Break-Glass Accounts in Microsoft Entra ID: How to Set Them Up Properly

There is a particular feeling you get as an IT administrator when you realise nobody can log in.

You try your normal administrator account.

Denied.

You try another administrator.

Same result.

Then someone asks the question that matters:

“Does the break-glass account work?”

I’ve been fortunate that I haven’t had to use one in anger during a tenant-wide lockout. And, to be honest, that’s exactly how it should be. A break-glass account isn’t something I want to use regularly. It’s the account I want sitting quietly in the background, properly secured and ready for the one day something goes badly wrong.

What I have seen, however, are environments where emergency access hasn’t been designed properly. Accounts have been synchronised from on-premises Active Directory, authentication depends on the same infrastructure as normal administrators, credentials aren’t easily accessible, or Conditional Access policies have been configured without properly considering the emergency account.

That is where the real problem lies.

A break-glass account isn’t simply another Global Administrator with a complicated password. It is an alternative path back into Microsoft Entra ID when the normal administrative access path has failed.

And that means it needs to be designed differently from your everyday administrator accounts.

Why Do You Need a Break-Glass Account?

The obvious answer is “in case you get locked out”.

The more useful question is:

What could actually cause your normal administrative access to stop working?

There are plenty of possibilities.

A Conditional Access policy could be configured incorrectly and block administrators.

An authentication policy could require a method your administrators don’t have available.

An identity provider or federation service could become unavailable.

Your administrators could lose access to their authentication devices.

The last usable Global Administrator account could be disabled or otherwise become unavailable.

Even a perfectly legitimate change to your privileged-access model could leave you with no active administrator capable of making the next change.

Microsoft’s emergency access account guidance identifies scenarios such as federation outages, unavailable MFA devices or services, loss of the last Global Administrator, and PIM configurations where no active approver is available as reasons for maintaining emergency access accounts.

This is particularly relevant in hybrid environments.

If your normal administrator account depends on Active Directory, Entra Connect, federation, Conditional Access, MFA and a managed device, that’s a lot of dependencies sitting between you and the Microsoft 365 admin centre.

The emergency account should have fewer.

That is the fundamental principle behind the design.

Your emergency access path shouldn’t depend on the system that has just failed.

Microsoft now calls these emergency access accounts, although most administrators still refer to them as break-glass accounts.

The Mistake I See Most Often

The traditional break-glass design was relatively straightforward.

Create a Global Administrator account, give it a long random password, exclude it from MFA and Conditional Access, and store the password somewhere secure.

That advice is showing its age.

Microsoft’s mandatory MFA enforcement applies to break-glass and emergency access accounts when they sign in to the affected Microsoft admin applications. Microsoft recommends updating emergency accounts to use passkey (FIDO2) or certificate-based authentication rather than relying on a password-only approach.

That changes the way I would design one today.

The Conditional Access exclusion isn’t there because the account doesn’t need MFA.

It’s there because you don’t want a badly configured Conditional Access policy to prevent the account from being used during the exact emergency it was created to solve.

The account should still have strong, phishing-resistant authentication.

That distinction is important.

Conditional Access exclusion is not the same thing as removing security controls.

Create Two Cloud-Only Emergency Accounts

The first thing I’d do is create two emergency access accounts, rather than relying on one.

Two gives you redundancy. If one account, credential or authentication method becomes unavailable, you still have another emergency path.

Microsoft currently recommends two or more emergency access accounts. They should be cloud-only, use the tenant’s .onmicrosoft.com domain, and not be synchronised or federated from an on-premises identity system.

Every Entra tenant has a default domain in the form yourtenant.onmicrosoft.com that exists independently of any custom domain you’ve verified. That’s the one to use here.

Naming

Common advice is to name these accounts something obvious, like breakglass01. The thinking is that anyone responding to an incident can identify them immediately.

I don’t do it that way.

A name like breakglass01@yourtenant.onmicrosoft.com tells anyone who can see it exactly which account is excluded from Conditional Access, holds permanent Global Administrator, and is almost never used. That’s a signpost pointing at the most valuable account in the tenant.

I’d rather the account names look unremarkable:

svc-ia01@yourtenant.onmicrosoft.com
svc-ia02@yourtenant.onmicrosoft.com

Pick a convention that blends into your existing account naming. If you have no other svc- accounts in the tenant, that prefix becomes its own signpost.

This isn’t security through obscurity on its own. Anyone with directory read access can enumerate Global Administrators, and the exclusions are visible in the Conditional Access policies themselves. But it does mean the accounts don’t stand out in a list, and it removes an obvious target from external credential attacks.

The trade-off is that the responder has to know which accounts these are. That’s what the runbook is for, and it’s why the runbook needs to be accessible during an incident rather than living only in a wiki behind the same identity provider that just failed.

Whichever convention you choose, the accounts should not be tied to an individual. They belong to the organisation, not to whoever happened to create them.

Why cloud-only matters

This is particularly important in a hybrid environment.

If the account exists in on-premises Active Directory and is synchronised to Entra ID, you’ve introduced a dependency on your on-premises identity infrastructure.

If Active Directory or Entra Connect is the problem, you don’t want the account you created to solve the problem depending on those systems.

The same principle applies to federation.

Microsoft recommends keeping cloud emergency access separate from emergency access for on-premises systems so that an outage in one doesn’t prevent recovery of the other.

That’s one of the reasons I like the .onmicrosoft.com identity for these accounts.

It’s deliberately boring.

And boring is exactly what I want from an emergency account.

Create the Account in Microsoft Entra ID

From the Microsoft Entra admin centre, go to:

Entra ID → Users → All users → New user

Create a cloud-only user using the .onmicrosoft.com domain.

For example:

User principal name:
svc-ia01@yourtenant.onmicrosoft.com

Display name:
Emergency Access 01

Don’t associate the account with a particular employee.

Instead, document who is authorised to access the account and where its credentials are stored.

Once the account exists, assign the Global Administrator role.

This is one of those situations where the normal privileged-access rules need to be considered in the context of the problem you’re trying to solve.

For everyday administrators, I generally want privileged roles controlled through Privileged Identity Management.

For emergency accounts, Microsoft recommends making the Global Administrator assignment permanent and active rather than eligible.

That makes sense.

If the tenant is already in an emergency state and your PIM approval process is unavailable, requiring the emergency account to activate its own emergency privileges isn’t particularly helpful.

The emergency account needs to be capable of working without another privileged workflow standing in front of it.

Use a Different Authentication Method

This is one of the biggest changes from the old break-glass model.

If your normal administrators use Microsoft Authenticator, I don’t want my emergency accounts depending on the same authentication method.

Microsoft recommends using a strong authentication method that is different from your normal administrative accounts. FIDO2 security keys are a recommended option, while certificate-based authentication is another where an organisation already has the required PKI infrastructure.

For example:

Normal administrator
    -> Microsoft Authenticator
    -> Conditional Access
    -> Microsoft Entra ID

Emergency administrator
    -> FIDO2 security key
    -> Microsoft Entra ID

The important part isn’t simply that FIDO2 is stronger.

It’s that the emergency authentication path has fewer shared dependencies.

A physical FIDO2 security key can also be stored securely and made available to authorised administrators when required.

I would keep the two emergency credentials physically separate where practical.

If both keys are sitting in the same location and that location becomes inaccessible, you’ve effectively created another single point of failure.

Don’t Forget the Workstation

The account is only one part of the emergency access path.

You also need to think about where it will be used.

Microsoft recommends using a designated secure workstation or Privileged Access Workstation when interacting with emergency access accounts.

This makes sense from an operational perspective.

You’ve created an account capable of taking control of your entire Microsoft 365 environment.

The last thing you want is to use it from an unmanaged laptop with a browser full of extensions and a collection of unknown software installed.

Your emergency procedure should document:

• Which workstation should be used
• Where that workstation is located
• Who can access it
• How it connects to the required services
• Where the FIDO2 keys or other credentials are stored
• Who is authorised to use them

The emergency account should also avoid dependencies that can expire or be automatically cleaned up because the account isn’t used regularly. Microsoft specifically calls this out in its emergency access guidance.

Conditional Access: Exclude the Emergency Accounts Carefully

Conditional Access is where emergency access designs can get interesting.

You might have policies requiring:

• MFA
• Phishing-resistant MFA
• Compliant devices
• Authentication strengths
• Trusted locations
• Risk-based controls
• Specific device or application requirements

Those controls are important for your normal administrators.

But you also need to make sure they don’t accidentally prevent your emergency account from signing in.

Microsoft recommends excluding emergency access accounts from Conditional Access policies that block or restrict sign-in. Report-only policies don’t block access and therefore don’t require the exclusion.

I prefer to manage this through a dedicated security group, for example:

EmergencyAccess
    |
    +-- svc-ia01
    +-- svc-ia02

The group can then be excluded from the appropriate Conditional Access policies rather than maintaining a long list of individual account exclusions.

That also makes the configuration easier to review.

The important thing is to understand what the exclusion means.

It does not mean:

“These accounts don’t need security.”

It means:

“These accounts must remain usable if the normal access-control configuration fails.”

The security comes from the combination of phishing-resistant authentication, secure credential storage, restricted use, monitoring and physical controls.

I’d also use Report-only mode when introducing significant Conditional Access changes. It gives you an opportunity to identify unexpected effects before the policy is enforced.

Monitor Every Use of the Account

There is one rule I consider non-negotiable:

If somebody uses a break-glass account, someone should know about it.

I don’t want to discover three weeks later that an emergency account was used.

Microsoft Entra sign-in and audit logs give you the information needed to investigate this activity. The sign-in logs show authentication activity, while audit logs record changes made within the tenant.

For a serious environment, I’d send those logs into Log Analytics rather than relying solely on someone remembering to check the Entra portal.

From the Entra admin centre:

Entra ID → Monitoring & health → Diagnostic settings

Create a diagnostic setting and send the relevant activity logs to your Log Analytics workspace. Microsoft documents the process in configure diagnostic settings for Microsoft Entra ID, including sending logs to Log Analytics, Event Hubs or storage.

Once the logs are available in Log Analytics, you can use KQL to find activity from the emergency accounts.

For example:

SigninLogs
| where UserPrincipalName in (
    "svc-ia01@yourtenant.onmicrosoft.com",
    "svc-ia02@yourtenant.onmicrosoft.com"
)
| project
    TimeGenerated,
    UserPrincipalName,
    AppDisplayName,
    IPAddress,
    Location,
    ResultType,
    ResultDescription,
    AuthenticationRequirement
| order by TimeGenerated desc

I would also create an alert around successful sign-ins.

A failed login is worth investigating.

A successful login to a break-glass account is something I want to know about immediately.

Microsoft’s guidance specifically calls for monitoring sign-in and audit activity and having alerts capable of detecting unnecessary or unauthorised use.

This is also where a break-glass account becomes much more than another user object in Entra ID.

You’ve got a defined identity, a defined authentication method, a defined workstation and a monitoring process around it.

That’s an emergency access system.

What Happens When Someone Actually Uses It?

Hopefully, almost nothing.

If the account is used legitimately, the priority is getting normal administration working again.

But once the immediate problem is resolved, I would treat the event seriously.

I’d want to know:

1. Why was the emergency account required?
2. Which account was used?
3. When did the sign-in occur?
4. Where did the sign-in originate?
5. What changes were made?
6. What caused the original administrative access failure?
7. Were the emergency credentials exposed?
8. Does anything need to be rotated or replaced?
9. Has normal administrator access been restored?
10. Does the emergency procedure need to be updated?

If the credentials were exposed or there is any doubt about their security, replace them.

Don’t leave that job until next month.

The same applies to the physical FIDO2 keys. If one is lost, you don’t simply make a note of it and hope nobody finds it.

Treat the credential as compromised until you’ve dealt with it.

Don’t Rotate Emergency Credentials Just Because the Calendar Says So

One piece of traditional advice I don’t particularly like is:

“Change the break-glass password every 90 days.”

That sounds secure, but it can create another operational problem.

The emergency credential needs to be accessible to authorised administrators when the emergency happens.

A credential that was changed three months ago and nobody can find is not particularly useful.

I’d rather have a strong credential stored securely, with controlled access and a tested recovery process, than blindly rotate it on a calendar and create another opportunity for the documentation and the actual credential to get out of sync.

For FIDO2 credentials, the same principle applies.

Know where the keys are.

Know who can access them.

Know that they work.

And have a documented process for replacing them when necessary.

The important scheduled activity is the validation of the emergency access process, not simply changing a password because a calendar reminder says it’s time.

Test the Break-Glass Accounts

This is the part I would put the biggest emphasis on.

Don’t assume your emergency access account works. Test it.

Microsoft recommends validating emergency access accounts at least every 90 days.

For me, the test isn’t simply:

“Can I log in?”

I’d test the whole recovery path.

Emergency access test checklist

• Can both emergency accounts authenticate?
• Does the FIDO2 security key work?
• Is the secure workstation available?
• Can the account access the required Microsoft administration portals?
• Is Global Administrator still permanently active?
• Are the accounts still cloud-only?
• Are the appropriate Conditional Access exclusions still present?
• Are the authentication credentials still accessible?
• Are sign-in logs being collected?
• Does the monitoring alert work?
• Does the documented runbook still match the environment?

That last one is easy to overlook.

Your environment changes constantly.

Conditional Access policies change.

Administrators leave.

Security keys get replaced.

Workstations get rebuilt.

Monitoring configurations change.

The person who originally documented the process might not even work in the organisation anymore.

A break-glass test is therefore as much a test of your process as it is of the account.

And I’d document the test.

If you ever need to use the account during a real incident, you want to know when it was last successfully tested.

Keep the Emergency Runbook Simple

When you’re dealing with an administrative outage, the last thing you want is a 40-page document telling you what to do.

The runbook should be short enough that someone can follow it under pressure.

Mine would contain something along these lines.

Emergency access procedure

1. Confirm the problem

Determine whether normal administrative access is unavailable because of Conditional Access, MFA, identity infrastructure or another issue.

2. Authorise emergency access

Follow your organisation’s emergency-change process and confirm that the situation warrants using the account.

3. Retrieve the credential

Access the designated secure location and retrieve the appropriate FIDO2 key or other emergency authentication credential.

4. Use the designated workstation

Use the documented secure workstation or Privileged Access Workstation.

5. Sign in

Use the appropriate emergency access account.

6. Fix the immediate problem

Make the minimum changes required to restore normal administrative access.

7. Confirm recovery

Verify that normal administrator accounts can sign in and perform their required functions.

8. Review the logs

Check sign-in and audit activity and document the changes made.

9. Secure the emergency credentials

Rotate or replace credentials if they may have been exposed.

10. Document the incident

Record why the emergency account was used and what was done.

The aim is to make the procedure boring.

If you’re standing in front of a Microsoft 365 tenant that nobody can administer at 2am, boring is good.

A Few Break-Glass Mistakes Worth Avoiding

There are a handful of mistakes I would specifically look for when reviewing an existing environment.

One emergency account

Two or more gives you redundancy. If one credential or authentication method fails, you have another route in.

Synchronising the account from Active Directory

If Active Directory or Entra Connect is the problem, you don’t want your emergency account depending on either of them.

Password-only authentication

This is no longer an appropriate design for modern Microsoft cloud administration. Use a phishing-resistant method such as FIDO2/passkey or certificate-based authentication.

Making the Global Administrator role PIM-eligible

If your emergency account needs another privileged approval workflow before it can perform its job, you’ve added another dependency to your emergency path.

Forgetting the Conditional Access exclusions

The account should be protected, but not by a policy that could prevent it from signing in during an emergency.

Never testing it

This is probably the biggest operational mistake.

A break-glass account that hasn’t been tested is a recovery plan on paper.

You don’t know that it works until you test it.

The Question Worth Asking

I haven’t had to use a break-glass account in anger, and that’s exactly how I want it to stay.

But I also don’t want to discover during a tenant-wide access problem that the account I created for emergencies depends on the same systems that just failed.

That’s really what break-glass design comes down to.

Don’t just create another Global Administrator account.

Create an independent path back into the tenant, protect it properly, monitor it and test it often enough that you know it will work when you need it.

The question I’d ask when reviewing any Microsoft 365 environment is simple:

If every normal Global Administrator was locked out right now, could you get back in?

If the answer isn’t an immediate “yes”, your emergency access strategy probably needs some work.

Microsoft references

• Manage emergency access accounts in Microsoft Entra ID
• Mandatory multifactor authentication for Microsoft Entra
• Enable passwordless security key sign-in
• Conditional Access overview
• Configure diagnostic settings for Microsoft Entra ID

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.