Fix DFCI Enrollment Failures on Windows 11 24H2 Pro During Autopilot

If you are trying to use Device Firmware Configuration Interface (DFCI) during Windows Autopilot on a device running Windows 11 24H2 Pro, stop treating it like a random profile sync problem.

Microsoft now documents a specific known issue: DFCI cannot currently be configured during out-of-box experience (OOBE) on Professional editions of Windows 11, version 24H2. That changes the troubleshooting path completely. If your device is on Pro during Autopilot, the failure is often not your assignment, not your UEFI payload, and not your network.

That matters because DFCI is usually part of a locked-down build process. If you expect BIOS or UEFI controls to land during provisioning and they do not, the device can leave the bench in a weaker state than your runbook assumes. Admins often discover this late, after the user already has the device.

This article walks through the Microsoft-documented limitation, what to check first, how to decide between KB5046740 or later versus an Enterprise edition step-up during OOBE, and what evidence to collect before you start reassigning profiles.

Quick fix checklist

Use this sequence before you delete the DFCI profile or re-register the device:

1. Confirm the device is really running Windows 11 version 24H2 Pro.
2. Confirm the device is supposed to receive a DFCI profile, not only a standard Settings Catalog or Device Control policy.
3. Confirm the hardware is actually DFCI-capable and from an OEM that supports DFCI.
4. Confirm the device was not manually registered to Autopilot by CSV import, because Microsoft says manually registered devices are not allowed to use DFCI.
5. If the device is already provisioned on 24H2 Pro, install KB5046740 or any later cumulative update.
6. After the update is installed, sync the device and restart it so DFCI enrollment can complete.
7. If DFCI must land during OOBE, make sure the device steps up to Windows 11 Enterprise 24H2 during onboarding, then sync, then continue the enrollment flow.
8. Validate in Intune that the DFCI profile is assigned to the intended device group.
9. Test one pilot device before you broaden the change to the whole hardware model.

If you only remember one thing, remember this: Windows 11 24H2 Pro and OOBE-time DFCI are the bad combination.

What this issue actually means

Microsoft’s current Windows Autopilot known issues page and the dedicated DFCI Management page both state that:

DFCI can't currently be configured during the out-of-box experience (OOBE) on devices with Professional editions of Windows 11, version 24H2.

Microsoft also gives two supported paths forward:

• for devices already provisioned on Windows 11 24H2 Pro, install KB5046740 or later
• for devices that must get DFCI during OOBE, move them to Windows 11 Enterprise 24H2 during onboarding, sync them, and then let DFCI enroll

That wording tells you this is not just a vague provisioning hiccup. It is a product limitation with a documented workaround path.

DFCI itself is the bridge that lets Intune manage supported UEFI settings after Autopilot enrollment. Microsoft says DFCI uses a trust chain that lets Windows pass management commands down into firmware, which is why admins use it to lock boot options, restrict firmware changes, and keep local users from bypassing platform controls.

When DFCI does not enroll, the machine can still finish Windows Autopilot and look healthy in the usual high-level views. That is the trap. The operating system may be enrolled while the firmware governance layer you expected never landed.

Why admins misdiagnose this

In practice, this problem often gets mixed up with four other issues:

1. The device is DFCI-ineligible for a reason unrelated to 24H2 Pro

Microsoft says manually registered Windows Autopilot devices, such as devices imported by CSV, are not allowed to use DFCI. DFCI requires external attestation of commercial acquisition through the OEM or a Microsoft CSP partner registration path.

So if the device was manually imported and the admin only notices the DFCI failure later, it can look like a Windows 11 24H2 bug when the device was never eligible for DFCI in the first place.

2. The OEM or firmware path is not really DFCI-ready

Microsoft’s DFCI documentation says the OEM must enable the device for DFCI, either in manufacturing or through a firmware update. A DFCI profile assigned to unsupported hardware does not magically make the firmware manageable.

3. The profile is assigned, but the admin expects it too early

Microsoft also documents that DFCI enrollment adds an additional restart during OOBE. If your build notes assume the firmware controls are present before that point, you can easily misread the timing and assume the profile failed.

4. The device is on Pro when the admin expected Enterprise behavior

Windows Autopilot supports Windows 11 Pro, and Microsoft also documents Windows Subscription Activation as the supported way to step devices from Pro to Enterprise. That means the base Windows edition can be valid for Autopilot overall while still being the wrong edition for OOBE-time DFCI on 24H2.

That distinction is the core troubleshooting lesson here.

What to check first in Intune and on the device

Start by proving the device is in the exact failure bucket.

In Intune

Check these paths first:

• Devices > Windows > Windows enrollment > Devices for the Autopilot record
• Devices > Configuration for the DFCI profile assignment
• the device’s assigned groups
• the device’s Windows edition and version inventory

You want evidence for all of the following:

• the serial number matches the hardware in hand
• the device is a supported OEM model for DFCI
• the DFCI profile is assigned to the correct device scope
• the device was OEM or CSP registered for Autopilot, not manually imported for a DFCI scenario
• the endpoint is really on Windows 11 24H2 Pro

On the endpoint

Capture local OS state first:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
  Select-Object EditionID, DisplayVersion, CurrentBuild, UBR

This confirms whether you are really looking at Professional edition, whether the build is 24H2, and whether the system is new enough to include the cumulative update level you expect.

If the device is already in service, also confirm recent updates:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15 HotFixID, InstalledOn

If KB5046740 or a later cumulative update is missing, that is the first thing to fix for an already provisioned 24H2 Pro device.

Logs and where to verify DFCI readiness

This issue is mostly about state validation, not one magic error event. The goal is to prove whether the problem is:

• Windows 11 24H2 Pro during OOBE
• missing cumulative update level
• device ineligible for DFCI
• bad profile targeting
• unsupported hardware or OEM path

Check DFCI readiness via Graph

Microsoft’s DFCI management documentation says DFCI readiness can be identified through the Intune Graph path:

managedDevice/deviceFirmwareConfigurationInterfaceManaged

A practical Graph check looks like this after you identify the managed device ID:

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$DeviceId = "YOUR-MANAGED-DEVICE-ID"
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/deviceManagement/managedDevices/$DeviceId/deviceFirmwareConfigurationInterfaceManaged"

Use that to confirm whether Intune sees the device as DFCI-managed or DFCI-capable after the edition and update prerequisites are fixed.

Check the assigned profile history

In Intune, confirm the DFCI profile itself was not the problem:

• profile exists
• profile is assigned to the right device group
• no last-minute scope change removed the target
• the pilot device synced after assignment

Check whether the device was manually registered

This is a common blind spot in labs and staging environments. If a technician imported the hardware by CSV for convenience, that may be enough to disqualify the device from DFCI even though basic Autopilot still works.

Practical remediation workflow

Scenario A: The device is already provisioned on Windows 11 24H2 Pro

This is the cleaner recovery path.

1. Confirm the device is on 24H2 Pro.
2. Install KB5046740 or any later cumulative update.
3. Sync the device with Intune.
4. Restart the device.
5. Recheck DFCI status in Intune or Graph.

Microsoft’s documentation is explicit that devices on Professional editions of Windows 11 24H2 with KB5046740 or later are automatically enrolled in DFCI after a restart.

This means you should not waste time rebuilding the device first. If the endpoint is already live, the fix is usually an update-state correction, not a tenant rebuild.

Scenario B: DFCI must be configured during OOBE

This is the path for locked-down new deployments where the firmware controls must be in place before the device leaves staging.

Microsoft’s documented workaround is:

1. During onboarding, ensure the device is upgraded to Windows 11 Enterprise 24H2.
2. After the edition step-up, sync the device.
3. Continue the workflow so DFCI can enroll in the expected path.

Operationally, this means your Autopilot runbook has to account for edition step-up timing. If the device stays on Pro throughout OOBE, the DFCI profile can remain effectively stranded even though your Autopilot profile and MDM enrollment look correct.

Scenario C: The device still does not enroll in DFCI after the documented fix

At that point, stop blaming 24H2 Pro alone and work the next layer:

• verify the hardware vendor actually supports DFCI on that model
• verify the firmware level required by the OEM
• verify the device was not manually registered for Autopilot
• verify the DFCI profile assignment landed after sync
• compare one failing model against one known-good model

That side-by-side comparison is usually faster than reading generic logs for hours.

What not to waste time on first

For this exact issue, these are usually poor first moves:

• deleting and recreating the DFCI profile before checking edition and update level
• reimporting the Autopilot device record before checking whether the device was manually registered
• assuming any supported Windows 11 edition is equally valid for OOBE-time DFCI on 24H2
• changing unrelated ESP blocking app lists
• chasing generic network blame without first proving DFCI eligibility

Those moves create noise and often hide the real blocker.

Limitations and caveats

A few constraints matter here:

• Autopilot support is broader than OOBE-time DFCI support. A device can be valid for Autopilot and still hit the DFCI limitation on 24H2 Pro.
• DFCI eligibility is hardware- and registration-dependent. OEM support and commercial-registration rules still apply after you fix the Windows edition problem.
• A successful Windows enrollment is not proof that firmware controls applied. You must verify the DFCI layer separately.
• Lab shortcuts break DFCI more easily than standard Autopilot. CSV imports and mixed staging flows can produce misleading test results.

Prevention

To keep this from slowing the next rollout:

1. Build a DFCI preflight checklist into your Autopilot staging process.
2. Record whether each hardware model is OEM DFCI-capable before you assign the profile.
3. Track whether the device was OEM/CSP registered or manually imported.
4. For Windows 11 24H2 fleets, decide up front whether the path is:
   • Pro + KB5046740 or later after provisioning, or
   • Enterprise step-up during OOBE for immediate DFCI needs.
5. Validate one pilot device per hardware family before broad rollout.
6. Verify DFCI status in Intune or Graph instead of assuming the firmware layer landed.

Conclusion

If DFCI enrollment fails on Windows 11 24H2 Pro during Autopilot, the most important fact is that Microsoft already documents this as a known limitation. For already provisioned devices, install KB5046740 or later, sync, and restart. For deployments where DFCI must apply during OOBE, use Windows 11 Enterprise 24H2 during onboarding instead of leaving the device on Pro. Once you separate edition state, update state, DFCI eligibility, and OEM readiness, the troubleshooting path becomes much shorter and a lot less expensive.

Sources

• Microsoft Learn: Windows Autopilot known issues
• Microsoft Learn: DFCI Management
• Microsoft Learn: Windows Autopilot requirements
• Microsoft Support: KB5046740 (OS Build 26100.2454)