Every Microsoft 365 tenant can lock itself out. A Conditional Access policy with a typo, an expired federation certificate, an MFA outage, or the only Global Administrator leaving the company — any of these can leave nobody able to sign in to the admin portals. An emergency access account, usually called a break-glass account, is the spare key for that moment.
Microsoft's guidance on emergency access is clear about the goal: a small number of highly privileged accounts that are rarely used, strongly protected, and always able to sign in when everything else fails. Here is how to set them up properly.
What a break-glass account is (and is not)
A break-glass account is a Global Administrator account that belongs to no person and exists only for emergencies. It is not:
- an admin's second account for "just in case" daily use;
- a shared admin login for the IT team;
- a service account for an application.
If anyone signs in with it on a normal day, something is wrong.
How many to create
Create at least two. One account is a single point of failure: if its credential is lost, damaged or locked, you have nothing. Two accounts, protected by different methods and stored in different places, survive almost any single failure.
How to set them up
1. Make them cloud-only. Create them directly in Microsoft Entra ID using the tenant's initial *.onmicrosoft.com domain — for example emergency-a@contoso.onmicrosoft.com. Do not sync them from on-premises Active Directory and do not federate them. If your on-premises directory, sync server or federation service is the thing that broke, a synced or federated account breaks with it.
2. Give them Global Administrator permanently. An emergency account must not depend on activating a role through Privileged Identity Management (PIM) at the worst possible moment. Assign the role as a permanent, active assignment.
3. Tie them to no person. Use neutral names, no personal mailbox, no personal phone number. When an admin leaves, the emergency accounts should not need to change.
4. Protect them with phishing-resistant MFA. Microsoft now requires multifactor authentication to sign in to its admin portals, so an emergency account that cannot complete MFA may not be able to reach the portals at all. Register FIDO2 security keys (or certificate-based authentication) for each account, and keep them separate: different keys, stored in different secure locations. Avoid SMS and voice for these accounts.
5. Keep at least one out of a Conditional Access lockout. The most common way tenants lock themselves out is a Conditional Access policy that applies to everyone, including every admin. Exclude your emergency accounts from Conditional Access policies that could block them — most simply by putting them in a dedicated group (for example Emergency Access) and excluding that group from every policy. Review each new policy against this rule before you enforce it. For the policies themselves, see our Conditional Access baseline.
6. Store the credentials like the keys to the building. A security key in a safe, a second in a different office or with a trusted officer, and a documented process for who may retrieve them and when.
Monitor every sign-in
Because these accounts should never be used on a normal day, any sign-in is an alert. Send the Entra sign-in logs to Log Analytics (or your SIEM) and create an alert that fires whenever one of the emergency accounts signs in. Investigate each one.
Test them on a schedule
An emergency account you have never tested is a hope, not a plan. At least every 90 days — and after any change to Conditional Access, MFA methods or admin staff:
- sign in with each account and confirm it reaches the Entra admin center;
- confirm its MFA method still works;
- confirm the alert fired;
- confirm it is still excluded from every enforced Conditional Access policy.
Common mistakes we see
- Only one emergency account, or none at all.
- Synced emergency accounts that fail together with the on-premises directory.
- Emergency accounts that also cover daily work, which defeats both the monitoring and the point.
- A new Conditional Access policy that forgot the exclusion — the lockout often happens months after the accounts were set up.
- Too many Global Administrators. Emergency accounts are the exception, not a reason to keep ten people on Global Administrator. Give daily admins the narrower roles they need.
How TenantVigil checks this
TenantVigil's assessment looks at the pieces that make emergency access work:
- whether your Conditional Access policies leave out any accounts at all, which is where break-glass accounts usually show up (CIS-1.2.2);
- how many people hold Global Administrator compared with narrower admin roles;
- whether your privileged accounts are cloud-only rather than synced from on-premises (CISA MS.AAD.7.3).
TenantVigil plans Conditional Access changes around the same rule: a new policy starts in report-only mode, always leaves out the admin applying it and the emergency accounts that all your enforced policies already exclude, and the change is refused if no such account can be found. TenantVigil only reads your Microsoft 365 tenant. It never changes a setting: you apply each fix yourself. Before a Conditional Access change can run, the Microsoft callback and permission setup for that sender must be complete.
Start free to see where one Microsoft 365 tenant stands. The Free plan requires a Microsoft work-account sign-in and administrator consent and covers one tenant. For the details of what TenantVigil reads and how, see the permission model.
Further reading: Microsoft's guide to managing emergency access accounts in Microsoft Entra ID.