Every tenant with Conditional Access needs a way back in when something goes wrong: a policy that blocks every admin, an MFA outage, a federation server that falls over. That way back is an emergency access account in Entra, often called a break-glass account. Most tenants I review have one. Far fewer have one that would actually work on the day it is needed, because nobody has tested it, nobody watches it, and the credential is in a drawer nobody can find.
Why emergency access accounts matter
Microsoft lists several scenarios where normal admin accounts can fail at once:
Your admin accounts are federated and the identity provider is down.
Admins registered MFA only on phones, and a cellular outage or lost devices stop them from completing it.
The last person with Global Administrator access leaves, or their account is disabled on-premises and synced.
All privileged roles are PIM-eligible with approval required, and no active approver remains.
A Conditional Access change blocks every admin by mistake.
The last one is the most common in small businesses. One wrong include or exclude on a “block legacy authentication” or “require compliant device” policy can lock out the whole IT team. An emergency access account is how you undo it without a support ticket and a long wait.
How to set up break-glass accounts correctly
Microsoft’s current guidance is specific. Here is the setup I use.
Create two accounts, not one. Redundancy matters. If one credential is lost or one account breaks, the other still works.
Make them cloud-only. Use the *.onmicrosoft.com domain. Do not sync them from Active Directory and do not federate them, so an on-premises or federation problem cannot affect them.
Avoid obvious names. A name like “breakglass@” or “emergency@” advertises a high-value target. Use something non-obvious and document it securely.
Assign Global Administrator as permanent active. If you use Privileged Identity Management, these are the accounts that should not be eligible-only. Activation flows are exactly what may be broken during an emergency.
Use phishing-resistant authentication. Register a FIDO2 passkey (security key) or certificate-based authentication. These satisfy Microsoft’s mandatory MFA requirements for admin portals. Use methods that are different from your normal admin accounts, and never tie them to a personal phone or email.
Exclude them from blocking Conditional Access policies. Create a group such as “EmergencyAccess” and exclude it from any policy that blocks or restricts sign-in. Report-only policies do not need the exclusion.
Exclude them from automated cleanup. Make sure inactivity workflows, access reviews and password expiry do not disable or alter them.
Storing the credentials
The credential is the account. Treat it accordingly.
Store each FIDO2 key in a separate, secure, fireproof location, for example one in the office safe and one with a trusted principal off-site.
If a password exists, keep it long, random and stored offline, split between people if your policy requires dual control.
Keep a written list of who is authorized to retrieve and use each credential.
Change safe combinations regularly, and immediately after anyone with access leaves.
Avoid storing the only copy inside a system that depends on Microsoft 365 sign-in, such as a password manager you can only reach through your Entra account. If the tenant is what is broken, that store is broken too.
Monitoring every sign-in
An emergency access account should almost never sign in. That makes monitoring simple: any sign-in is worth an alert. Microsoft documents this approach using Azure Monitor.
Send Microsoft Entra sign-in and audit logs to a Log Analytics workspace using diagnostic settings.
Note the Object ID of each emergency access account from Entra ID > Users.
In the Azure portal, open Monitor > Alerts > Create > Alert rule, scope it to your workspace, and use a custom log search such as: SigninLogs | where UserId == "<object-id-1>" or UserId == "<object-id-2>"
Set the threshold to greater than 0, severity to critical, and evaluate every few minutes.
Attach an action group that emails and notifies your security contacts.
Also alert on audit events involving these accounts, such as role changes or authentication method changes. If you use Microsoft Sentinel, the same query works as an analytics rule. Every alert should lead to a short review: was this a planned test, a real emergency, or misuse? Preserve the logs either way.
Without a Log Analytics workspace, sign-in logs are kept for only 7 days on Entra ID Free and 30 days on P1 or P2, so exporting them is worth it on its own.
Testing: the step everyone skips
An untested break-glass account is a hope, not a control. Microsoft recommends validating these accounts at least every 90 days, and again when IT staff change or your subscriptions change.
Quarterly test checklist
Tell your security monitoring contacts a test is happening.
Retrieve the credential from storage using your documented process.
Sign in from a designated secure workstation and confirm you can reach the Microsoft Entra admin center.
Perform a harmless admin task, such as viewing Conditional Access policies.
Confirm the alert fired and reached the right people.
Check that nobody registered extra MFA methods or self-service password reset details on the account.
Review and update the list of authorized users and the written procedure.
Return the credential to storage and record the test date.
Setting
Recommended value
Number of accounts
At least two
Account type
Cloud-only, *.onmicrosoft.com
Role
Global Administrator, permanent active
Authentication
FIDO2 passkey or certificate-based authentication
Conditional Access
Excluded from blocking policies via a dedicated group
Monitoring
Alert on any sign-in and any audit change
Testing
At least every 90 days
The full guidance, including the monitoring queries, is in Microsoft’s article Manage emergency access accounts in Microsoft Entra ID. For regulated businesses, it also maps to HIPAA emergency access procedure requirements, which is useful evidence for healthcare IT audits.
Where break-glass fits in your wider identity design
Break-glass accounts are a safety net for everything else: Conditional Access, phishing-resistant MFA for admins, PIM. They let you enforce strict controls with confidence because you know there is a tested recovery path. It also helps to keep a short contingency plan next to the credentials: which policy to switch off first, who to call, and how to record what was changed. When people are stressed during an outage, a one-page procedure beats memory every time. If you are tightening MFA across the organization, our MFA enablement service sets up emergency access as part of the rollout, and the Microsoft 365 security assessment checks existing break-glass accounts against these settings.
Frequently asked questions
Do emergency access accounts need a Microsoft 365 license?
No product license is needed for an account to sign in and use admin roles. They do not need a mailbox, and keeping them unlicensed reduces their footprint. Monitoring them with Azure Monitor does need an Azure subscription for the Log Analytics workspace.
Should break-glass accounts be excluded from all Conditional Access policies?
Exclude them from any policy that blocks or restricts sign-in, including MFA, device compliance and location policies. The phishing-resistant method registered on the account protects it instead. Report-only policies can include them.
Can I use PIM for my emergency access accounts?
You can keep them visible in PIM, but their Global Administrator assignment should be permanent active rather than eligible. The point is to avoid any dependency on activation, approval or MFA flows that might be broken during an emergency.
Not sure your break-glass accounts would work tomorrow? Book a free Microsoft 365 security assessment and we will review the setup, exclusions and monitoring with you.
Every tenant with Conditional Access needs a way back in when something goes wrong: a policy that blocks every admin, an MFA outage, a federation server that falls over. That way back is an emergency access account in Entra, often called a break-glass account. Most tenants I review have one. Far fewer have one that would actually work on the day it is needed, because nobody has tested it, nobody watches it, and the credential is in a drawer nobody can find.
Why emergency access accounts matter
Microsoft lists several scenarios where normal admin accounts can fail at once:
The last one is the most common in small businesses. One wrong include or exclude on a “block legacy authentication” or “require compliant device” policy can lock out the whole IT team. An emergency access account is how you undo it without a support ticket and a long wait.
How to set up break-glass accounts correctly
Microsoft’s current guidance is specific. Here is the setup I use.
*.onmicrosoft.comdomain. Do not sync them from Active Directory and do not federate them, so an on-premises or federation problem cannot affect them.Storing the credentials
The credential is the account. Treat it accordingly.
Avoid storing the only copy inside a system that depends on Microsoft 365 sign-in, such as a password manager you can only reach through your Entra account. If the tenant is what is broken, that store is broken too.
Monitoring every sign-in
An emergency access account should almost never sign in. That makes monitoring simple: any sign-in is worth an alert. Microsoft documents this approach using Azure Monitor.
Entra ID > Users.Monitor > Alerts > Create > Alert rule, scope it to your workspace, and use a custom log search such as:SigninLogs | where UserId == "<object-id-1>" or UserId == "<object-id-2>"Also alert on audit events involving these accounts, such as role changes or authentication method changes. If you use Microsoft Sentinel, the same query works as an analytics rule. Every alert should lead to a short review: was this a planned test, a real emergency, or misuse? Preserve the logs either way.
Without a Log Analytics workspace, sign-in logs are kept for only 7 days on Entra ID Free and 30 days on P1 or P2, so exporting them is worth it on its own.
Testing: the step everyone skips
An untested break-glass account is a hope, not a control. Microsoft recommends validating these accounts at least every 90 days, and again when IT staff change or your subscriptions change.
Quarterly test checklist
The full guidance, including the monitoring queries, is in Microsoft’s article Manage emergency access accounts in Microsoft Entra ID. For regulated businesses, it also maps to HIPAA emergency access procedure requirements, which is useful evidence for healthcare IT audits.
Where break-glass fits in your wider identity design
Break-glass accounts are a safety net for everything else: Conditional Access, phishing-resistant MFA for admins, PIM. They let you enforce strict controls with confidence because you know there is a tested recovery path. It also helps to keep a short contingency plan next to the credentials: which policy to switch off first, who to call, and how to record what was changed. When people are stressed during an outage, a one-page procedure beats memory every time. If you are tightening MFA across the organization, our MFA enablement service sets up emergency access as part of the rollout, and the Microsoft 365 security assessment checks existing break-glass accounts against these settings.
Frequently asked questions
Do emergency access accounts need a Microsoft 365 license?
No product license is needed for an account to sign in and use admin roles. They do not need a mailbox, and keeping them unlicensed reduces their footprint. Monitoring them with Azure Monitor does need an Azure subscription for the Log Analytics workspace.
Should break-glass accounts be excluded from all Conditional Access policies?
Exclude them from any policy that blocks or restricts sign-in, including MFA, device compliance and location policies. The phishing-resistant method registered on the account protects it instead. Report-only policies can include them.
Can I use PIM for my emergency access accounts?
You can keep them visible in PIM, but their Global Administrator assignment should be permanent active rather than eligible. The point is to avoid any dependency on activation, approval or MFA flows that might be broken during an emergency.
Not sure your break-glass accounts would work tomorrow? Book a free Microsoft 365 security assessment and we will review the setup, exclusions and monitoring with you.