Locked Out by Conditional Access in Microsoft 365? How to Recover

A Conditional Access (CA) policy has been published, refined, or auto-applied — and now nobody can sign in. Or worse, only your standard admins can't sign in, and a senior leader is asking for a fix in the next 30 minutes before a board call.

Conditional Access lockouts are one of the most common Microsoft 365 outages because the trade-off is built into the design: tighten the policy and you tighten the failure mode along with it. This guide walks through how to recover access fast, find the offending policy in the sign-in logs, and put proper safeguards in so it doesn't happen again. Written for IT managers and infrastructure engineers responsible for Entra ID / Microsoft 365 tenants.

If you're locked out right now and time is critical, call 01923 372471 — senior engineer answers directly with experience across hundreds of M365 tenants.

Step 1: Use a break-glass account

If you set up the tenant correctly, you have a break-glass account — also called an "emergency access account":

• A cloud-only account in Entra ID (not synced from on-prem AD)
• With Global Administrator role
• Excluded from every Conditional Access policy
• With a long, randomly-generated password stored offline (not in your password manager, not in your work email — somewhere genuinely separate, like a sealed envelope in a safe)
• Without MFA, or with FIDO2 security key MFA only (so it doesn't depend on the same factors as everyone else)
• Monitored — sign-ins to this account should generate alerts, because in normal operation it should never be used

If you have one, sign in with it now. Open the Entra admin centre at entra.microsoft.com or portal.azure.com, go to Conditional Access, and proceed to Step 2.

If you don't have one, skip to Step 4 — recovery without a break-glass account is harder but not impossible.

Step 2: Identify the offending policy

In the Entra admin centre:

Identity > Monitoring & health > Sign-in logs

Filter by:

• A user who is locked out (the most senior person who can't get in is usually a good start, since their failure is most informative)
• Status = Failure
• Date range = the last hour

Open a failed sign-in. The Conditional Access tab on the sign-in detail shows every policy that was evaluated and the result of each. You're looking for policies showing "Failure" or "Not Applied" with a result of "Block" in the policy detail.

Note the policy name(s). This is your culprit.

Step 3: Disable or modify the policy

Two options, in order of safety:

Option A: Set the policy to Report-only

Cleanest fix. The policy continues to log what it would have done, but no longer blocks anyone.

Conditional Access > Policies > [policy name] > toggle to "Report-only" > Save.

Test sign-in immediately. Users should be able to authenticate within 1–2 minutes (Conditional Access changes propagate quickly but not instantly).

Option B: Add an exclusion for affected users

If only a subset of users is affected and you want to keep the policy enforced for the rest:

[Policy] > Users or workload identities > Exclude > Users and groups > pick the affected users or a security group

This is appropriate when, for example, a "Require MFA from outside the office" policy is correctly blocking your remote sales team because someone changed the named-locations definition. Exclude them temporarily; investigate; reinclude properly.

Option C: Disable the policy entirely

[Policy] > Set to "Off"

Use this only as a last resort, and only briefly — you've removed a security control. Document it, set a calendar reminder to re-enable, and re-enable as soon as the immediate fire is out.

Step 4: Recovery without a break-glass account

If you don't have a break-glass account and your normal admins are blocked, you have a smaller set of options:

Option 1: Try a different network or device

Many CA lockouts are conditional on network location, device compliance, or sign-in risk. Try:

• Signing in from an entirely different network (mobile hotspot, home connection)
• Signing in from a personal device on the same network
• Signing in from a different country (via VPN exit) — only if the policy isn't location-bound
• Signing in via a different browser, in InPrivate / Incognito mode

If any of these gets you in, you have a working session. Go to Conditional Access immediately and disable the policy as in Step 3.

Option 2: Microsoft Support

Microsoft Support can, in genuine global-admin lockout scenarios, help recover access. This requires:

• A signed Letter of Authorisation from the tenant's billing owner
• Confirmation that you are the legitimate tenant administrator
• Time — Microsoft Support is not a quick fix. Expect 24–72 hours from initial call to access restored.

Open a support ticket via your Microsoft partner if you have one, or via aka.ms/PortalSupport if you can reach a Microsoft account that has visibility of the tenant.

Option 3: Subscription owner override

The user designated as Subscription Administrator (Azure subscription, not the tenant) can sometimes elevate access via "Access management for Azure resources" in the directory properties — entra.microsoft.com > Properties > Access management for Azure resources > Yes. This grants User Access Administrator at the root scope, which doesn't directly recover M365 access but does let you assign roles in Entra. Combined with a recoverable account, this is sometimes enough.

Option 4: Token-based bypass (pre-auth still working)

If interactive sign-in is blocked but a refresh token from before the lockout is still valid, tools like the Graph PowerShell SDK signed in with that token can still operate.

# If you still have an authenticated session somewhere:
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
Get-MgIdentityConditionalAccessPolicy | Where-Object DisplayName -eq "<policy name>" |
    Update-MgIdentityConditionalAccessPolicy -State "disabled"

Useful in narrow circumstances. Don't rely on this as a recovery strategy.

Step 5: Why CA policies lock people out

Common causes, in rough order of frequency:

1. "Require compliant device" enabled before all devices were enrolled — users on personal devices, contractor devices, or unmanaged Macs get blocked.
2. Named locations misconfigured — a "block sign-ins from outside the UK" policy without UK office IPs whitelisted; or with a typo in the IP range.
3. MFA required but registration incomplete — users who never finished MFA registration get caught when "Require MFA" is enforced.
4. "Block legacy authentication" rolled out without auditing first — old Outlook clients, old MFP scan-to-email, old line-of-business apps using EWS or POP/IMAP all stop working.
5. Risk-based policies firing on legitimate sign-ins — Entra Identity Protection flags a user who connected via a new VPN exit; CA blocks based on the risk score.
6. Scope of "All users" — including emergency accounts — the most preventable lockout. This is precisely why break-glass accounts must be excluded from "All users" via group exclusion or named exclusion.

What NOT to do

• Don't reset every user's MFA to try to fix a lockout. You'll create days of helpdesk work and won't address the cause.
• Don't disable Conditional Access entirely as a "fix" and forget to re-enable. CA is a critical security control; disabling it leaves the tenant exposed to what it was protecting against.
• Don't try to call Microsoft via the standard support number if the tenant is a partner-managed tenant. Go through your partner first; they have escalation paths you don't.
• Don't make multiple changes at once while diagnosing. Change one thing, test, observe, change the next. CA policies interact in subtle ways.
• Don't blame the user. The CA policy you (or someone) wrote is what's blocking them. Fix the policy.

Prevention

After recovery, the standard hardening for Conditional Access:

1. Create two break-glass accounts (you want redundancy on the recovery path itself), excluded from every CA policy, with FIDO2 security keys, monitored.
2. Document the break-glass procedure in a place that doesn't depend on M365 (printed, in a safe, in a vault).
3. Use Report-only mode for new policies first. Run for a week. Review the impact. Promote to On only when you've seen what it would have done.
4. Use named locations correctly — your office IPs as "Trusted", with conditions only requiring MFA from outside trusted locations, not blocking outright.
5. Stage rollouts via security groups. New policy → "CA Pilot" group → "CA Wave 1" group → all users. Each stage with monitoring time between.
6. Audit policy changes via Entra audit logs with alerting. CA policy changes outside change windows are a red flag.
7. Test every quarter that your break-glass account works. A break-glass account that fails when you need it is no break-glass account.

When to call us

Call us if:

• You're locked out of the tenant entirely and don't have a working break-glass account.
• You're seeing partial lockouts (some users, some apps) that you can't trace to a specific policy.
• A planned CA rollout has caused unexpected business impact and you need help disentangling which policy is doing what.
• You suspect the CA configuration is more complex than it should be (overlapping policies that conflict) and want a tidy-up.

Engineerdirect.co.uk has senior engineers across Entra ID, Conditional Access design, MFA rollouts and break-glass procedures.

Call 01923 372471 — senior engineer answers directly. Same-day resolution.

FAQ

What is a break-glass account, and how many should I have? A break-glass account is a dedicated emergency-access account, cloud-only, with Global Administrator role, excluded from every Conditional Access policy. Microsoft recommends at least two — for redundancy if one is compromised, locked, or otherwise unavailable.

Should the break-glass account have MFA? Yes — but with FIDO2 security keys rather than the SMS / app methods other users use. The key is stored in a physical safe. This avoids the failure mode where the same MFA infrastructure that's blocking everyone else also blocks the break-glass account.

My break-glass account is also blocked. What now? Almost always means it was created without proper CA exclusions, or someone added a policy targeting "All users" without the exclusion. Step 4 of this guide covers no-break-glass recovery.

Can I disable Conditional Access without admin access? No, by design — only an account with Conditional Access Administrator or Global Administrator role can change CA policies. This is what makes break-glass accounts essential.

Why does my user pass the policy on Edge but fail on Chrome? Two common causes: (1) the policy requires a compliant device and Edge picks up the device-compliance claim from Windows while Chrome doesn't; (2) the policy requires Continuous Access Evaluation (CAE) and Chrome's session token has expired but the browser hasn't reauthenticated. Microsoft has been adding CAE support to Chrome via the Microsoft Single Sign-On extension — verify it's installed.

Can I use PowerShell to disable a Conditional Access policy? Yes — Update-MgIdentityConditionalAccessPolicy from the Microsoft Graph PowerShell module. You need an authenticated session with Policy.ReadWrite.ConditionalAccess scope, which means you need to be able to sign in — which is the problem you're trying to solve. Useful only if you have a still-valid token from before the lockout.

If you're locked out of your tenant right now, our emergency Microsoft 365 & Azure support can get an administrator back in safely.

Part of a series of disaster-recovery references. If you're locked out right now: 01923 372471.

References

Authoritative Microsoft Entra documentation behind this guide:

• Microsoft Learn — Manage emergency access (break-glass) accounts
• Microsoft Learn — Conditional Access overview
• Microsoft Learn — Sign-in logs in Microsoft Entra ID