The engagement looked routine on paper. A customer was ready to convert their primary custom domain in Entra ID from managed to federated authentication — a migration we had done before with a well-documented process.
Before we changed a single setting, we mapped the failure modes. That is when we caught it. Their cloud administrator accounts were homed in a child domain, not the parent domain we were converting. By default, a child domain inherits its authentication settings from the parent. Federate the parent, and the child comes along with it. The moment the conversion completed, every cloud admin account in the tenant would have been redirected to an authentication endpoint that was not configured to handle them.
No Global Administrator access. No fallback. No way in through the normal front door.
We stopped and briefed the customer on what we had found before touching anything. Once they understood the implications, they approved two changes: reconfiguring the child domain to authenticate independently from the parent, and creating two proper break glass accounts. We built the accounts, tested them, confirmed they were excluded from every Conditional Access policy in the tenant, and secured the credentials. Knowing a change is safe is not the same as having a recovery path if something goes wrong.
Then we ran the conversion. It completed without incident. The customer was glad we had caught it before it became a problem.
I have described that scenario in conversations since, and the reaction is almost always the same: “I did not realize that was even a risk.” And then, almost always: “I am not sure we actually have break glass accounts.” That second response is the reason for this article.
Break glass accounts are among the most consistently skipped controls in Entra ID environments. Not because organizations do not take security seriously. Not because they are hard to configure. But because the failure they protect against is completely invisible right up until the moment it is not.
What Break Glass Accounts Are — and What They Are Not
A break glass account (Microsoft’s official term is emergency access account) is a cloud-only account permanently assigned the Global Administrator role in Entra ID. It is designed to remain accessible when all normal authentication paths are unavailable. Two accounts are the minimum. They are not assigned to any individual person. Their credentials are not stored in any system that depends on the tenant being healthy to access.
They are not a replacement for day-to-day admin accounts. If you are using a break glass account on a Tuesday afternoon to review a policy, something has gone wrong in your account governance model.
They are not a PIM-activated emergency role. This is one of the most common points of confusion. Privileged Identity Management requires a successful authentication to activate any role. If you cannot authenticate, PIM cannot help you. Break glass accounts exist precisely because PIM cannot.
They are not backup MFA accounts. A standard admin account with extra authentication methods registered is not a break glass account. If the MFA provider is the problem, additional registered methods on a standard account do not solve it.
Microsoft now enforces MFA at the portal level for all admin accounts, including emergency access accounts. There is no exemption. These accounts must be enrolled in a phishing-resistant MFA method. Attempting to configure break glass accounts without MFA will not work when you actually need them.
Why Most Organizations Don’t Have Them — or Think They Do
The organizations I encounter rarely say “we decided not to set up break glass accounts.” What they say is one of the following.
PIM is excellent for governing privileged access under normal conditions. It is not a substitute for break glass accounts. Activating a PIM-eligible role requires the user to authenticate first. If authentication is the problem, PIM is unavailable. The scenarios where break glass accounts matter most are exactly the scenarios where PIM-based access fails alongside everything else.
This addresses a real risk but it is not the same protection. If the MFA provider is experiencing an outage, backup methods registered through that same provider are affected. And Microsoft now enforces MFA at the portal level for all admin accounts, regardless of Conditional Access exclusions.
You can. But Microsoft’s process for recovering tenant access involves identity verification, escalation chains, and timelines measured in days, not hours. For an organization running production workloads in Azure or Microsoft 365, a multi-day administrative lockout is a multi-day operational problem. The call to Microsoft is a last resort, not a plan.
A shared admin account is not a break glass account unless it is specifically configured as one. Shared accounts are frequently enrolled in MFA through a shared phone or shared mailbox, which introduces the same failure modes as any individual account. The label does not make it safe. The configuration does.
Conditional Access exclusions are an important part of break glass configuration, but they do not address MFA provider outages, federation failures, or mandatory portal-level MFA enforcement. Exclusions are one layer. They are not the whole answer.
How to Configure Break Glass Accounts in Entra ID
This section covers the minimum viable configuration. Everything here reflects Microsoft’s current guidance for emergency access accounts.
Create two accounts, not one. Both should be named clearly so there is no ambiguity in an emergency: breakglass1@yourtenant.onmicrosoft.com and breakglass2@yourtenant.onmicrosoft.com. Use the *.onmicrosoft.com domain specifically — it resolves directly in Entra regardless of what else is failing.
Create two cloud-only accounts on *.onmicrosoft.com
Not synced from on-premises AD. Cloud-only accounts remain accessible even if your on-premises infrastructure fails.
Assign Global Administrator — active and permanent
Not eligible through PIM. In Entra Privileged Identity Management, set the role assignment as active permanent, not eligible. Eligible roles require authentication to activate.
Configure phishing-resistant MFA
FIDO2 security key is Microsoft’s recommended method. Use a different phishing-resistant method across the two accounts — if the FIDO2 key is the failure point, your second account should not share that dependency.
Exclude from every Conditional Access policy
This is intentional. Document the exclusion in each policy note so future administrators understand it is not an oversight.
Store credentials physically, in separate locations
Microsoft recommends secure, fireproof physical storage. Each account’s credentials should be in a different location, accessible to more than one authorized person — not in a password manager that requires Entra credentials to access.
Use authentication methods that differ from your regular admin accounts. If one method represents a single point of failure, your emergency access strategy inherits that failure. Distribute the risk across both accounts and both methods.
Monitoring — The Part Everyone Forgets
Expected sign-ins under normal conditions
Any activity on these accounts is either a planned test, a real emergency, or a potential compromise. All three demand an immediate response.
Configure an alert on sign-in activity for both accounts at the highest severity your monitoring tooling supports. Entra sign-in logs can feed into Azure Monitor, Log Analytics, Microsoft Sentinel, or your organization’s existing SIEM. The specific tool matters less than two non-negotiable requirements: the alert must fire on any sign-in, and it must notify more than one person.
That second requirement is easy to overlook. If your break glass alert only notifies the primary IT administrator, and that administrator is the one locked out during the emergency, the alert is not doing its job. Route notifications to at least two people, ideally including someone in security leadership.
Every time an alert fires, conduct a brief review: Was this a planned validation test? A response to an actual emergency? Or unexplained activity? If use was unauthorized or unexplained, treat it as a credential compromise and rotate the affected account immediately.
Testing — You Have to Actually Do It
Knowing you have break glass accounts is not the same as knowing they work. Accounts get misconfigured. MFA methods expire or get tied to a device that is no longer accessible. Conditional Access policies get updated and someone forgets to re-verify the exclusion. A break glass account that was properly configured eighteen months ago may not behave the same way today.
Microsoft recommends validating emergency access accounts at least every 90 days. At a minimum, each validation should confirm the following:
- Account signs in successfully using its configured authentication method
- MFA prompt completes without error
- No Conditional Access policy blocks or interrupts the sign-in
- Global Administrator role is active and accessible after sign-in
- Physical credentials or hardware keys are in their designated secure locations
- Authorized personnel list is current and reviewed
- Test result documented with date, tester, and outcome
Run the test from a workstation and network connection that differ from your normal administrative environment. You are simulating an emergency where your regular setup may not be available. A test that only works from your office on your usual laptop is telling you less than you think.
Break Glass Is One Layer, Not the Whole Answer
Break glass accounts are a recovery mechanism. They exist so that when something goes wrong with your normal access controls, you have a path back in. They are not a substitute for the controls themselves.
A properly configured Entra environment still needs Conditional Access policies built as a layered risk-based strategy, not a collection of static rules. It needs Privileged Identity Management governing day-to-day elevated access. It needs regular access reviews to catch privilege accumulation and stale assignments. And it needs a documented incident response process that includes the break glass procedure.
Break glass accounts give you a floor. The rest of your identity architecture determines how rarely you need it.