Break Glass Account: Because ‘I’ll Just Ring Microsoft’ Isn’t a Recovery Plan

A break glass account is the spare key to your Microsoft 365 tenant, and like most spare keys, nobody thinks about it until they are standing outside in the rain.

The story usually goes like this. Someone tightens a Conditional Access policy at 4:55pm on a Friday. It now requires Microsoft Authenticator for every admin, including the two who never registered it. Teams goes quiet, the admin centres go quiet, and the Global Administrator is stuck in an MFA loop. Microsoft Q&A has a steady supply of threads just like this one.

You can ring Microsoft support and prove you own your own tenant. It works, eventually. It is also a bit like convincing a locksmith it is your house while your passport is inside it.

This guide covers how to set up a break glass account properly in 2026, why the old “long password in a safe” advice no longer works, and how to make sure the account actually works on the day you need it.

Never miss a guide: subscribe here and check out the Control Alt Delete Tech Bits YouTube channel.

What is a break glass account?

A break glass account is a highly privileged account you only use when your normal admin accounts cannot sign in. Microsoft calls it an emergency access account. Everyone else calls it break glass, after the little red fire alarm box on the corridor wall.

It is not an admin account for quiet days, and it is not a service account for your scripts. It sits in the corner doing nothing, which is exactly its job.

Think of a break glass account as a fire extinguisher. You hope you never use it, you check it regularly, and you definitely do not use it to prop the door open.

Microsoft’s guidance lives in Manage emergency access accounts in Microsoft Entra ID, and it is the page this article is built around.

Why the old break glass account advice no longer works

The classic break glass account was simple. A long random password, excluded from MFA and every Conditional Access policy, printed out and locked in a safe. I recommended exactly that in the first version of this article.

That advice now has the shelf life of a Windows 98 boot floppy. Microsoft has been enforcing mandatory MFA on its admin portals, and there is no opt-out for emergency accounts.

Portal or tool	MFA enforced from
Azure portal, Microsoft Entra admin centre, Microsoft Intune admin centre	October 2024 (phase 1)
Microsoft 365 admin centre	February 2025
Azure CLI, Azure PowerShell, Azure mobile app, IaC tools and REST API (create, update and delete operations)	1 October 2025 (phase 2, could be postponed to 1 July 2026)

Microsoft’s mandatory MFA documentation is blunt about it: break glass accounts must sign in with MFA once enforcement begins, and Conditional Access exclusions do not change that. A password-only break glass account cannot do admin work in the very portals it exists to rescue.

Microsoft’s recommended fix is passwordless: passkey (FIDO2) as the first choice, or certificate-based authentication if you already run a PKI. Both satisfy mandatory MFA, and both are phishing-resistant.

When will you actually need a break glass account?

Hopefully never. Microsoft lists the situations where it saves the day, and they are less exotic than you would think:

• A Conditional Access policy locks out every admin. The classic Friday afternoon special.
• Your admins’ MFA devices are lost, broken or unreachable, or the MFA service itself is having a bad day.
• Your accounts are federated and the identity provider is down.
• The last person with Global Administrator leaves, and their account is disabled or deleted on-premises.
• Every Global Administrator assignment is eligible in PIM, activation needs approval, and no approvers are left. Nobody can approve anybody, and tenant administration is effectively locked.

That last one is my favourite, in the way a horror film is somebody’s favourite. It is a perfectly sensible PIM design that quietly removes every escape route.

Before you start

What you need	Why
Global Administrator or Privileged Role Administrator	To create the accounts and assign the role
At least two FIDO2 security keys, ideally four	A passkey for each break glass account, plus a spare for each
Microsoft Entra ID P1 (included in Microsoft 365 Business Premium, E3 and E5)	Conditional Access, so you can exclude the accounts properly
A Log Analytics workspace receiving Entra sign-in logs	For the sign-in alert in step 6
Two secure, separate storage locations	Fireproof safes, not desk drawers

How to set up a break glass account in 7 steps

Step 1: Create two cloud-only break glass accounts

Two, not one. A single break glass account is a single point of failure with a safe attached.

1. Sign in to the Microsoft Entra admin centre as at least a User Administrator.
2. Go to Entra ID > Users > All users > New user > Create new user.
3. Use your .onmicrosoft.com domain for the user principal name, not your custom domain. If your domain or federation breaks, this account still works.
4. Give it a display name your team will recognise. I would avoid anything that shouts BreakGlass-GlobalAdmin at an attacker scrolling through your directory.
5. Do not sync it from on-premises Active Directory and do not federate it. The whole point is that it does not depend on anything else being alive.

Step 2: Assign Global Administrator as permanent active

Go to Entra ID > Roles & admins > Global Administrator > Add assignments and add both accounts.

If you use Microsoft Entra PIM, make the assignment active and permanent, not eligible. Eligible is lovely for normal admins. For the account you reach for when PIM itself is broken, it is like keeping the fire extinguisher in a box that only the fire brigade can open.

Step 3: Protect each break glass account with a passkey (FIDO2)

This is the step that replaces the password in a safe.

1. Go to Entra ID > Authentication methods > Policies.
2. Open Passkey (FIDO2), enable it, and target a group that contains your break glass accounts (or all users, if you are rolling passkeys out anyway).
3. Register a FIDO2 security key on each break glass account, then register a second key on each as a spare and store it somewhere else.

Use a different method from your everyday admin accounts. If your normal admins use Microsoft Authenticator, a FIDO2 key on the break glass account means one broken app or one lost phone cannot take out both. If you already run a PKI, certificate-based authentication is Microsoft’s other recommended option.

Step 4: Exclude the break glass account from Conditional Access that blocks sign-in

Create a security group called something like EmergencyAccess and add both accounts. Then exclude that group from every Conditional Access policy that blocks or restricts sign-in.

Microsoft’s wording has tightened here. Report-only policies do not block anything, so they do not need the exclusion. The passkey protects the account, whereas an enforced policy demanding a compliant device or a trusted location could stop it working in the exact emergency it exists for.

Run the Conditional Access What If tool against both accounts to confirm no enforced policy applies. It takes two minutes and is far cheaper than finding out during an outage.

One thing exclusions do not do: they do not exempt the account from mandatory MFA. That is fine, because the passkey already covers it.

Step 5: Store the credentials somewhere sensible

Two keys, two safes, two locations. Not two keys on the same lanyard in the drawer with the Christmas decorations.

• Use fireproof safes in separate, secure locations that more than one member of the admin team can reach.
• Keep a short runbook with each key: which account it belongs to, who to call, and what to do afterwards.
• Change safe combinations regularly, and straight away when someone with access leaves.
• Make sure the key or credential cannot expire or get caught by an automated clean-up for inactivity.

Microsoft also recommends using these accounts from a designated secure workstation, such as a Privileged Access Workstation. If that sounds like overkill, remember this account can do anything in your tenant.

Step 6: Alert on every break glass account sign-in

If this account signs in at 3am and nobody’s phone buzzes, you have not got a break glass account. You have got a very well hidden back door.

Send your Entra sign-in logs to a Log Analytics workspace, then create an Azure Monitor alert rule:

1. Copy the Object ID of each break glass account from Entra ID > Users.
2. In the Azure portal, go to Monitor > Alerts > Create > Alert rule and select your Log Analytics workspace as the scope.
3. Choose Custom log search and paste the query below, swapping in your own Object IDs.
4. Set the threshold to Greater than 0, the severity to 0 (Critical), and attach an action group that emails and texts more than one person.

SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

This catches failed sign-ins too, which is the point. A run of failures against a break glass account is either someone testing it or someone guessing at it, and you want to know which. Microsoft Sentinel can do the same job if you already use it.

Step 7: Test your break glass account every 90 days

An untested break glass account is Schrödinger’s admin. It both works and does not work, right up until the day you really need it.

Microsoft’s minimum is every 90 days, plus whenever IT staff or subscriptions change. Each test should cover:

• Telling your security team a test is happening, so the alert is not treated as a real incident.
• Signing in with each account and its passkey, and completing an admin task.
• Confirming the alert fired and reached the right people.
• Checking nobody has registered MFA or SSPR details to their own phone or email on the account.
• Reviewing who is authorised to use the accounts and who knows the safe combinations.
• Updating the runbook if anything has changed.

Put a recurring reminder in the team calendar. Every 90 days feels like a lot until you compare it with explaining to the head teacher why nobody can get into anything.

Break glass account gotchas

PIM eligibility. Covered above, but worth repeating: a permanent active assignment is one of the few exceptions PIM is designed to allow.

Identity Protection. Microsoft scheduled the legacy user risk and sign-in risk policies to retire on 1 October 2026 in favour of risk-based Conditional Access. Make sure your EmergencyAccess group is excluded from any new risk policies that block access.

Automation. Never use a break glass account for scripts or as a service account. Mandatory MFA will break it anyway, and an account that signs in all day turns your alert into background noise.

Tampering. Consider placing your break glass accounts in a restricted management administrative unit, so tenant-wide admins cannot quietly reset them.

Backups. Microsoft Entra Backup and Recovery can roll back a mangled Conditional Access policy, but somebody still has to sign in and press the button. That somebody is your break glass account.

Should you bother with a break glass account?

Yes. Two break glass accounts, a few security keys and an alert take under an hour to set up. Compare that with days waiting for support to verify you own your own tenant, while the whole organisation emails you from their personal Gmail.

If you only do three things today: replace any password-only break glass account with a passkey, check it is not caught by an enforced Conditional Access policy, and put a 90 day test in the calendar.

Then go and have a cup of tea. You have earned it.

Break glass account FAQs

Further reading

• Manage emergency access accounts in Microsoft Entra ID (Microsoft Learn)
• Mandatory multifactor authentication for Azure and admin portals (Microsoft Learn)
• Enable passkeys (FIDO2) for your organisation (Microsoft Learn)
• Create a resilient access control management strategy (Microsoft Learn)
• Entra ID phishing-resistant MFA: a staged rollout
• Conditional Access session controls

Found this useful? Buy me a coffee, and if you handle subject access requests, have a look at Redact Ninja for redacting PDFs without sending files to a server.