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

There’s a particular feeling you get as an IT administrator when you realise nobody can log in to the Azure tenant. You try your normal administrator account and get denied. You try another administrator and get the 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 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 are environments where emergency access hasn’t been designed properly. The accounts were synchronised from on-premises Active Directory, authentication depended on the same infrastructure as the normal administrators, nobody could easily get to the credentials, or Conditional Access policies had been configured without considering the emergency account at all. That’s where the real problem lies.

A break-glass account isn’t simply another Global Administrator with a complicated password. It’s an alternative path back into Microsoft Entra ID when the normal administrative path has failed, and that means it needs to be designed differently from your everyday administrator accounts. Microsoft now calls these emergency access accounts, although most administrators still call them break-glass accounts.

Why you need a break-glass account

The obvious answer is “in case you get locked out”. The more useful question is what could actually stop your normal administrative access from working, and there are plenty of possibilities:

• a Conditional Access policy configured incorrectly that blocks administrators
• an authentication policy requiring a method your administrators don’t have available
• an identity provider or federation service becoming unavailable
• administrators losing access to their authentication devices
• the last usable Global Administrator account being disabled or otherwise unavailable

Even a perfectly legitimate change to your privileged access model could leave you with no active administrator able to make the next change. Microsoft’s emergency access account guidance lists scenarios like these, including federation outages, unavailable MFA devices or services, and Privileged Identity Management (PIM) configurations where no active approver is available.

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 between you and the Microsoft 365 admin centre. The emergency account should have fewer. That’s the principle behind the whole design: your emergency access path shouldn’t depend on the system that has just failed.

Why the old password-only design no longer works

The traditional break-glass design was simple: create a Global Administrator account, give it a long random password, exclude it from MFA and Conditional Access, and store the password somewhere safe. 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 portals. Microsoft recommends updating these accounts to use passkeys (FIDO2) or certificate-based authentication rather than a password alone.

That changes how I’d design one today. The Conditional Access exclusion isn’t there because the account doesn’t need MFA. It’s there so a badly configured Conditional Access policy can’t stop the account working during the exact emergency it was created for. The account should still have strong, phishing-resistant authentication. Excluding an account from Conditional Access is not the same thing as removing its security controls.

Create two cloud-only emergency accounts

Start by creating 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 way in. Microsoft 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, and that’s the one to use here.

Naming

Common advice is to name these accounts something obvious, like breakglass01, so 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 sensitive account in the tenant. I’d rather the 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 list Global Administrators, and the exclusions are visible in the Conditional Access policies themselves. It does mean the accounts don’t stand out in a list, and it removes an obvious target for 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 reachable during an incident, not sitting only in a wiki behind the same identity provider that just failed.

Whichever convention you choose, don’t tie the accounts to an individual. They belong to the organisation, not to whoever happened to create them.

Why cloud-only matters

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. When Active Directory or Entra Connect is the problem, the account you created to solve it can’t depend on either of them. The same applies to federation. Microsoft also recommends keeping cloud emergency access separate from emergency access for on-premises systems, so 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

In the Microsoft Entra admin centre, go to Entra ID > Users > All users > New user and create a cloud-only user on the .onmicrosoft.com domain. For example, use a user principal name of svc-ia01@yourtenant.onmicrosoft.com and a display name of Emergency Access 01. Don’t associate the account with a particular employee. Instead, document who is authorised to use it and where its credentials are stored.

Once the account exists, assign the Global Administrator role. This is one of those situations where normal privileged access rules need to be weighed against the problem you’re solving. For everyday administrators I generally want privileged roles controlled through PIM, but 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, an emergency account that has to activate its own privileges isn’t much help.

Use a different authentication method

If your normal administrators use Microsoft Authenticator, your emergency accounts shouldn’t depend on it too. Microsoft recommends a strong authentication method that’s different from the one your normal administrative accounts use. A FIDO2 security key is the usual choice, and certificate-based authentication is another option where you already have the PKI to support it.

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

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

The point isn’t simply that FIDO2 is stronger. It’s that the emergency authentication path has fewer shared dependencies.

Make sure passkeys (FIDO2) are enabled in your authentication methods policy and that the emergency accounts are in scope. Entra ID now supports synced passkeys as well as device-bound ones. For an emergency account, use a device-bound passkey on a physical security key, so the credential doesn’t live in someone’s personal cloud keychain. A Temporary Access Pass is a clean way to register the keys on a new account that has no other method yet.

A physical key can be stored securely and handed to authorised administrators when needed. Keep the two emergency credentials physically separate where practical. If both keys sit in the same safe and that location becomes inaccessible, you’ve created another single point of failure.

Don’t forget the workstation

The account is only part of the emergency access path. You also need to think about where it will be used. Microsoft recommends a designated secure workstation or Privileged Access Workstation for emergency access accounts, which makes sense. You’ve created an account that can take control of your entire Microsoft 365 environment, and the last place you want to use it is an unmanaged laptop with a browser full of extensions.

Your emergency procedure should document which workstation to use, where it’s located, who can access it, how it connects to the required services, where the FIDO2 keys or other credentials are stored, and who is authorised to use them. Also check that the account doesn’t depend on anything that could expire or be cleaned up automatically because it’s rarely used, such as an inactive-account policy or a time-limited credential.

Conditional Access: exclude the emergency accounts carefully

You might have Conditional Access policies requiring MFA, phishing-resistant MFA, compliant devices, authentication strengths, trusted locations, risk-based controls or specific applications. Those controls matter for your normal administrators, but they mustn’t accidentally stop the 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, so they don’t need the exclusion. See Microsoft’s Conditional Access overview for how policies are evaluated.

I prefer to manage the exclusion through a dedicated security group:

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

The group can then be excluded from the relevant policies, rather than maintaining individual account exclusions, which also makes the configuration easier to review. Protect that group, though. Anyone who can change its membership can exclude an account from your Conditional Access policies. A role-assignable group, or management restricted to your most privileged roles, closes that gap.

Be clear about what the exclusion means. It doesn’t 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 phishing-resistant authentication, secure credential storage, restricted use, monitoring and physical controls working together. When you introduce significant Conditional Access changes, run them in Report-only mode first so you can spot unexpected effects before the policy is enforced.

Monitor every use of the account

There’s 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 logs show authentication activity, and audit logs record changes made in the tenant. For a serious environment, send those logs to Log Analytics rather than relying on someone remembering to check the portal. In the Entra admin centre, go to Entra ID > Monitoring & health > Diagnostic settings and create a setting that sends the sign-in and audit logs to your Log Analytics workspace. Microsoft documents the process in configure Microsoft Entra diagnostic settings. Exporting sign-in logs needs Entra ID P1 or P2, and it can take up to three days for logs to start appearing at the destination, so set this up before you need it.

Once the logs are in Log Analytics, this KQL query shows all activity from the emergency accounts:

kusto

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

Build an alert rule on top of it that fires on successful sign-ins, which have a ResultType of 0. A failed sign-in is worth investigating, but a successful sign-in to a break-glass account is something I want to know about immediately. Microsoft’s guidance calls for alerts on every use of an emergency access account.

This is where a break-glass account becomes more than another user object in Entra ID. With a defined identity, a defined authentication method, a defined workstation and monitoring around it, you have an emergency access system.

After the account has been used

Hopefully this almost never happens. When the account is used legitimately, the priority is getting normal administration working again. Once the immediate problem is resolved, though, treat the event seriously and work out:

• why the emergency account was needed and which account was used
• when and where the sign-in came from
• what changes were made
• what caused the original administrative access failure
• whether the credentials were exposed and need replacing
• whether normal administrator access has been fully restored
• whether the emergency procedure needs updating

If there’s any doubt about the security of the credentials, replace them straight away rather than leaving it until next month. The same applies to the physical FIDO2 keys. If one goes missing, treat it 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 like is “change the break-glass password every 90 days”. It sounds secure, but it can create its own problem. The emergency credential has to be available to authorised administrators when the emergency happens, and a credential changed three months ago that nobody can find isn’t much use.

I’d rather have a strong credential stored securely, with controlled access and a tested recovery process, than rotate it on a schedule and give the documentation and the real credential another chance to drift apart. The same goes for FIDO2 keys: know where they are, know who can access them, know they work, and have a documented process for replacing them. The scheduled task that matters is validating the emergency access process.

Test the break-glass accounts

Don’t assume your emergency access account works. Microsoft recommends validating emergency access accounts at least every 90 days, and in my view the test should cover the whole recovery path, not just “can I log in?” That means checking that both accounts can authenticate with their FIDO2 keys from the designated workstation, reach the admin portals, still hold Global Administrator permanently, are still cloud-only, are still excluded from the right policies, and trigger the monitoring alert. It also means checking that the runbook still matches the environment.

That last check is easy to overlook. Conditional Access policies change, administrators leave, security keys get replaced, workstations get rebuilt and monitoring configurations drift. The person who wrote the original process might not even work for the organisation anymore. A break-glass test is as much a test of your process as of the account, so record each test. If you ever need the account during a real incident, you’ll want to know when it last worked.

Keep the emergency runbook simple

During an administrative outage, the last thing you want is a 40-page document. The runbook should be short enough to follow under pressure. Mine would look something like this:

1. Confirm that normal administrative access is unavailable and why, whether that’s Conditional Access, MFA, identity infrastructure or something else.
2. Follow your emergency change process to authorise using the account.
3. Retrieve the FIDO2 key or other emergency credential from its secure location.
4. Go to the designated secure workstation or Privileged Access Workstation.
5. Sign in with the emergency access account.
6. Make the minimum changes needed to restore normal administrative access.
7. Confirm that normal administrator accounts can sign in and do their jobs.
8. Review the sign-in and audit logs and record every change made.
9. Replace any credentials that may have been exposed.
10. Document why the 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.

Break-glass mistakes worth avoiding

These are the problems I look for when reviewing an existing environment.

Break-glass setup checklist

Use this when building emergency access from scratch or reviewing an existing setup.

1. Two emergency accounts exist, both cloud-only on the .onmicrosoft.com domain and not tied to any individual.
2. Both hold the Global Administrator role as a permanent, active assignment.
3. Each account uses a phishing-resistant method that differs from your normal administrators’ method, such as a device-bound passkey on a FIDO2 security key.
4. The keys or credentials are stored securely, in separate locations, with a documented list of who can access them.
5. A designated secure workstation is identified and documented.
6. Both accounts are excluded from Conditional Access policies that block or restrict sign-in, through a protected group.
7. Sign-in and audit logs flow to Log Analytics, with an alert on every successful sign-in.
8. A short runbook exists that’s reachable without the tenant’s normal identity provider.
9. A full test runs at least every 90 days, and after every significant Conditional Access change, with the result recorded.

The question worth asking

I haven’t had to use a break-glass account in anger, and I’d like it to stay that way. What I don’t want is 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.

When I review any Microsoft 365 environment, the question I ask 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 – Microsoft’s emergency access guidance and checklist
• Mandatory multifactor authentication for Microsoft Entra – which admin portals require MFA and how it affects emergency accounts
• Enable passkeys (FIDO2) in Microsoft Entra ID – configuring security key sign-in
• Conditional Access overview – how Conditional Access policies are evaluated
• Configure Microsoft Entra diagnostic settings – sending sign-in and audit logs to Log Analytics

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.