Break-Glass Accounts: Set Them Up Before You’re Locked Out
Microsoft Entra Conditional Access can protect an organisation extremely well.
It can require:
MFA
phishing-resistant authentication
compliant devices
trusted applications
specific authentication strengths
location or risk conditions
But the same controls can also create a serious problem.
A badly configured Conditional Access policy can lock out every administrator.
An identity provider can fail.
A compliant-device requirement can block every available admin workstation.
An MFA deployment can go wrong.
When that happens, you need an administrative identity that does not depend on the same controls that just failed.
That is the purpose of an emergency access account, commonly called a break-glass account.
Microsoft currently recommends maintaining at least two such accounts.
What Is a Break-Glass Account?
A break-glass account is a highly privileged Microsoft Entra identity reserved for genuine emergencies.
It should not be used for:
daily administration
Microsoft Teams
testing
ordinary support work
convenience
Its purpose is much narrower:
restore administrative access when normal administrators cannot sign in.
For example, you may need it if:
Conditional Access locks everyone out
federation fails
administrator authentication methods fail
device-compliance rules become unusable
a security incident disables normal admin identities
an authentication rollout breaks unexpectedly
Your existing article already explains this well; the rewrite mainly needs to make the implementation shorter and more operational.
Why You Need Two Emergency Accounts
One emergency account creates another single point of failure.
That account might become unusable because:
its credential is lost
its security key fails
the account is accidentally disabled
automation removes it
somebody mistakenly includes it in a Conditional Access policy
its physical credential becomes inaccessible
Microsoft therefore recommends two or more emergency access accounts.
The two accounts should not depend unnecessarily on the same:
authentication device
physical storage location
person
identity provider
recovery process
Think resilience, not duplication.
Two accounts whose security keys are sitting on the same keyring in the same office are not genuinely independent.
Use Cloud-Only Accounts
Microsoft recommends creating emergency accounts directly in Microsoft Entra ID using the tenant’s:
onmicrosoft.com
domain.
For example:
tenant-admin-4821@contoso.onmicrosoft.com
The account should not depend on:
on-premises Active Directory
Entra Connect synchronisation
AD FS
another federation provider
a third-party identity platform
Why?
Because an identity-system failure is one of the exact scenarios the emergency account is designed to survive.
Microsoft specifically recommends keeping cloud emergency access independent from on-premises emergency access.
Do Not Tie the Account to One Employee
The emergency account should not be:
john.smith@company.com
with John's mobile phone registered for authentication.
Microsoft says these accounts should not be associated with a specific individual and should not depend on employee-supplied devices such as personal phones.
That matters because John may be:
on holiday
ill
no longer employed
unreachable during the incident
The organisation owns the emergency identity.
Authorised administrators control access to it through an agreed recovery process.
Give It Global Administrator
A break-glass account must have enough authority to repair a tenant-wide lockout.
Microsoft recommends that the emergency identities hold the:
Global Administrator
role.
Normally, privileged access should be minimised and Microsoft Entra Privileged Identity Management should be used where appropriate.
Emergency access is a deliberate exception.
For these accounts, Microsoft currently recommends that Global Administrator be:
permanent active
rather than merely PIM-eligible.
Why?
Because PIM activation might itself depend on:
authentication
approvals
Conditional Access
services
that are unavailable during the emergency.
The account needs to work before you repair those dependencies.
Password-Only Break-Glass Accounts Are Outdated
This is the biggest change from older Microsoft 365 guidance.
Years ago, you frequently saw recommendations for an emergency account with:
very long password + no MFA
The reasoning was that MFA itself might fail.
That is no longer the right design.
Microsoft’s current guidance recommends passwordless, phishing-resistant authentication for emergency access accounts, specifically:
Passkey/FIDO2 — recommended
certificate-based authentication
These methods satisfy modern MFA requirements while giving the emergency account a recovery path that can be independent from the everyday Microsoft Authenticator experience.
FIDO2 Security Keys Are an Excellent Option
For many SMEs, physical FIDO2 security keys are probably the cleanest solution.
For example:
Emergency account 1
Cloud-only account
Global Administrator
FIDO2 security key
Stored in secure office safe
Emergency account 2
Cloud-only account
Global Administrator
Separate FIDO2 key
Stored securely at a second location
The important thing is not merely owning two keys.
Avoid creating common dependencies such as:
both keys in the same safe
or:
both emergency accounts registered to one administrator's phone.
The recovery design should survive loss of:
one person
one device
one location
where practical.
Exclude Emergency Accounts From Conditional Access
This is critical.
Suppose you create:
CA – Require Compliant Device for All Administrators
and include the break-glass accounts.
Then every compliant device becomes inaccessible because of an Intune problem.
Your emergency identities are now blocked by the same control you need them to repair.
Microsoft therefore recommends excluding emergency access accounts from Conditional Access policies that block or restrict sign-in.
That can include policies requiring:
compliant devices
particular MFA conditions
locations
authentication strengths
risk controls
device registration controls
Report-only Conditional Access policies do not block access, so Microsoft says they do not require the same exclusion.
Use an Emergency Access Group
Rather than manually excluding two usernames from every Conditional Access policy, create a dedicated group such as:
EmergencyAccess
Add only the approved emergency accounts.
Then explicitly exclude that group where appropriate.
Microsoft recommends this pattern because it makes the exception easier to:
identify
audit
maintain
verify.
Whenever creating a new Conditional Access policy, make checking the EmergencyAccess exclusion part of the deployment checklist.
Do Not Exclude All IT Staff
This is a common mistake.
You should not solve Conditional Access lockout risk by excluding:
IT department
all Global Administrators
all technical staff
That creates a much larger attack path.
Microsoft’s phishing-resistant admin policy guidance specifically recommends excluding emergency access identities—not casually exempting the entire administration team.
Normal administrators should remain strongly protected.
The break-glass account is the exception.
Store the Credentials Properly
An emergency account is useless if nobody can access its credential during the emergency.
It is dangerous if everybody can access it.
Microsoft recommends storing emergency credentials in secure, known locations available to authorised members of the administration team. For physical authentication devices, Microsoft gives examples such as secure fireproof safes in separate locations.
The documented recovery process should answer:
Where are the credentials?
Who is authorised to obtain them?
Who approves emergency use?
How is access recorded?
What happens after use?
Do not store the only recovery information solely inside:
SharePoint
Teams
the password vault
the same Microsoft 365 tenant
if that service might itself be inaccessible during the incident.
Monitor Every Sign-In
A properly configured emergency account should almost never be used.
That makes monitoring simple.
Normal activity should be:
zero.
Microsoft recommends generating a high-priority alert whenever an emergency access account signs in or is changed.
Monitor for:
successful sign-in
failed sign-in
credential changes
authentication-method changes
role changes
account disablement
group-membership changes
An unexpected break-glass sign-in is potentially a serious security incident.
Treat it accordingly.
Test the Accounts Every 90 Days
Do not assume the accounts work because they were configured last year.
Microsoft currently recommends validating emergency access accounts at least every 90 days.
A test should confirm:
1. Account still exists.
2. Account is enabled.
3. Global Administrator is still permanently active.
4. Authentication credential works.
5. Conditional Access does not block it.
6. Approved administrators can locate the credential.
7. Monitoring detects the test sign-in.
Then document the result.
Do not wait until a tenant-wide outage to discover:
the security key has disappeared.
Use a Secure Admin Workstation
Because these accounts have permanent Global Administrator access, they should not be signed into random PCs.
Microsoft’s current guardrails recommend using a designated secure workstation or Privileged Access Workstation when the emergency account is required.
That workstation should ideally be:
patched
trusted
security monitored
free of ordinary email/browsing activity
available during an incident
The account may be highly resilient to authentication failure.
That does not mean it should be exposed to a compromised endpoint.
Never Use the Account for Email
There should be no normal reason for a break-glass account to:
send email
receive routine mail
join Teams
access documents
browse SharePoint
Reducing ordinary activity helps in two ways.
First, it reduces exposure to:
phishing
malicious links
session theft
Second, it makes monitoring much clearer.
Any interactive activity becomes noteworthy.
What Happens During an Emergency?
Suppose a new Conditional Access policy accidentally locks every administrator out.
The response might be:
1. Confirm normal administrator access is genuinely unavailable.
2. Activate the organisation's emergency-access procedure.
3. Retrieve the authorised security key/credential.
4. Use the designated secure admin workstation.
5. Sign into the emergency account.
6. Identify the policy causing the lockout.
7. Disable, correct or revert it.
8. Verify ordinary administrator access.
9. Sign out of the emergency account.
10. Review Entra logs.
11. Document what happened.
12. Return the credential to secure storage.
The emergency account should be used for the minimum work necessary to restore normal administration.
Do not suddenly use it as the permanent admin account because:
“Well, we're already logged in.”
What If the Emergency Account Is Compromised?
Treat that as a critical identity-security incident.
Because it has permanent Global Administrator rights, compromise could give an attacker near-total control of the tenant.
Immediately investigate:
sign-in logs
audit logs
authentication-method changes
role assignments
Conditional Access changes
newly created identities
application consent
tenant configuration
Secure the other emergency account first so you preserve a recovery route.
Then replace or rotate compromised credentials according to the incident plan.
Break-Glass Accounts Are Not Service Accounts
Do not use emergency accounts for:
scripts
PowerShell automation
third-party connectors
scheduled jobs
application authentication
Microsoft distinguishes service principals and workload identities from human emergency access accounts. Normal automation should use suitable:
managed identities
service principals
workload identities
rather than permanent Global Administrator user credentials.
The emergency account should remain dormant.
Avoid Automatic Lifecycle Processes
Microsoft's current guidance also warns that emergency credentials and devices should not be allowed to expire or be removed by automated lifecycle processes.
Check that the accounts are not accidentally included in:
user expiration
inactive-account cleanup
HR leaver automation
security-key cleanup
access reviews intended for normal users
Automation should not quietly delete your recovery route because it noticed the account had not logged in for six months.
Its inactivity is intentional.
Build Emergency Access Before Changing Conditional Access
This is the rule I would put in a box if the blog design permits it:
Do not begin a major Conditional Access rollout until tested emergency access accounts exist.
Microsoft itself warns administrators to protect against tenant lockout before deploying stronger authentication policies.
The correct order is:
Create emergency accounts
↓
Protect them
↓
Exclude them appropriately
↓
Test them
↓
Configure alerting
↓
Then change Conditional Access
not the other way around.
A Practical Break-Glass Checklist
Before considering your emergency-access design complete, confirm:
1. At least two emergency accounts exist.
2. Both are cloud-only.
3. They use the tenant's onmicrosoft.com domain.
4. Neither belongs to an individual employee.
5. Both hold permanently active Global Administrator.
6. Both use phishing-resistant authentication.
7. Credentials are stored securely and independently.
8. Accounts are excluded from blocking/restrictive Conditional Access.
9. They are not used for ordinary administration.
10. Every sign-in generates an alert.
11. Automated cleanup cannot remove them.
12. A secure admin workstation is available.
13. The procedure is documented.
14. Accounts are tested at least every 90 days.
15. Test results and access are recorded.
The key principle is:
Your recovery account must not depend on the thing you are trying to recover.
How Hamilton Group Can Help
Microsoft Entra can provide extremely strong identity protection, but badly planned Conditional Access can also create operational lockout risk.
Hamilton Group can help businesses with:
Microsoft Entra ID
emergency access accounts
Conditional Access
phishing-resistant MFA
FIDO2 security keys
administrator security
Microsoft 365 hardening
Privileged Identity Management
identity monitoring
incident recovery
A break-glass account is something you hopefully never need.
But the correct time to find out whether it works is before every administrator is locked out of Microsoft 365.
Visit hgmssp.com or call 0330 043 0069 to discuss Microsoft 365 and identity security.