Locked out of Microsoft 365 by Conditional Access: recovery order, and the fifteen minutes that prevent it

The forum threads have the word URGENT in the title. Someone tightened a Conditional Access policy, or Microsoft’s mandatory MFA for the admin centre kicked in, and now no administrator can sign in. Here is the recovery order, from least to most painful, and the fifteen minutes of setup that would have made all of it unnecessary.

First: is anyone still in?

Before anything else, find a session that works. Check every administrator, on every device, in every browser. A session that was open before the policy took effect often survives it. So does a browser that already holds a token. Try:

A different network — mobile hotspot instead of the office — if the policy is location-based. A personal device if the policy requires compliant devices. An incognito window if the trouble is a cached token. A different administrator account, including service and automation accounts with Global Administrator, and the break-glass account if one exists.

If any of these get you in, go straight to Entra admin centre → Protection → Conditional Access, find the policy from the sign-in logs (the error is usually 53003), and switch it to Report-only. Do not delete it; you will want to fix it, not lose it.

Second: nobody is in

This is a tenant lockout, and there is exactly one supported path: Microsoft’s Data Protection team, sometimes called Tenant Recovery. It is slow, it requires proof of ownership, and it is the only door.

Open a ticket from somewhere. You cannot open one from the locked tenant. Options: your Cloud Solution Provider can open one on your behalf — this is one of the things you pay a partner for. If you have another tenant with an administrator, open it there and describe the locked one. If you have neither, create a free Microsoft 365 trial tenant, sign in to its admin centre, and open the ticket from there, stating clearly that the affected tenant is a different one.

What the ticket needs. The locked tenant’s primary domain, the UPNs of the Global Administrators, the error code, a statement that every administrator is blocked and no emergency account exists. Expect to be asked for a letter of authorisation signed by the billing owner. Expect days, not hours.

What to say to the business. Users are usually still working — the policy blocked administrators, not everyone. Nothing is lost. Nothing can be changed until access is restored.

Third: while you wait

Write down what the policy was supposed to do, and what it did instead. Nine times out of ten it is one of these: a policy scoped to All users with no exclusions; Require compliant device before any device was enrolled; Require MFA on accounts whose MFA method was never registered; a named-location policy after the office IP changed; or blocking legacy authentication while an administrator still used a client that needs it.

Fourth: never again

This is the part that matters, and it takes fifteen minutes.

Create two emergency access accounts. Cloud-only, on the .onmicrosoft.com domain so no federation or on-premises dependency can break them. Global Administrator. Passwords of thirty or more random characters, stored in two physically separate places — a safe, a sealed envelope, a second password manager. Not the same one the compromised administrator used.

Exclude them from every Conditional Access policy. Every one, including the ones you have not written yet. Make a group, put both accounts in it, and exclude the group from each policy as it is created.

Give them a phishing-resistant second factor — a FIDO2 security key kept with the password, not a phone that can be lost or a number that can be ported. Microsoft’s mandatory MFA for admin portals applies to these accounts too; a key satisfies it without depending on Conditional Access.

Alert on their use. Route sign-in logs to a workspace or a mailbox and alert on any sign-in by either account. They should be used twice a year to prove they work, and never otherwise.

Roll out every policy in report-only first. Let it run for a week. Read the sign-in log to see who it would have blocked. Then, and only then, enable it — scoped to a pilot group before All users.

The order for a new policy, every time

Skip step 1 and steps 2 to 6 are how you find out you skipped it.