DEV Community: Exactey

The 5 Conditional Access Mistakes That Lock Users Out (And How to Fix Them)

Exactey — Wed, 10 Jun 2026 10:35:33 +0000

One wrong Conditional Access policy and your entire organization is locked out. No exceptions. Not some users — everyone, including you.
These are the five mistakes I see most often. Each one has locked out real users in real environments.

Mistake 1: No break-glass account
This is the one that causes the most damage. A break-glass account is a cloud-only Global Administrator account that is excluded from every single Conditional Access policy. Its only purpose: if a misconfigured policy locks out all admins, you can still get in and fix it.
Most environments don't have one until after the first lockout.
How to set it up correctly:
Create a cloud-only account — not synced from on-prem AD. Something like emergency-admin@yourtenant.onmicrosoft.com. Assign Global Administrator permanently, not via PIM. Use a long random password stored offline. Register MFA using a FIDO2 hardware key, not an authenticator app tied to a personal phone. Exclude this account from every Conditional Access policy you create. Monitor sign-ins — any login from this account should trigger an alert immediately.
Never skip this step. Microsoft explicitly recommends break-glass exclusions in every CA policy tutorial in their documentation for good reason.

Mistake 2: Enabling "Require compliant device" before devices are enrolled
This is the fastest way to lock out your entire user base in one click.
What happens: you enable the policy targeting All Users, and every user whose device is not yet enrolled in Intune and marked compliant gets blocked from everything — including the Intune portal they need to enroll.
The correct order:

Create an Intune compliance policy first
Confirm at least one device is enrolled and marked compliant
Start with a pilot group of 10-20 users, not All Users
Use the flexible version first: require compliant device OR MFA — this gives unenrolled users a fallback instead of a hard block
Expand to All Users only after full enrollment is complete

If you are not ready to enforce device compliance for everyone, use the flexible policy. It is always better than a hard block on day one.

Mistake 3: Not using Report-only mode first
Every new Conditional Access policy should start in Report-only mode. In this mode the policy is evaluated but not enforced — users are not blocked or prompted. You see exactly who would be affected before anything happens.
Most lockouts happen because someone created a policy, set it to On immediately, and did not check the impact first.
The correct flow:

Create policy → set Enable policy to Report-only → Save
Wait 24-48 hours
Review sign-in logs: Entra Admin Center → Monitoring → Sign-ins → Conditional Access tab
Use the What If tool to simulate specific users and scenarios
Only switch to On after confirming the impact is what you expected

This costs you 24 hours. Skipping it can cost you hours of emergency recovery.

Mistake 4: Blocking legacy authentication without checking who uses it
Blocking legacy authentication is one of the highest-value CA policies you can enable — over 99% of password spray attacks use legacy auth protocols. But if you enable it without checking first, you will block legitimate users.
Common legacy auth users that get missed:

Older printers and scanners sending email via SMTP
Shared mailboxes accessed via older Outlook versions
On-premises applications authenticating via basic auth
Some conferencing equipment

How to check before enabling:
Go to Entra Admin Center → Monitoring → Sign-ins → filter by Client app → select Exchange ActiveSync and Other clients. Any sign-ins showing here are using legacy authentication. Document them before you block anything.
Then enable the policy in Report-only mode, review the impact, handle the exceptions, and only then turn it on.

Mistake 5: Forgetting that all policies apply simultaneously
This is a logic mistake that creates unexpected blocks.
Conditional Access policies are not evaluated one at a time — all applicable policies must be satisfied simultaneously. If Policy A requires MFA and Policy B requires a compliant device, the user must complete both MFA AND use a compliant device. There is no "first match wins" logic.
This creates problems when:

You have a policy requiring MFA for all users
And a separate policy requiring a compliant device for all users
And a user is on an unenrolled device

They cannot satisfy the compliant device requirement, so they are blocked — even though your intention was to allow MFA as a fallback.
Fix: think through policy combinations carefully. Use the What If tool to simulate specific users before enabling. And when in doubt, use OR logic in grant controls instead of AND.

The safe rollout order
If you are starting from scratch, enable policies in this order:

Create break-glass accounts first — non-negotiable
Disable Security Defaults
Create all policies in Report-only mode
Review sign-in logs for 24-48 hours
Enable Block legacy authentication — low user impact, high security gain
Enable MFA for all users — communicate to users first
Enable device compliance — start with pilot group only

Never enable everything at once. One policy at a time, Report-only first.

I put together a complete playbook covering all 10 essential Conditional Access policies with exact configuration steps, the full safe rollout order, 5 lockout scenarios with fixes, and a 28-item implementation checklist — all sourced from official Microsoft documentation.
Get it here: https://exactey.gumroad.com/l/ConditionalAccess-IntuneCompliance
Questions? Drop them in the comments.
Sources: learn.microsoft.com/en-us/entra/identity/conditional-access

Windows Autopilot: The 7 Most Common Deployment Failures (And Exactly How to Fix Them)

Exactey — Wed, 10 Jun 2026 10:28:03 +0000

If you've deployed Windows Autopilot more than twice, you've hit at least one of these. The same seven failures keep showing up across every environment. Not edge cases — the same errors, over and over.
This post covers each one with the exact cause and fix.

Error 1: 0x800705B4 — "Preparing device for mobile management failed"
Nine times out of ten: TPM.
Check in this order:

Run tpm.msc on the device. Specification Version must show 2.0 — if it shows 1.2, the device is not supported for Self-Deploying mode.
Open BIOS/UEFI → Security → TPM → must be set to Enabled. Not just present. Actually enabled.
If TPM shows 2.0 but error persists → Clear TPM in BIOS, then retry. This fixes corrupted TPM state from previous enrollment attempts.
Open CMD via Shift+F10 during OOBE and run: Test-NetConnection -ComputerName login.microsoftonline.com -Port 443
Check Event Viewer: Microsoft-Windows-ModernDeployment-Diagnostics-Provider → Autopilot

Note: Hyper-V virtual TPMs are NOT supported for Autopilot Self-Deploying mode. If you're testing on a VM, this error is expected and cannot be fixed.

Error 2: 0x80180014 — Re-enrollment after reset fails
After a first Self-Deploying or Pre-Provisioning deployment, Intune blocks re-enrollment of the same device.
Fix:

Intune Admin Center → Devices → All Devices → find the device → Delete
Redeploy — it will now enroll fresh

If caused by a malformed Hardware Hash CSV: never open the CSV in Excel. Excel corrupts the binary hash format silently. Re-collect with PowerShell: Get-WindowsAutopilotInfo -OutputFile C:\hash.csv

Error 3: No company branding on OOBE — standard Windows setup appears
The Autopilot profile was not received by the device.
Root causes in order of likelihood:

Device is not registered in the Autopilot service at all
Profile is not assigned to a group the device belongs to
No network connection at first boot
Group sync has not completed after device import

The dynamic group rule must be: (device.devicePhysicalIds -any (_ -eq "[ZTDId]"))
Quick test: after connecting to network during OOBE, wait 60 seconds. If the sign-in page shows your company name and logo, the profile was received. If it shows the generic Microsoft logo, the profile was not received.

Error 4: 0x80180005 — "ZTD Profile was not assigned to ZTD Device"
Commonly seen during Pre-Provisioning (White Glove) mode in the technician phase.
Fix:

Delete all objects for this device in Intune, Entra ID, and local AD if Hybrid
Re-register the device with a fresh Hardware Hash
Verify the profile is assigned to the dynamic device group
Wait 15 minutes for sync to complete before retrying

Error 5: ESP stuck or timing out
Common causes: a Win32 app failing to install, ESP timeout too low for your app payload (60 minutes default is often not enough), or slow internet during large app downloads.
Diagnose with: Get-AutopilotDiagnostics (install from PowerShell Gallery first)
Fixes:

Increase ESP timeout to 90-120 minutes: Intune → Windows Enrollment → ESP
Check app configuration in Intune: correct requirements? All dependencies present?
Temporarily disable ESP to isolate whether the issue is app-related

Error 6: 0x8007052E — "Registering your device for mobile management failed"
Authentication failure during enrollment.
Common causes: incorrect credentials during OOBE, a Conditional Access policy blocking the unenrolled device, or firewall blocking Microsoft endpoints.
Fix:

Check Entra ID Sign-in logs: Entra Admin Center → Monitoring → Sign-ins → find the failed event → Conditional Access tab
If a CA policy is blocking: temporarily exclude the device or user during enrollment
Verify all Autopilot network endpoints are reachable on port 443

I put together a complete PDF guide covering all errors in full detail, a complete 8-step deployment walkthrough, recommended profile settings, and a 24-item checklist — all sourced directly from official Microsoft documentation.
Get it here: https://exactey.gumroad.com/l/windows-autopilot-setup-guide
Questions? Drop them in the comments — happy to help.