What is a break-glass account?
A break-glass account, also called an emergency access account, is an administrative account kept for one purpose: regaining control when every normal way to administer a system has failed. The name comes from the glass panel on a fire alarm, broken only in an emergency. Typical triggers include an outage at the identity provider or MFA service, a conditional access policy that accidentally blocks every administrator, an expired federation certificate that stops all single sign-on, and an on-premises directory that is down or compromised. Network devices use the same idea in a local fallback account that works when the TACACS+ or RADIUS servers cannot be reached.
How break-glass accounts are set up
The account has to work during the very failure it exists for, so its design avoids every dependency that might be broken:
- Create two or more, so that losing one key or password is not fatal.
- Host them directly in the cloud tenant rather than syncing them from on-premises Active Directory or federating them to another identity provider.
- Exclude them from policies that could lock them out, but not from protection. Microsoft's guidance for Entra ID emergency access accounts, for example, now calls for phishing-resistant methods such as FIDO2 security keys or certificate-based authentication rather than leaving the accounts without MFA.
- Store credentials under dual control, such as a long random password split between two officers or sealed in a safe with a sign-out log, with FIDO2 keys kept in separate secure locations.
- Avoid ties to one person, such as a single employee's phone number or mailbox.
Monitoring and testing
Legitimate use is rare, so every sign-in deserves attention. In Microsoft Sentinel or a Log Analytics workspace, the alert rule can be as simple as:
SigninLogs | where UserPrincipalName in~ ("bg-admin-01@corp.onmicrosoft.com", "bg-admin-02@corp.onmicrosoft.com")
The alert should page several people, and each use should be explained in an incident or change record. Test the accounts on a schedule, such as quarterly and after major identity changes, so a forgotten password or a lost key turns up before the emergency does. Rotate the credentials after any real use, and keep the procedure in the incident response and disaster recovery plans, where responders will look for it.
Break-glass account vs. other privileged access
- Everyday admin accounts are used daily, depend on the normal identity provider and MFA, and often get their rights through just-in-time elevation.
- PAM-vaulted accounts are checked out through a privileged access management workflow, which may itself be unavailable in the emergency.
- Break-glass accounts sit outside those dependencies and stay unused, trading convenience for guaranteed access under heavy monitoring.
- Shared accounts are a poor practice that break-glass accounts can resemble; the difference is strict custody, alerting and testing.
An unmonitored break-glass account with a password nobody has changed in years is an ideal back door, and an attacker who gains a foothold in an identity platform has every reason to look for one.
Break-glass account on the CompTIA Security+ exam
Emergency access accounts are among the account types in SY0-801 objective 4.5. Wording such as "administrators are locked out of the cloud tenant after an MFA outage," "keep access if the identity provider fails" or "an account reserved for emergencies" points to a break-glass account. A follow-up question about protecting it wants secure storage, an alert on every use and regular testing. Distractors include disabling the account until needed, which fails when the directory needed to enable it is down; sharing it with the help desk; and storing its password in the same identity system it is meant to bypass. MFA outage scenarios also connect to failing closed for administrator sign-in, with break-glass accounts as the planned exception.