Break Glass Done Properly
Break glass accounts are your last line of defence. Most organisations get them wrong. Here's how to design, secure, and test them properly.
What break glass means
Break glass accounts are emergency access accounts designed to restore administrative control when normal privileged access mechanisms fail. They bypass PIM, Conditional Access, and MFA — by design.
This makes them both essential and extremely dangerous.
Why most break glass implementations fail
Common failures include:
- Untested accounts — break glass credentials stored in a safe but never validated
- Stale passwords — credentials that haven’t been rotated in months or years
- No monitoring — sign-ins to break glass accounts that go undetected
- Poor storage — credentials in shared password managers, spreadsheets, or email
- No process documentation — no defined procedure for when and how to use them
- Conditional Access exclusions too broad — break glass accounts excluded from all policies instead of carefully scoped
Design principles
Minimum viable access
Break glass accounts should have the minimum access needed to restore normal administrative capability. In most environments, this means Global Admin — but only because that’s often the only way to restore PIM or Conditional Access.
Cloud-only
Break glass accounts should be cloud-only (no on-premises sync) to avoid dependency on AD DS or AD Connect.
No MFA dependency
By definition, break glass accounts must work when MFA is unavailable. This is their purpose. But this means additional compensating controls are critical.
Strong credentials
Use long, complex, randomly generated passwords. Consider splitting the password between two secure locations so that no single person or location has full access.
Operational requirements
- Test regularly — at least quarterly, validate that break glass accounts can sign in and perform their intended function
- Monitor continuously — alert on any sign-in to a break glass account immediately, 24/7
- Rotate credentials — after every use and on a scheduled basis
- Document the process — who can authorise use, how credentials are retrieved, what actions to take, and how to report use
- Limit knowledge — restrict awareness of break glass credential locations to the minimum number of people necessary
Monitoring
At a minimum, configure:
- Azure Monitor or Microsoft Sentinel alerts on break glass account sign-ins
- Sign-in log review as part of regular security operations
- Conditional Access policy to require known, trusted locations for break glass (where feasible without defeating the purpose)
The bottom line
Break glass is not “set and forget.” It is an ongoing operational responsibility within the Operations pillar of the Privileged Path Framework.
If you haven’t tested your break glass process in the last 90 days, you don’t have a break glass process. You have a hope.