Break-glass procedures exist for the moment everything else has failed: the identity provider is down, the on-call engineer can't authenticate normally, and someone needs privileged access right now to fix it. Every mature access program has one. In practice, many organizations have never exercised it end to end, which means the procedure that gets used in a real crisis can end up being tested for the first time under the worst possible conditions.
This is a strange gap given how much rigor goes into everything else in a PAM program. Standing privilege gets reviewed, sessions get logged, approvals get workflow. But the emergency path around all of that tends to be a runbook in a wiki, a shared credential in a safe, or a break-glass account nobody has logged into since it was provisioned. Nobody tests it because testing it means simulating an outage, and simulating an outage is disruptive and easy to postpone. So it gets postponed, often indefinitely.
The instinct we push back on is treating break-glass as a static bypass — a credential outside the system, kept for when the system stops working. That framing is exactly why it doesn't get tested: it's designed to sit unused. We think about it instead as still an access-control problem, just one with a different trigger. The request is still a request, the grant should still be time-boxed, and the session should still be logged and revoked. What changes is that the approval step is emergency-shaped rather than routine-shaped — faster, with different evidence requirements, but not absent.
What testing actually looks like
Testing a break-glass procedure doesn't require staging a real outage. It means walking through the actual sequence: can the designated person retrieve the credential or trigger the grant without depending on the very system that's down, does the access expire automatically afterward, and does the usage generate the same audit trail a normal privileged session would. A common pattern is that the first walkthrough is where organizations discover a hidden dependency — the emergency path quietly relies on the same system it's meant to work around, or the mechanism for retrieving the credential turns out to be less reliable than assumed.
The fix is rarely more process. It's usually removing that hidden dependency and making sure revocation is automatic rather than a follow-up task someone forgets after the incident is resolved. A break-glass path that grants standing access and never gets cleaned up isn't an emergency control anymore — it's just an unmonitored privileged account with a good excuse.
The reason this control gets neglected is the same reason it matters most: it's invoked exactly when attention is scarcest and stakes are highest. A break-glass procedure is still a person, or a service account, or increasingly an automated agent, requesting access to a system — the discipline is identical to every other access decision, it's just compressed into a worse moment. Treating it as a separate, untested category is how the emergency exit becomes the least-guarded door in the building.