The Autopilot Conditional Access deadlock: requiring a compliant device can block the enrolment that makes devices compliant

On Friday afternoon someone tightened your Conditional Access baseline. On Monday morning every new laptop dies in the out-of-box experience. Nobody touched Autopilot, nobody touched Intune, and the devices that were already enrolled are perfectly happy. Only the brand-new ones fail. That shape of outage almost always points at the same thing: a policy that asks a device to prove something it cannot possibly know yet.

Conditional Access (CA) is the gate. Device compliance is the claim the gate wants to see. Compliance is a statement Intune makes about a device it already manages. A factory-fresh Autopilot device is not managed yet, so it has no compliance state to present. Ask for that state at the wrong moment and you have blocked the enrolment that would have produced it. This post explains exactly where in the out-of-box experience (OOBE) that happens, which shapes of policy cause it, which shapes Microsoft explicitly says do not, and how to prove which one you have before you edit anything.

The problem: OOBE fails and nothing on the device is broken

The failures do not look like Conditional Access failures. That is what makes this expensive. Autopilot surfaces a generic wall of text, and the person holding the laptop reports whatever it says.

The three faces of this outage are worth learning by sight. First, a plain interruption on the sign-in page during OOBE. Microsoft documents the generic version of this as Something went wrong, and the documented first cause is that the client cannot reach the required identity endpoints. A Conditional Access block produces a similar-looking interruption for a completely different reason, which is why you cannot diagnose this from the device screen alone.

Second, the Enrollment Status Page (ESP) hangs and then times out. Microsoft documents this precise combination: you are using the ESP to track store apps, you have a CA policy that uses the Require device to be marked as compliant control, and that policy applies to all cloud apps and to Windows. The device sits waiting for a compliance verdict it cannot obtain, and the page expires before the sign-in screen loads.

Third, the device gets through OOBE and then a user cannot sign in to anything. This is the Microsoft Entra hybrid joined variant. Microsoft documents that a hybrid Autopilot deployment initially associates two device IDs with the same physical machine, one Microsoft Entra ID and one hybrid, and that the hybrid compliance state displays as N/A until a user signs in. Intune only syncs with the hybrid device ID after a successful user sign-in. A device-based policy that blocks on compliance will block during that window, and Microsoft states plainly that this behaviour is intended.

So the interesting question is not "does requiring compliance break Autopilot". It is "what did we add on top of the plain policy that removed the safety net". There are only a handful of answers.

Why it happens: compliance is a fact about a device you already manage

To see where the deadlock lands you need the enrolment order of operations. Microsoft documents the user-driven Autopilot sequence as eight steps. Compressed, and with the identity events called out:

Read steps 4 and 5 together. The Microsoft Entra device object exists before Intune manages the device. Compliance is a verdict Intune reaches about a device it manages, so compliance necessarily arrives after both. Any grant control that asks about device state before step 5 is asking a question with no answer. That is the whole mechanism.

The applications involved, and their documented IDs

Conditional Access does not evaluate "enrolment". It evaluates token requests for named resources. These are the resources that matter during OOBE, with the application IDs Microsoft publishes for them.

The four shapes that actually deadlock

Microsoft's Autopilot known-issues article carries a section titled Device-based Conditional Access policies. It is the single most useful paragraph on this subject, and it names the shapes.

The key sentence in that Microsoft section, and the one that resolves the chicken-and-egg framing, is this: if a policy is in place such that all cloud apps require a compliant device and there is no exclusion list, then by default Microsoft Intune Enrollment is excluded, so that the device can register with Microsoft Entra ID and enrol with Intune, and avoid a circular dependency.

The multifactor-authentication variant

Requiring MFA at enrolment is a legitimate, documented configuration. It is not the deadlock. The failure mode is different, and it comes from where you attach the requirement.

Microsoft's supported path for requiring MFA at enrolment targets the Microsoft Intune Enrollment app and combines Require multifactor authentication with Require device to be marked as compliant under Require all the selected controls. That combination is the documented recipe, and the same article states that if a device is not compliant, the user is prompted to make the device compliant before enrolling. The same article also carries a blunt instruction: do not configure device based access rules for Microsoft Intune enrolment.

The cleaner modern option is the Register or join devices user action. Microsoft documents that only two access controls are available with it, Require multifactor authentication and Require authentication strength, and that all others are disabled specifically to prevent conflicts with controls that depend on device registration having already happened. In other words, Microsoft removed the ability to create this particular deadlock on that user action. Note also that Windows Hello for Business and device-bound passkeys are not supported there, because those scenarios require the device to be registered already.

How to verify: read the sign-in log before you edit a policy

Everything above is a hypothesis until the sign-in log confirms it. Verify cloud-side first, because the cloud has the authoritative answer and the device only has symptoms.

1. Find the blocked sign-in in the Entra sign-in logs

You need at least the Reports Reader role. Microsoft documents the filters to narrow the noise, and for this investigation four of them do the work.

1. Filter on Date, scoped to the window when the OOBE attempt failed.
2. Filter on Username, using the account that was typed at the OOBE sign-in page.
3. Filter on Resource and look for Microsoft Intune Enrollment and Microsoft Intune.
4. Filter on Conditional Access and scope it to failures only.

If the failing OOBE screen offered a More Details link, take the correlation ID from it and filter on Correlation ID instead. That takes you straight to the event rather than to a plausible neighbour.

Select the Conditional Access tab on the event. Microsoft documents that this tab shows the specific policy or policies that caused the interruption. The Troubleshooting and support tab often states the reason in one line, such as a device that did not meet compliance requirements. Select the ellipsis beside a policy to see, condition by condition, whether the signals collected at sign-in satisfied that policy. Policies apply only when all conditions are satisfied or not configured, so that side-by-side view is where a wrong assumption dies.

2. Match the error code

Microsoft publishes the common Conditional Access sign-in error codes. These four are the ones that show up in enrolment investigations. In a browser they appear with an AADSTS prefix.

3. Audit the policy set with Graph, read-only

Reading policies one at a time in the portal does not scale, and it is easy to miss the one policy with a stale exclusion list. The companion script for this post reads every Conditional Access policy with a single least-privilege permission and reports the ones that match a deadlock shape. It performs GET requests only.

Two things to know about the values the script reads, both from the Microsoft Graph reference. The grant control names are block, mfa, compliantDevice, domainJoinedDevice, approvedApplication, compliantApplication, passwordChange and riskRemediation. The only two supported user action strings are urn:user:registersecurityinfo and urn:user:registerdevice. If you are writing your own tooling, use those literals rather than the portal labels.

4. Corroborate on the device

Cloud-side evidence is authoritative, but the device tells you which phase failed. There is a documented event surface for that. All of these live under Event Viewer › Applications and Services Logs › Microsoft › Windows.

The fix: exclusions, user actions and grace periods

Fix the specific shape you confirmed. Do not apply all of these blindly, because each exclusion is a small reduction in coverage and you should be able to justify every one.

Fix 1: exclude the enrolment resources from a restrictive block policy

This is the documented remedy for the block-all-except-a-list shape. You can do it from either portal, and the Conditional Access blade in Intune is the same blade as the one in Entra.

1. Sign in as at least a Conditional Access Administrator.
2. Open the block-style policy that the sign-in log named as the failure.
3. Select Target resources, then Resources (formerly cloud apps).
4. Select the Exclude tab, then Select excluded resources.
5. Search for Microsoft Intune Enrollment and select it.
6. Search for Microsoft Intune and select it as well. Microsoft names both apps for this remedy.
7. Select Select, then Save.
8. Repeat for any Terms of Use policy, because Terms of Use is not supported for the Intune Enrollment app.

If Microsoft Intune Enrollment is not in the picker, you are on a tenant where the service principal was never created. Microsoft documents that an administrator must create it, with app ID d4ebce55-015a-49b5-a083-c84d1797ae8c, in PowerShell or Microsoft Graph. That is a write operation, so do it deliberately and record it in your change log.

Fix 2: move the enrolment MFA requirement to the right place

If your goal is a second factor before a device can join, use the user action rather than bolting device-state controls onto the enrolment app.

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID › Conditional Access › Policies and select New policy.
3. Name the policy to a standard you can search later.
4. Under Assignments › Users or workload identities › Include, select All users.
5. Under Exclude, select Users and groups and add your emergency access or break-glass accounts.
6. Under Target resources › User actions, select Register or join devices.
7. Under Access controls › Grant, select Grant access, then Require authentication strength, then the built-in Multifactor authentication strength.
8. Set Enable policy to Report-only and select Create.
9. Review the report-only results, then move the toggle to On.

Then turn off the overlapping tenant-wide setting, or the policy will not be enforced properly.

Fix 3: give device-state compliance rules room to become true

Two adjustments, both documented, both on the Intune side rather than the Conditional Access side.

1. Open the Windows compliance policy that evaluates BitLocker or Secure Boot.
2. Set a grace period on the actions for noncompliance. Microsoft notes the grace period is needed because BitLocker and Secure Boot state are not captured until the device reboots, and that it can be as short as 0.25 days.
3. Assign your compliance policies to device groups rather than user groups. Microsoft's documented fix for the ESP timeout is exactly this: target compliance policies to devices so that compliance can be determined before the user signs in.
4. If you track store apps on the ESP, use offline licensing for them, so the client does not have to check with the Microsoft Store before compliance is known.

Fix 4: the hybrid join case

There is no exclusion that makes the hybrid compliance window disappear, because the N/A state is a real reflection of the sync order. Microsoft gives two options: a user signs in to the device, which lets Intune sync the hybrid device ID, or you modify the device-based policy. If you are building new devices, Microsoft's standing recommendation is to deploy them cloud-native with Microsoft Entra join rather than hybrid join, including through Autopilot.

Proof it worked: a clean audit and a quiet sign-in log

Three pieces of evidence, in the order you should collect them.

First, the audit script comes back with nothing to say about the policy you fixed. The block below is illustrative output, hand-composed to show the report format; it is not a capture from a live tenant.

Second, re-run a real OOBE on a test device and look at the same sign-in event. The Microsoft Intune Enrollment resource should now show Success, and on the Conditional Access tab the previously failing policy should read Not applied because the resource is excluded, rather than Success. Those two outcomes mean different things and it is worth knowing which one you got.

Third, confirm the device landed where it should.

One closing thought on design rather than repair. Microsoft's guidance keeps steering toward a small number of broad policies with no resource exclusions, and toward doing enrolment-time enforcement with the mechanism built for it. The deadlock is almost always a symptom of an exclusion list that grew organically, one exception at a time, until nobody could describe what it covered. If your audit script found several findings rather than one, the fix is probably not another exclusion. It is fewer, simpler policies.

References

Microsoft official documentation

• Windows Autopilot known issues — the Device-based Conditional Access policies section, which names the enrolment app exclusions, the Terms of Use limitation, the hybrid N/A compliance window and the BitLocker grace period.
• How to require device compliance with Conditional Access — the note stating that the compliant-device control does not block Intune enrolment, and the Subscription Activation exclusion.
• Require multifactor authentication for Intune device enrollment — the documented app ID for Microsoft Intune Enrollment, and the note that the service principal is not created automatically for new tenants.
• Troubleshooting sign-in problems with Conditional Access — sign-in log navigation, the Conditional Access tab, audience reporting, and error codes 53000 to 53009.
• Targeting resources in Conditional Access policies — the Register or join devices user action and the controls it does and does not support.
• Require MFA for device registration — the supported walkthrough, and the warning about the tenant-wide device setting.
• Windows Autopilot user-driven mode — the documented OOBE sequence used in the table above.
• Troubleshooting Windows device enrollment problems in Intune — the ESP timeout caused by a compliant-device policy across all cloud apps, and Event ID 76.
• Troubleshoot auto-enrolling existing Configuration Manager devices in Intune — the documented app ID for Microsoft Intune and the MFA exclusion guidance.
• Troubleshoot Microsoft Entra hybrid joined devices — the User Device Registration and AAD event IDs in the catalog above.
• List Conditional Access policies (Microsoft Graph) — the endpoint and the Policy.Read.All least-privileged permission the companion script uses.
• conditionalAccessGrantControls resource type — the exact builtInControls enumeration values.

Community deep-dives

Companion script

Get-AutopilotCaDeadlockReport.ps1 reads every Conditional Access policy in the tenant and reports the ones matching a deadlock shape. It is GET-only, uses the single delegated permission Policy.Read.All, runs on Windows PowerShell 5.1 and PowerShell 7, and aborts with a loud message rather than reporting a clean result after a failed query.