Key idea
Emergency access expands your blast radius
A break-glass account is a deliberate exception to your control model. If it isn’t isolated, monitored, and rehearsed, you’ve added a permanent bypass that attackers will eventually find.
Research Note · Privileged Access
Break-Glass Accounts
How most organizations implement them wrong
Break-glass accounts exist for one reason: to regain control of your tenant when normal access paths fail. But most implementations turn emergency access into a permanently exposed superuser that is rarely tested, lightly monitored, and assumed safe because it is “not used.”
Emergency access
Tenant recovery
Governance design
If your break-glass accounts are “set and forget,” they are probably a liability.
Executive summary
Break-glass is a recovery control — not a convenience account
Break-glass accounts are intended to preserve business continuity when identity control is degraded: Conditional Access misconfigurations, MFA outages, IdP failures, mis-scoped admin changes, or account lockouts during an incident. The common mistake is to create “emergency admin” identities and then treat them as inert. In reality, any standing privileged identity becomes an attacker objective.
Misconception
“It’s safe because no one uses it”
Low usage usually means low visibility. Attackers love quiet accounts that don’t generate normal operational noise.
Outcome
Organizations discover failure mid-incident
The most common time to learn your break-glass doesn’t work is during a real outage or compromise — when time and options are limited.
Purpose
What break-glass accounts are actually for
Break-glass is not “another admin account.” It is a last-resort recovery mechanism designed to restore governance and control.
Recover from policy mistakes
Misconfigured Conditional Access or MFA policies can lock out administrators. Break-glass provides a recovery path to roll back changes and restore normal access.
Operate during identity outages
If an IdP component fails, or if MFA services degrade, break-glass provides continuity so you can keep the business running while restoring primary controls.
Contain incidents when normal accounts are suspect
During a suspected identity compromise, you may need a clean, isolated credential to regain control, revoke sessions, remove malicious apps, and reassert governance.
Failure modes
How most organizations implement break-glass wrong
These failures are common because they are operationally convenient. They are also exactly what attackers expect.
Single break-glass account
One account equals one point of failure. If it’s locked, compromised, or misconfigured, you have no safe fallback. Break-glass should be resilient — which usually means at least two independent paths.
Same MFA / same device dependency
A “break-glass” that depends on the same device, phone, authenticator app, or recovery channel as normal admin access is not a break-glass. It is a shared failure mode.
Shared credentials and informal custody
Credentials stored in a shared document, emailed around, or kept in someone’s desk drawer create both insider and attacker risk. Custody must be deliberate and auditable.
No alerting, no monitoring, no story
Many teams configure break-glass accounts and then never set up “if this account is used, the world stops” alerting. If usage isn’t instantly visible, you have a stealth bypass sitting in your tenant.
Break-glass used for normal admin tasks
The fastest way to destroy the concept is to use it when you’re in a hurry. If it gets used in routine operations, it will eventually become integrated into normal workflows — and then attacked.
No rehearsal or validation
Password rotation, policy drift, logging changes, and tenant evolution often break emergency access. If you do not test it, you do not have it.
Program direction
A safer break-glass pattern that survives real incidents
The goal is not to make break-glass “easy.” The goal is to make it dependable in crisis and unattractive to abuse.
Design
Two independent emergency paths
Create at least two break-glass identities with independent dependencies and custody. Avoid shared failure modes where both accounts rely on the same people, the same device, or the same recovery channel.
Design
Isolated credentials and custody
Store credentials in a controlled vault process (not shared docs). Define who can retrieve them, under what conditions, and how retrieval is logged and reviewed.
Design
Immediate alerting and “stop the world” workflow
Any sign-in should generate high-priority alerts to multiple channels. Treat break-glass usage as an incident until proven otherwise.
Design
Dedicated validation exercises
Rehearse quarterly. Validate you can: sign in, regain tenant control, roll back policies, revoke sessions, remove risky app grants, and re-enable normal admin access — quickly and safely.
Governance signals
Questions leaders should ask about break-glass
These questions turn emergency access from “a checkbox” into an operational control you can trust.
Question
When did we last prove it works end-to-end?
If the answer is “we’ve never tested it” or “not in the last year,” assume break-glass is unreliable in the moment you need it.
Question
Would we know within 60 seconds if it was used?
Emergency accounts should have instantaneous, high-confidence alerting. If it’s possible for the account to be used quietly, it will be.
Question
Do both accounts fail the same way?
If both depend on the same admin’s phone, the same vault workflow, or the same network path, then you have one break-glass split into two usernames.