Break-Glass Accounts: Setting Them Up Before You’re Locked Out

2 Aug 2026

A Microsoft 365 or Microsoft Entra administrator can be locked out for several reasons.

A Conditional Access policy may be configured incorrectly. An identity provider may fail. An administrator may lose access to their authentication device. A device-compliance rule may block every available computer. A phishing-resistant authentication rollout may go wrong.

When normal administrator accounts cannot sign in, the organisation needs a separate recovery route.

That route is provided by an emergency access account, commonly called a break-glass account.

A break-glass account is a highly privileged identity reserved for genuine emergencies. It should not be used for routine administration, email, testing or convenience. Its purpose is to restore access when the controls protecting ordinary administrators are also preventing legitimate recovery.

Microsoft recommends maintaining at least two cloud-only emergency access accounts, using strong authentication that does not depend on the same methods as normal administrator accounts, excluding the accounts from Conditional Access restrictions that could cause lockout, monitoring every use and testing them at least every 90 days.

This guide explains how to create, protect, monitor and test break-glass accounts before your organisation needs them.

What Is a Break-Glass Account?

A break-glass account is an emergency administrative identity used when normal access methods are unavailable.

The phrase comes from physical emergency equipment stored behind glass: it should be accessed only when ordinary procedures cannot solve the problem.

In Microsoft Entra ID, a break-glass account may be needed when:

A Conditional Access policy locks out all administrators
Multi-factor authentication services or methods are unavailable
A federated identity provider fails
Device-compliance rules block every administrator
Authentication methods are removed accidentally
A tenant configuration change prevents normal sign-in
An administrator’s account is compromised or disabled
The organisation needs urgent cloud access during an outage
A security incident requires recovery through an independent identity

Emergency access accounts normally hold the Global Administrator role because they must be capable of repairing tenant-wide identity and access problems. Their use should be limited to the shortest time genuinely necessary.

Why Break-Glass Accounts Matter

Conditional Access is powerful because it can require:

MFA
Phishing-resistant authentication
Compliant devices
Approved applications
Trusted network conditions
Specific authentication strengths
Restricted sessions

The same controls can also cause a tenant-wide lockout when they are misconfigured.

For example, an administrator may create a policy that:

Includes all users
Targets all resources
Requires a compliant device
Includes every administrator
Applies immediately
Does not exclude an emergency account

When no administrator currently has a compliant device, nobody can sign in to correct the policy.

Microsoft therefore recommends excluding emergency access accounts from Conditional Access policies that block or restrict access. It also recommends verifying these exclusions during Conditional Access planning.

Without a working emergency identity, the organisation may need Microsoft support to intervene. That can delay recovery during a serious outage or security incident.

Why You Need at Least Two Emergency Accounts

One emergency account is better than none, but it still creates a single point of failure.

The account could become unusable because:

Its credential is lost
Its authentication device fails
Its security key is damaged
The account is deleted accidentally
The account is included in a policy unexpectedly
The account is disabled by automation
Its authentication certificate expires
Its credential storage location becomes inaccessible

Microsoft recommends maintaining at least two emergency access accounts for redundancy.

The two accounts should not depend on exactly the same:

Authentication device
Physical storage location
Employee
Identity provider
Credential type
Recovery procedure

The objective is genuine independence.

Use Cloud-Only Accounts

Emergency access accounts should normally be created directly in Microsoft Entra ID using the tenant’s .onmicrosoft.com domain.

For example:

emergency-admin-01@yourtenant.onmicrosoft.com

emergency-admin-02@yourtenant.onmicrosoft.com

Do not make the emergency account dependent on:

On-premises Active Directory
Active Directory Federation Services
A third-party federation provider
Synchronisation from a local directory
An external identity platform
A normal employee mailbox
An employee’s personal account

Microsoft advises keeping cloud emergency access separate from on-premises emergency access and avoiding dependencies on other identity systems that may be involved in the outage.

If the failure affects the federated identity provider, a federated emergency account may fail at exactly the same time as every normal administrator account.

Do Not Name the Account Too Obviously

A username such as:

breakglass@company.com

is easy for an attacker to identify.

Use a name that administrators can document and recognise internally without advertising its purpose publicly.

For example:

cloud-recovery-7281@yourtenant.onmicrosoft.com

tenant-ops-9456@yourtenant.onmicrosoft.com

Do not hide the account so thoroughly that authorised staff cannot identify it during an emergency. The account should be clearly recorded in the internal recovery documentation.

The important distinction is between documented internally and obvious to an attacker.

Assign the Required Administrative Role

A break-glass account must have enough authority to repair the problem.

For most Microsoft Entra emergency-access designs, this means assigning the Global Administrator role.

The role should be:

Permanently active
Assigned directly to the emergency account
Available without requiring Privileged Identity Management activation
Restricted to emergency use

Microsoft advises making the Global Administrator assignment permanently active rather than merely eligible through Privileged Identity Management. An account that requires PIM activation may depend on the same policies, authentication services or approvals that are failing.

This permanent privilege is a risk, which is why the account must be strongly protected and continuously monitored.

MFA Is Now Required for Emergency Accounts

Older break-glass guidance sometimes suggested keeping one emergency account outside MFA requirements.

That approach is no longer suitable for Microsoft management access.

Microsoft’s mandatory MFA enforcement includes emergency access accounts. Microsoft recommends configuring them with passkeys using FIDO2 or certificate-based authentication so they meet the MFA requirement while remaining independent of ordinary administrator authentication methods.

The correct design is not:

Create an administrator account with only a password.

It is:

Create a strongly authenticated emergency account whose authentication route remains usable during the failures your normal administrators may experience.

Use Phishing-Resistant Authentication

Suitable authentication methods may include:

FIDO2 hardware security keys
Device-bound passkeys
Certificate-based authentication
Smart cards in appropriate environments

Microsoft recommends strong authentication that differs from the method used by normal administrator accounts. For example, when ordinary administrators depend on Microsoft Authenticator, emergency accounts might use separately stored FIDO2 security keys.

Avoid making every administrator and emergency account depend on:

The same mobile provider
The same authenticator application
The same device-management platform
The same certificate authority without contingency planning
One physical security key
One employee’s phone

Diversity helps prevent a single failure from disabling every administrative identity.

Use Separate Authentication Methods for Each Account

A strong two-account design might look like this:

Emergency Account One

Cloud-only identity
Global Administrator
FIDO2 security key
Key stored in a secure office safe
Backup key stored separately

Emergency Account Two

Cloud-only identity
Global Administrator
Certificate-based authentication or a separate FIDO2 key
Credentials stored at another secure location
Authorised to a different small group of senior staff

The exact arrangement depends on the organisation’s size, geography and risk.

The key principle is that losing one key, one safe or one office should not remove every recovery option.

Do Not Use SMS as the Primary Emergency Method

SMS and voice calls may fail because:

The phone is unavailable
The mobile provider has an outage
The number has changed
The SIM is compromised
The employee has left
The account recovery process is socially engineered
The organisation is responding from another location

A FIDO2 security key or well-designed certificate-based method is generally more suitable for a high-value emergency account.

Emergency authentication should be resistant to phishing and should not depend on a personal phone.

Exclude the Accounts From Conditional Access Restrictions

Emergency access accounts should be excluded from Conditional Access policies that could stop them signing in.

These commonly include policies that:

Require compliant devices
Require hybrid-joined devices
Restrict network locations
Block selected countries
Require approved applications
Require specific authentication flows
Restrict administrative portals
Enforce session controls
Block users based on risk
Require controls unavailable during an outage

Microsoft explicitly recommends excluding emergency access accounts from Conditional Access policies that block or restrict sign-in. Report-only policies do not actively block access and therefore do not require the same exclusion.

The exclusion does not mean the account should be weak.

The account should still satisfy Microsoft’s mandatory MFA requirements through a strong independent authentication method.

Check Every Conditional Access Policy

Do not assume that excluding the accounts from one baseline MFA policy is sufficient.

Review every policy, including:

All-user MFA
Administrator protection
Compliant-device policies
Location restrictions
Guest policies
Sign-in-risk policies
User-risk policies
Authentication-strength policies
Device code restrictions
Security-information registration
Microsoft-managed policies
Application-specific policies

The exclusion should be checked whenever a policy is:

Created
Edited
Duplicated
Replaced
Converted from report-only to active
Introduced by Microsoft-managed policy changes

Microsoft’s Conditional Access deployment guidance specifically advises verifying that emergency access accounts are excluded from all policies before broad deployment.

Use a Dedicated Exclusion Group Carefully

Some organisations create a group such as:

CA-Emergency-Access-Exclusions

The two break-glass accounts are added to the group, and the group is excluded from relevant policies.

This makes exclusions easier to manage consistently.

However, the group itself becomes highly sensitive.

Protect it by:

Limiting who can change membership
Alerting on membership changes
Reviewing membership regularly
Preventing normal users or administrators from being added casually
Recording the expected member count
Investigating every change

An attacker who adds their account to the emergency exclusion group may bypass important access controls.

Microsoft recommends monitoring privileged account activity, including group membership and application-assignment changes.

Prevent Automated Cleanup

Emergency accounts are intentionally inactive most of the time.

That inactivity can cause them to be targeted by automated processes that:

Disable unused accounts
Remove unlicensed users
delete dormant identities
Remove inactive authentication methods
Expire credentials
Remove old devices
Revoke unused role assignments

Microsoft advises ensuring that emergency account credentials and devices do not expire or become subject to automated cleanup merely because they are unused.

Add the accounts to documented exclusion lists for any lifecycle automation that could disable them.

Review these exclusions whenever identity-governance processes change.

Do Not Assign a Normal Mailbox

An emergency account generally does not need:

Exchange Online
Teams
OneDrive
A normal Microsoft 365 licence
Collaboration access
Everyday application assignments

Adding a mailbox increases the attack surface and encourages misuse.

The emergency identity should not:

Receive ordinary email
Be used to browse the web
Open attachments
Join Teams meetings
Store business documents
Be used as a shared administrator identity
Run automated jobs

Its purpose is narrow: recover administrative access.

Store Credentials Securely

Break-glass credentials should be available during an emergency but inaccessible during ordinary work.

Microsoft recommends storing credentials or authentication devices in secure, fire-resistant safes located separately.

Possible storage arrangements include:

A sealed FIDO2 key in a fire-rated safe
A second key in another secured office
A controlled physical envelope with tamper evidence
A secure enterprise password vault with emergency procedures
Separate custody shared between authorised senior personnel

Avoid storing credentials in:

Email
OneNote
An ordinary Word document
A shared spreadsheet
A Teams channel
A standard password manager vault accessible to many employees
The same laptop used for normal administration
An IT technician’s desk drawer

The storage process should survive:

Staff absence
Office closure
Device failure
A cybersecurity incident
Loss of normal identity systems
Loss of one physical site

Use Dual Control Where Appropriate

For sensitive organisations, consider requiring two authorised people to access an emergency credential.

For example:

One manager controls the safe
Another controls the sealed authentication key
Use requires both individuals
Every opening is logged
The credential is resealed after testing

This reduces the risk of one person using the account without oversight.

The process must not be so slow that it prevents urgent recovery.

Balance control with practical availability.

Define Who Is Authorised to Use the Accounts

Document a very small list of authorised users.

This may include:

IT director
Head of security
Senior Microsoft 365 administrator
Managed service provider escalation lead
Business continuity manager

For each person, document:

Full name
Role
Contact details
Which account they may use
Which credential location they may access
Who approves use
Who must be informed
What evidence must be recorded afterward

Review the authorised list whenever staff:

Leave
Change roles
Lose administrative responsibility
Change employer
Move between service providers

Use a Secure Administrative Workstation

Do not use an emergency account on a random personal computer.

Microsoft advises using a designated secure workstation or privileged access environment for emergency account use.

The recovery workstation should ideally be:

Company controlled
Fully patched
Encrypted
Protected by endpoint security
Free from routine email and web browsing
Stored securely
Tested regularly
Available independently from normal administrator devices

You may maintain:

A dedicated privileged access workstation
A secured spare laptop
A preconfigured emergency virtual desktop
A documented clean-device deployment process

The device must not depend entirely on the same compliance policy that may have caused the lockout.

Monitor Every Sign-In

A break-glass account should almost never be used.

Any sign-in is therefore significant.

Microsoft recommends monitoring all sign-in and audit activity for emergency access accounts and generating alerts whenever they are used. Azure Monitor, Microsoft Sentinel or another monitoring platform can trigger email or SMS notifications.

Alert on:

Successful sign-ins
Failed sign-ins
Password changes
Authentication-method changes
Role changes
Group membership changes
Application assignments
Account enable or disable actions
Credential additions
Conditional Access exclusion changes

Every unexpected event should be investigated immediately.

Send Alerts to More Than One Person

Do not send emergency-account alerts only to the person who normally manages Conditional Access.

Send alerts to a group containing several responsible people, such as:

IT management
Security operations
Managed service provider escalation team
Compliance lead
Senior technical administrators

An attacker may compromise or disable one recipient.

Multiple recipients increase the likelihood that suspicious activity will be noticed quickly.

Test the Accounts at Least Every 90 Days

An emergency account that was created two years ago and never tested cannot be trusted.

Microsoft recommends validating emergency access accounts at least every 90 days. The review should include testing sign-in, confirming administrative capability and reviewing the authorised-user list.

A test should confirm:

The account still exists.
The account is enabled.
The authentication method works.
The physical key or certificate is accessible.
The Global Administrator role remains assigned.
Conditional Access does not block the account.
Mandatory MFA requirements are satisfied.
Alerts are triggered.
The secure workstation is available.
The account can perform a harmless administrative task.
The authorised-user list is current.
The test is documented.

Do not wait for a real lockout to discover that the key no longer works.

Use a Harmless Test Procedure

A validation drill should not make unnecessary production changes.

A safe test might involve:

Retrieve the credential through the approved procedure.
Sign in using the secure emergency workstation.
Confirm that the expected alert is generated.
Open the Microsoft Entra admin centre.
Review a read-only tenant setting.
Confirm that Global Administrator privileges are present.
Sign out.
Revoke or close the session if required by procedure.
Return and reseal the authentication device.
Record the test result.

Do not use the account to perform normal maintenance simply because it is already open.

Test the Monitoring During Every Drill

A successful sign-in without an alert indicates that part of the emergency design has failed.

During testing, confirm:

The sign-in appears in logs.
The alert triggers promptly.
The correct people receive it.
The alert includes enough information.
The incident process begins as expected.
The test can be distinguished from unauthorised use.
The monitoring team knows the test was scheduled.

Testing the account and testing the alerting should happen together.

Document When the Account May Be Used

Define acceptable emergency scenarios.

Examples include:

Every normal Global Administrator is locked out.
Conditional Access prevents all administrator access.
Normal authentication methods are unavailable.
Federation is down.
An urgent security incident requires independent recovery access.
The normal privileged access platform has failed.

Examples that normally do not justify use include:

An administrator finds MFA inconvenient.
A technician needs temporary Global Administrator rights.
A routine change is urgent.
A normal administrator forgot their password.
A script needs elevated access.
A supplier wants shared credentials.
Someone wants to test a portal quickly.

The account should not become a shortcut around security controls.

Create an Emergency Use Checklist

When the account is needed, follow a documented procedure.

Before Sign-In

Confirm the incident qualifies as an emergency.
Obtain the required approval.
Record the reason and time.
Confirm which emergency account will be used.
Use the designated secure workstation.
Notify monitoring personnel.

During Use

Sign in only to required administrative services.
Make the smallest necessary change.
Record every action.
Avoid email, browsing and unrelated administration.
Maintain communication with the incident lead.
Stop using the account as soon as normal access is restored.

After Use

Sign out of every session.
Revoke active sessions where appropriate.
Review all audit activity.
Rotate or replace credentials when the situation warrants it.
Inspect the workstation.
Restore and reseal physical credentials.
Conduct a post-incident review.
Update the recovery procedure.

Rotate Credentials After Suspicious Use

Routine testing does not always require replacing a FIDO2 key or certificate.

However, credentials should be rotated or reissued when:

The key may have been exposed
The safe was accessed unexpectedly
The account may have been compromised
An unauthorised person handled the credential
The account was used during a security incident
Audit records are incomplete
The device is lost or damaged
An authorised custodian leaves

After rotation, retest the account and monitoring process.

Do Not Share One Password Informally

Break-glass accounts are sometimes weakened by informal sharing.

Examples include:

Several technicians know the password.
The password is stored in a group chat.
An MSP and customer both keep uncontrolled copies.
The password never changes because “someone may need it.”
Nobody knows who last accessed it.

Use controlled custody and auditable retrieval.

The organisation should be able to answer:

Who accessed the credential?
When?
Why?
Who approved it?
What was changed?
Was the credential secured afterward?

Keep MSP and Customer Responsibilities Clear

When a managed service provider supports the tenant, agree:

Who owns the accounts
Who may use them
Where credentials are stored
Whether the customer and MSP each hold a separate account
Who receives alerts
Who approves emergency use
What happens when the contract ends
How access is transferred
How tests are recorded

Do not let the emergency process depend solely on one external provider.

The customer organisation should retain a recovery route appropriate to its governance and risk.

Protect Against Insider Misuse

A permanently active Global Administrator account is powerful.

Reduce insider risk through:

Restricted credential custody
Dual approval
Immediate sign-in alerts
Audit-log monitoring
Secure workstations
Clear authorised-user lists
Tamper-evident storage
Regular review
Post-use investigation

Every use should be treated as an event requiring explanation.

Common Break-Glass Account Mistakes

Creating Only One Account

One failed key or deleted user can remove the recovery route.

Using the Company’s Normal Domain

A federated or synchronised domain may depend on the failed identity system.

Using Only a Password

Microsoft’s mandatory MFA enforcement now covers emergency access accounts used for protected management access.

Using the Same MFA Method as Every Administrator

One service or device failure may disable all accounts simultaneously.

Including the Account in Conditional Access

The emergency account may be blocked by the policy it needs to repair.

Excluding the Account From Monitoring

The most privileged account becomes the least visible.

Allowing Credential Expiry

The organisation discovers the expired credential during an emergency.

Never Testing the Account

The design exists only on paper.

Giving the Account a Mailbox

This creates unnecessary exposure and encourages routine use.

Using It for Scheduled Tasks

The account can no longer be treated as dormant or exceptional.

Storing Both Credentials Together

A single theft, fire or access failure removes both recovery options.

Giving Too Many People Access

Accountability disappears.

Failing to Update the Procedure

Staff and storage locations change, but the documentation does not.

Break-Glass Account Setup Checklist

Identity

Create at least two accounts.
Use cloud-only .onmicrosoft.com identities.
Avoid obvious public names.
Do not attach ordinary mailboxes.
Assign permanent Global Administrator access.
Exclude the accounts from automated inactivity cleanup.

Authentication

Configure phishing-resistant MFA.
Use methods independent of normal administrators.
Keep separate credentials for each account.
Ensure credentials do not expire unexpectedly.
Maintain spare hardware keys where appropriate.

Conditional Access

Exclude emergency accounts from blocking or restrictive policies.
Review every policy.
Check Microsoft-managed policies.
Protect the exclusion group.
Alert on exclusion changes.

Storage

Store credentials in secure, fire-resistant locations.
Separate the two accounts physically where possible.
Limit authorised custodians.
Use tamper evidence.
Document retrieval procedures.

Monitoring

Alert on every successful sign-in.
Alert on failed sign-ins.
Monitor authentication-method changes.
Monitor role and group changes.
Send alerts to several responsible people.
Retain logs according to business and compliance requirements.

Testing

Test at least every 90 days.
Verify the sign-in method.
Verify Global Administrator access.
Verify Conditional Access exclusions.
Verify alerts.
Test the secure workstation.
Review authorised users.
Document every test.

A Practical Two-Account Example

Cloud Recovery Account A

tenant-recovery-7421@contoso.onmicrosoft.com

Configuration:

Cloud-only
Global Administrator
FIDO2 security key
Primary key in headquarters safe
Spare key in secondary secure location
Excluded from restrictive Conditional Access
Alert on every sign-in and account change

Cloud Recovery Account B

tenant-operations-9164@contoso.onmicrosoft.com

Configuration:

Cloud-only
Global Administrator
Separate FIDO2 key or certificate-based authentication
Stored at a different site
Different authorised custodians
Excluded from restrictive Conditional Access
Independent alerting and quarterly testing

Both accounts:

Have no mailbox
Are not used for scripts
Are not used for everyday work
Are tested every 90 days
Have documented emergency procedures
Generate immediate security alerts

What to Do When You Are Already Locked Out

When no emergency account exists or none works:

Confirm whether another authorised Global Administrator can sign in.
Try a known compliant or previously used administrative device.
Check whether the problem affects one account or the entire tenant.
Review any available sign-in error details.
Avoid repeated unplanned policy changes from partially working sessions.
Open a Microsoft support case through an available organisational support route.
Preserve screenshots, error codes and relevant timestamps.
After recovery, create and validate proper emergency access accounts immediately.

Microsoft support may need to intervene when every administrator is locked out and no usable break-glass account exists.

Do not postpone emergency-account setup because the tenant currently appears healthy.

That is precisely when the work should be completed.

Final Thoughts

Break-glass accounts are easy to ignore because they are designed for situations that should rarely occur.

That does not make them optional.

Conditional Access, phishing-resistant MFA, device compliance and privileged access controls all improve security—but they also create dependencies. A mistake or outage involving those dependencies can block legitimate administrators along with attackers.

A properly designed emergency-access strategy provides a controlled route back into the tenant.

Create at least two cloud-only accounts. Assign the authority required for recovery. Use independent phishing-resistant authentication. Exclude the accounts from Conditional Access restrictions that could cause lockout. Store the credentials securely in separate locations. Monitor every sign-in and change.

Most importantly, test the complete process at least every 90 days.

A break-glass account that has never been tested is not a recovery plan. It is an assumption.

Worried Your Microsoft 365 Tenant Has No Reliable Recovery Route?

Hamilton Group can help you design and validate emergency access for Microsoft Entra ID and Microsoft 365.

Our experts can help you:

Create cloud-only emergency administrator accounts
Configure phishing-resistant authentication
Review Conditional Access exclusions
Protect emergency credentials and security keys
Configure sign-in and audit alerts
Build a quarterly validation procedure
Review Global Administrator assignments
Secure privileged administration workstations
Document emergency-use and recovery processes
Test your tenant-lockout response
Review Microsoft 365 identity security more broadly

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to make sure your emergency access works before you need it.

Previous Next