What Break Glass Access Reveals About Trust

Break glass access is the emergency procedure that bypasses normal access controls when something has gone catastrophically wrong. The name comes from the physical analogy: when there is a fire, you break the glass and pull the alarm. You don't wait for authorization. You act, and you deal with the paperwork afterward.

In digital systems, break glass accounts are the admin credentials kept in a vault for when the identity provider is down, when a critical system is locked out, when something has failed in a way that requires access the normal process can't provide in time. Every organization of any size has some version of this. Most have more versions of it than they know about.

What's interesting about break glass access is not the access itself. It's what the existence and design of break glass procedures reveals about how an organization actually thinks about trust.

The trust model exposed

Normal access control systems encode a trust model: this person, in this role, gets access to these resources. The trust is calibrated, scoped, audited. Someone decided what level of access was appropriate and built controls around it.

Break glass access suspends that model. It says: in a sufficiently extreme emergency, we need to be able to override the controls entirely. An authorized person can access anything. The audit trail might be incomplete. The normal approval process is skipped.

The interesting question is: who is that authorized person? How was that decision made? What does it say about who the organization actually trusts when the formal trust model breaks down?

In most organizations, the answer is surprisingly informal. The break glass credentials exist in a password manager, or a sealed envelope in a safe, or a shared document that three senior people have access to. The process for using them is documented somewhere, probably. The last time they were used was... uncertain. The last time the credentials were rotated was also uncertain.

"Break glass access is not a backup system. It's a confession about what the organization believes would happen if the normal system failed completely."

What good break glass design looks like

A well-designed break glass system has several properties that most implementations lack. First: the accounts are genuinely separate from normal identity infrastructure. They don't authenticate through the identity provider that might be down. They have their own credential chain that is deliberately independent.

Second: every use generates an alert. Not just a log entry that someone might review in an audit — an immediate, loud, multi-channel alert that break glass access was used, by whom, for what stated reason. The transparency is the point. If someone is using break glass access, everyone who matters should know immediately.

Third: the accounts are tested regularly. This sounds obvious. In practice, many organizations discover during an actual emergency that their break glass credentials have expired, or the vault that holds them requires credentials to access, or the person who knows the procedure is on vacation.

Fourth: the design of the break glass system reflects a specific threat model. What exactly are you protecting against? Identity provider outage is different from ransomware that has encrypted your PAM solution is different from a terminated admin who changed credentials on the way out the door. Good break glass design starts from a specific failure scenario and works backward.

The broader lesson

Every identity system has a break glass layer, even if it's not called that. The question is whether it's designed or accidental. The root account in AWS that nobody uses but that has to exist. The local administrator account on servers that bypasses Active Directory. The emergency contact at the identity provider who can reset things manually. The executive who can call the CEO of the SaaS vendor directly.

These are all break glass mechanisms. They exist because the formal trust model has edges and the organization knows it. The difference between a secure organization and an insecure one is often not whether the break glass layer exists — it almost always exists — but whether it's been thought about, designed, tested, and audited.

If you want to understand how an organization actually thinks about trust and accountability, don't look at their access control policies. Look at their break glass procedures. Look at who has access to the emergency accounts and how that decision was made. Look at how long it's been since those credentials were last rotated and last tested. Look at what happens when someone uses them.

The break glass layer is where the formal trust model ends and the real trust model begins. They are often quite different things.