Concept

Break-glass access, without leaving the glass broken

Also written break glass access, and called emergency access. The identity that holds it is usually a break-glass account or an emergency access account.

Every approval control needs an answer for the moment nobody answers. Most of the answers in use today end with somebody holding admin rights they never give back.

The fire-alarm metaphor is exact in one way people tend to skip. The glass is not there to make the alarm hard to pull. It is there so that pulling it is visible — a broken pane that everyone walking past can see, and that somebody has to replace. A break-glass mechanism that leaves no trace, or that nobody ever puts back, is not a control. It is a door.

There are two emergencies, and they need different glass

"Emergency access" gets used for two situations that have almost nothing in common, and most of the trouble in this area comes from answering both with the same tool.

The first emergency has a well-understood answer

When sign-in is broken, you need an identity that does not go through it. Microsoft's guidance on emergency access accounts is the clearest version written down: at least two cloud-only accounts, Global Administrator assigned permanently active rather than eligible, phishing-resistant credentials kept in separate safes, excluded from Conditional Access policies that could block them, an alert on every sign-in, and a drill at least every ninety days. Okta's security team describes the same shape for a super-administrator break-glass account — hardware keys, restricted network locations, and "any use should set off alarm bells in the SOC".

That account holds standing privilege by design, and it should. It is the one exception a zero standing privilege program is built to have: few, sealed, alarmed, and used for the emergency it exists for. Nothing on this page argues for getting rid of it.

The second emergency is the one that actually happens

The far more common night looks like this. The pager goes off, the on-call engineer needs a role they do not hold, the request goes in, and the queue does not move — not because anything is broken, but because the one person who can say yes is not looking at their phone. Every control is working exactly as designed. That is the problem.

The two emergencies get confused because the second one borrows the first one's tool. The sealed account is sitting there, it works, and it is faster than waking a director. So it gets opened for an incident it was never meant for, the credential is now known to one more person, and a mechanism designed to be used once every few years starts being used once a month. The other borrowings are worse, and they are compared side by side in break-glass vs. standing admin vs. a shared root password.

What break-glass for an unanswered approval has to get right

If the second emergency gets its own glass, the design has more to get right than "let them through". Six properties, and the last is the one that decides whether any of it was worth building.

1. A real wait first. Long enough that the ordinary path had a genuine chance — that the approval request reached an inbox and sat there. A wait of zero is not break-glass. It is auto-approval with extra steps.
2. Offered only to someone with no other way through. The person who raised the request, and only when they cannot approve it themselves by ordinary means. Offering the glass to an approver who already holds the Approve button turns the record of necessity into a record of convenience.
3. A reason, in words, at the moment. The sentence typed then is the whole account of why a control was bypassed. It is what the people told will read, and what somebody reconstructing the incident will read weeks later.
4. Everyone whose control was bypassed is told, immediately. The approvers, because their queue was skipped, and the owners, because their policy was. Not a weekly digest — a message that lands while the access is still live, so there is still something to do about it.
5. A record an auditor can ask for by name. Not one line among thousands in a general audit log, but a list whose every row is a person who got past the control.
6. It expires on the same clock as everything else. See below.

Why the expiry is the part that matters

Look at how emergency access usually ends. Somebody opens the shared account, fixes the incident, and goes to bed. Or an administrator adds the engineer to the admin group in the console "for tonight". Or the engineer already had standing admin rights, because that was the previous time's fix. Every one of those ends the same way: the access is still there in the morning, and in six months, and at the next audit. The glass stays broken.

That happens for a structural reason, not a disciplinary one. The emergency path is a different path from the normal one — a different account, a manual console change, a standing grant — and nothing about that path has a clock in it. Removal depends on somebody remembering, on the morning after the worst night of their month.

The fix is equally structural. Break-glass should not have a grant path of its own. It should produce an ordinary approval with a marker on it, and let the ordinary machinery do the rest: provision the access, schedule its removal from the package's normal window, and revoke it when that window closes. A separate emergency grant path would be a second implementation of the most important thing the system does, exercised only in emergencies — which is to say, the one path nobody tests until it matters.

How TemprBac does it

TemprBac grants access as time-bound packages of groups across the systems you already run. Break-glass is an org-level setting, off by default, and when an org turns it on it works like this:

• The wait is between 5 and 60 minutes, defaulting to 30. Five is the floor because anything shorter is auto-approval; sixty is the ceiling because past an hour the feature stops being an incident tool and becomes a slow auto-approve nobody is watching.
• Only the requester sees the glass, and only if they cannot already approve. Their unanswered request appears on their own Approvals tab marked Break glass, with a single button. An admin or a named approver never sees it on their own request — they get the ordinary Approve and Deny buttons instead.
• Two confirmations, and a reason. The first states what will happen and asks why, with a floor of twenty characters so the reason cannot be "x". The second asks again, because the emails cannot be un-sent.
• The package's approvers and the org's admins are all emailed. Both groups, not one or the other, because both need to know. The mail says who, which package, how long the request waited, the reason given, and when the access will be removed.
• It is the ordinary grant path. Break-glass writes an ordinary approval with a marker. The worker that grants every other request grants this one, and removes it when the package's 1-to-8-hour window closes. There is no break-glass grant that outlives a normal one, and it can be removed early from the dashboard — removal is never blocked by anything.
• It has its own report. Break-glass usage, in the Security group, visible to admins: who, which package, how many minutes they waited, whether the access is pending, active or already ended, when it was removed, and the reason in full.