A break-glass account is a pre-staged emergency credential. Its value is not that it logs in fast. Its value is that when it logs in, everyone knows, and the session can be traced back to a named human afterward. For a team of two to fifteen engineers who run their own on-call rotation, that distinction matters more than it does in an organization with a dedicated security operations center.
The failure mode the account exists for is specific: the identity provider is down, the MFA device is lost, the last global administrator has left, or the federation path is unreachable. Microsoft’s guidance on emergency access accounts in Entra ID names these cases directly and states the rule plainly: use emergency access accounts only for emergency or break-glass scenarios where normal administrative accounts cannot be used, and restrict their use to times when it is absolutely necessary. The same logic applies whether your control plane is Entra ID, a self-hosted LDAP directory, or a cloud provider’s IAM.
Design constraints for a small team
Microsoft recommends creating two or more emergency access accounts, as cloud-only accounts on the *.onmicrosoft.com domain that are not federated or synchronized from on-premises. The redundancy is not decorative. A single emergency account is a single point of failure that happens to be the thing you reach for when everything else has already failed.
The federation independence is the load-bearing part. If your emergency account authenticates through the same identity provider that just went down, you have not built an emergency path. You have built a second door with the same broken lock. For a bare-metal or self-hosted environment, the equivalent is a local account that does not depend on the central directory, with credentials stored somewhere that does not require the network to reach.
Microsoft also specifies that emergency access accounts should be excluded from Conditional Access policies that block or restrict sign-in, because an enforced policy could prevent sign-in during the exact emergency the account is designed for. Report-only policies do not block access and do not need an exclusion. This is a tradeoff worth stating plainly: you are deliberately carving a hole in your normal access policy. The hole is the control. It is not a bug to be closed later.
The authentication method for the emergency account should differ from the methods used by normal administrative accounts. If your normal admin accounts use an authenticator app, the emergency account should use a FIDO2 security key or certificate-based authentication. The credential or device must not expire or fall under automated cleanup for lack of use. An emergency account that gets swept by a dormant-account policy is an emergency account that will not work when you need it.
Make the account conspicuous by design
Yale’s HIPAA break-glass procedure, which draws on a 2004 whitepaper from the Joint NEMA/COCIR/JIRA Security and Privacy Committee, describes the design principle well: emergency accounts should be created in advance so that careful thought can go into the access controls and audit trails associated with them, and the username should be obvious and meaningful, such as breakglass01, so that the account name would be inappropriate under normal operations and would stand out in audit trails.
That is the opposite of how most credentials are named. Normal accounts blend in. The emergency account should not. When someone greps the audit log six months from now, the account name should be the first thing that catches their eye.
The distribution method should also be physically evident. Yale’s procedure lists several options: kept behind glass in a cabinet where access requires literally breaking the glass, maintained within sealed envelopes where a broken seal is an obvious indication of access, locked in a desk drawer that only specific people can access, or locked in a safe or cabinet where one person knows the combination and a different person has the key to the room. The common thread is that access to the credential leaves a physical trace.
For a small team, the two-person pattern is practical. One engineer holds the safe combination; another holds the office key. Neither can reach the credential alone. The friction is the point. It is not a bug to be optimized away.
The distribution procedure should include a sign-out method requiring an acceptable form of identification, recorded before the accounts are made available. Yale’s procedure notes that this assures activities performed using the emergency account may eventually be associated with an authorized individual, creates accountability, and can assure non-repudiation. In practice, that means a paper log or a shared document with a timestamp, a name, and a reason. The reason field is not bureaucracy. It is the first line of the postmortem.
Wire the alert before you need it
Microsoft’s guidance is direct: monitor sign-in and audit log activity from the emergency accounts and trigger notifications to other administrators, so that you can verify these accounts are only used for testing or actual emergencies. The alert is the account’s real security control. If a break-glass sign-in does not page a human within minutes, the audit trail is archaeology rather than detection, and the account is effectively a permanent backdoor with a nice name.
For a team without a SOC, the alert should route to the same on-call channel that handles production incidents. The alert should fire on every sign-in, not on a threshold. There is no legitimate reason for a break-glass account to sign in without a human knowing about it in real time.
The audit record itself should contain enough to reconstruct the event. NIST SP 800-53 Rev. 5, as reflected in the CSF reference, specifies that audit records should establish what type of event occurred, when it occurred, where it occurred, the source of the event, the outcome, and the identity of any individuals, subjects, or objects associated with the event. For a break-glass session, that means the account name, the source IP or workstation, the timestamp in UTC, the actions taken, and the outcome. If your system cannot produce that, Yale’s procedure is explicit: break-glass use needs to be carefully considered before implementing, and may require a manual paper log instead.
NIST SP 800-92 frames log management as the process for generating, transmitting, storing, analyzing, and disposing of computer security log data, and notes that it is essential to ensuring that computer security records are stored in sufficient detail for an appropriate period of time. For a small team, the practical version is: ship the break-glass account’s logs to a destination that the account itself cannot modify, and keep them long enough to cover your incident review cycle.
Write the post-use runbook
After any use of an emergency access account, Microsoft’s guidance calls for a review to determine whether the use was authorized and whether the actions taken were appropriate. That review has a few concrete steps.
First, preserve the logs. Capture the sign-in record, the audit trail of privileged actions, and any session recordings or command history the platform provides. NIST’s audit guidance specifies that audit record reduction and report generation should support on-demand review and after-the-fact investigations without altering the original content or time ordering of audit records. Copy the raw records before you summarize them.
Second, reconcile the session to a named human. The sign-out log from the distribution procedure gives you the name. The audit trail gives you the actions. The postmortem gives you the reason. If those three do not line up, that is the finding.
Third, disable or rotate the credential. Yale’s cleanup procedure recommends disabling or deleting the emergency account that was used to prevent reuse now that the password is known, and reconciling the data acquired and audit trails to reflect the proper operator’s name. Some systems can automatically deactivate emergency accounts after first use or after a selectable period such as 8 hours or 1 day. Commvault’s break-glass implementation takes a different approach: the password is regenerated on every login to prevent repeated use of the same password, and all actions are recorded in the audit trail. Either pattern works. What does not work is leaving a known password in place after an incident that involved a dozen people in a channel.
Fourth, ask whether the normal access path failed in a way that should be fixed. Yale’s procedure notes that frequent use of emergency accounts may indicate problems with the normal user authentication mechanism. A break-glass account that gets used every month is not a break-glass account. It is a helpdesk with extra steps, and Yale’s procedure explicitly says break-glass should not replace a helpdesk.
Schedule the drill
Microsoft recommends performing account validation drills at least every 90 days, including reviewing the authorized-user list and testing sign-in and administrative task functionality. The 90-day cadence is a reasonable default for a small team. The important part is the second half of that sentence: testing administrative task functionality, not just sign-in.
A drill that only tests sign-in is not a drill. The failure that matters is discovering at 3 a.m. that the credential works but the permission it grants does not cover the task. If the break-glass account is supposed to let you restore a database, the drill should include a restore. If it is supposed to let you rotate an IAM role, the drill should include a role switch. AWS IAM documentation notes that when you switch to a role in the console, you temporarily give up your user permissions and work with the permissions assigned to the role, and when you exit the role, your user permissions are automatically restored. That is a useful property for a break-glass path, but only if the role’s permissions actually cover the emergency task.
One more AWS-specific detail worth knowing: you cannot switch roles in the AWS Management Console to a role that requires an ExternalId value. Such a role can only be assumed by calling the AssumeRole API that supports the ExternalId parameter. If your break-glass path depends on a role with an ExternalId, the console switch will not work, and the drill will find that out before the incident does.
Treat a failed drill as an incident. It is a control that did not work when tested under controlled conditions. The blameless postmortem format applies: what did we expect, what happened, what will we change.
The tradeoff to accept
The break-glass account is slower and more awkward than a normal login on purpose. Two people, a physical envelope, a sign-out log, a page to the on-call channel, a postmortem the next morning. Every one of those steps is friction, and every one of those steps is the control.
The alternative is an account that is fast and quiet. That account is not a break-glass account. It is a standing privilege with a reassuring name, and the first time it is used without anyone noticing, you will have lost the ability to tell an emergency from a misuse.
If you are building the recovery checklist that the break-glass account supports, the Recovery Checklist Before You Need It is a useful companion. The break-glass account gets you into the system. The checklist tells you what to do once you are there.
Questions that come up
How many break-glass accounts should a small team have? Microsoft recommends two or more for redundancy. For a team of two to fifteen, two is the practical minimum. One is a single point of failure. More than two multiplies the credential storage and rotation burden without adding much resilience.
Should the break-glass account be a person or a shared account? Microsoft’s guidance says not to associate emergency access accounts with any individual user in the organization, and to store credentials in a known secure location available to multiple members of the administration team. The account is a shared emergency path, not a personal login. The sign-out log is what ties a specific session to a specific person.
What if the system cannot produce an audit trail? Yale’s procedure is explicit: if the system cannot provide an audit trail showing simple account activity like login attempts, break-glass use needs to be carefully considered before implementing, and may require a manual paper log instead. A break-glass account without an audit trail is a standing privilege with no accountability.
How often should the credential be rotated? The sources describe per-login regeneration (Commvault) and post-use disable-or-delete (Yale), but do not specify a fixed rotation interval for offline-stored credentials. The 90-day validation drill is the cadence the sources support. Rotation after every use is the safer default; a fixed calendar rotation is a secondary control.
Does the break-glass account replace normal access controls? No. The sources frame it as a last resort alongside standard controls. Yale’s procedure says standard access controls should be established with sufficient rules to minimize the number of times break-glass needs to occur. The account is the exception path, not the primary one.