Break Glass Accounts in Entra ID: Setup and Monitoring

Every Microsoft tenant needs a way in when the normal way in is broken. A break glass account is the emergency door: a highly privileged account, kept outside your usual authentication flow, that lets an administrator regain control if Conditional Access misfires, your identity provider federation breaks, or multi-factor authentication becomes unreachable for everyone at once. Getting the break glass account setup right is one of those tasks that feels theoretical until the day it is not, and by then it is too late to fix a mistake.

The problem is that break glass accounts sit in an uncomfortable spot. They need to bypass the very controls you rely on for everything else, which makes them a real target if mismanaged. Left unmonitored, they are exactly the kind of standing, high-privilege access that security reviews are supposed to catch. This article walks through how to set break glass accounts up correctly, what to exclude them from, and how to monitor them so they stay a safety net instead of a blind spot.

Why You Need a Break Glass Account

Conditional Access, MFA enforcement, and Privileged Identity Management are core to a modern Entra ID security posture. They are also exactly the things that can lock you out if something goes wrong.

The lockout scenarios are real

A handful of situations recur across Microsoft tenants of every size:

• A Conditional Access policy is misconfigured and blocks all sign-ins, including admins.
• Your MFA provider or phone network is down, and nobody can complete a second factor.
• Federation with an on-prem identity provider breaks, cutting off every federated account.
• The last remaining Global Administrator leaves the company or loses access to their device.

Any one of these can leave you unable to sign in and unable to fix the thing that is blocking you. That is precisely the situation a break glass account exists to solve.

It is not optional, and it is not a convenience account

A break glass account is not a shared IT password for daily admin tasks, and it is not a way to skip MFA because it is annoying. It exists for one purpose: restoring access when every normal path has failed. Treating it as anything else erodes the one safeguard you are counting on for the worst day.

Setting Up a Break Glass Account Correctly

Use cloud-only accounts, not synced ones

A break glass account should be a cloud-only Entra ID account, never synchronized from on-prem Active Directory. If your on-prem environment or your hybrid sync is the thing that broke, a synced account goes down with it. Cloud-only accounts also avoid depending on federation, which removes another single point of failure.

Assign the role directly, not through PIM

This is the detail that trips people up most often. Privileged Identity Management is excellent for just-in-time, time-bound privileged access, but a break glass account should have its Global Administrator role assigned permanently and directly, not eligible through PIM. If PIM itself is unavailable during an outage, an account that depends on PIM activation is useless exactly when you need it.

Exclude it from Conditional Access

Every Conditional Access policy that could plausibly block sign-in, MFA requirements, location restrictions, device compliance checks, needs to explicitly exclude your break glass accounts. Microsoft's own guidance recommends creating a dedicated Conditional Access policy that excludes break glass accounts from all other policies, so a single misconfigured rule elsewhere cannot lock the emergency door too.

Use strong, unique credentials stored offline

Generate a long, random, unique password (32+ characters is a common recommendation) and store it somewhere physically secure and access-controlled, such as a sealed envelope in a safe, rather than in a password manager tied to the same identity system that might be down. If you use a physical security key instead of a password, apply the same offline, controlled-access principle to how it is stored.

Create at least two accounts

One break glass account is a single point of failure. Two accounts, stored separately, with different custodians where possible, gives you redundancy if one credential is lost, forgotten, or compromised.

Monitoring: The Part Most Tenants Skip

Setting the account up is the easy half. The harder discipline is making sure a dormant emergency account does not quietly become a permanent, unmonitored administrator.

Alert on every sign-in, immediately

A break glass account should never sign in during normal operations. Configure a sign-in log alert (through Microsoft Sentinel, a SIEM, or a simple Logic App on the sign-in log) that fires the moment either account authenticates. If nobody expected that sign-in, you want to know within minutes, not during the next quarterly review.

Review the accounts on a fixed schedule

Even though the accounts should stay dormant, they still need a recurring check: does the credential still work, is the role assignment still correct, has the account accidentally been swept into a Conditional Access policy it should be excluded from. A quarterly review is a reasonable baseline.

Rotate credentials after every use, and periodically regardless

If a break glass account is ever used, rotate its credential immediately afterward as part of the incident review. Even if it is never used, rotating on a set schedule (annually is common) limits how long a leaked or forgotten credential stays valid.

Keep the documentation current, and keep it out of the systems it protects

Document exactly which accounts are break glass accounts, where the credentials are stored, and who is authorized to use them, and store that documentation somewhere that does not depend on the identity system the accounts exist to rescue.

Setup element	Recommended approach	Why it matters
Account type	Cloud-only, not synced	Survives on-prem or federation outage
Role assignment	Permanent, direct assignment	Not blocked if PIM is unavailable
Conditional Access	Explicitly excluded	A misconfigured policy cannot lock it out
Credentials	Strong, unique, stored offline	Not dependent on a password manager that may be down
Number of accounts	At least two	Redundancy against a single lost credential
Monitoring	Real-time sign-in alert	Any use is investigated within minutes

Where Break Glass Fits Into Broader Access Governance

Break glass accounts are a narrow, specific control, but they sit inside a wider discipline of knowing exactly who has standing privileged access and why. The same visibility gap that lets a break glass account go unmonitored for years is usually the same gap that lets ordinary privileged roles accumulate unnoticed.

Standing privilege is the pattern to watch

A break glass account is deliberately a standing, non-expiring privileged account, which is exactly why it needs tighter monitoring than anything managed through PIM's time-bound elevation. The same logic applies more broadly: any account with permanent, high-level access deserves periodic review, whether it is an emergency account or a service account nobody has looked at since it was created.

Access reviews close the loop

A recurring access review cycle, covering not just regular users but privileged and emergency accounts, is what turns "we set this up once" into "we know this is still correct." ServiceChanger's access review functionality lets you build break glass and other privileged accounts into a recurring review cadence alongside your regular Entra ID and on-prem AD access reviews, so an account like this does not fall through the cracks between annual audits.

Automating the routine frees attention for the exceptions

Most access decisions in a mid-market Microsoft environment do not need this level of manual care, they follow predictable patterns based on department, role, or location. ServiceChanger's access automation handles that routine assignment work through attribute-based rules, which is precisely what frees up an IT team's attention for the handful of accounts, like break glass accounts, that genuinely need hands-on scrutiny.

FAQ

How many break glass accounts should we have? Two is the common recommendation from Microsoft and most security practitioners. One account is a single point of failure; two gives you redundancy if a credential is lost or one account has a problem, without creating unnecessary sprawl.

Should break glass accounts use MFA? No. Break glass accounts are specifically excluded from MFA and Conditional Access requirements because they exist to restore access when those very systems are unavailable. The tradeoff is compensated for with strong, unique, offline-stored credentials and strict, real-time monitoring of any sign-in.

Can a break glass account be a synced on-prem account? It should not be. A cloud-only account avoids dependency on your on-prem Active Directory or hybrid sync, either of which could be the reason you need emergency access in the first place.

How often should break glass credentials be rotated? Immediately after any actual use, and on a fixed schedule regardless of use, commonly once a year. This limits the window in which a stale or potentially exposed credential remains valid.

Break glass accounts are a small piece of your Entra ID environment, but they carry an outsized amount of risk if they are set up carelessly or left unwatched. Get the setup right once, monitor it consistently, and fold it into the same governance rhythm as the rest of your privileged access. For the broader picture on keeping access accountable across your Microsoft tenant, see our guide to access governance and compliance. For more on related controls, browse our Entra ID articles or our access control coverage.

If you want to see how ServiceChanger fits break glass and other privileged accounts into a recurring access review cycle alongside your everyday Entra ID and on-prem AD governance, get in touch to see it in action.