Product decisions
What a good break-glass control actually costs you
Every vendor that sells emergency access describes what it gives you. This is what ours takes away, written down before you turn it on rather than discovered after.
We shipped break-glass approval this week. It lets a person who has requested access, and been left waiting, approve their own request once a set time has passed — and it tells everyone who should know the moment they do. It is off by default, and the setting that turns it on opens with the words "Read this before turning it on."
This post is the long version of that warning. A security feature whose cost you learn about afterwards is a security incident you learn about afterwards.
The cost, in one sentence
"This package requires approval" becomes "this package requires approval, or thirty minutes of patience."
Anyone who can request a package can, with break-glass on, eventually hold it without anyone agreeing. That is not a side effect we failed to design out. It is the feature. The whole point is to get somebody through an approval when the approver is unavailable, and the only way to do that is to make the approval conditional on the approver being available.
If that sentence makes you uncomfortable, good — it should be a decision, not a default. Everything else in this post is about how uncomfortable it needs to be.
Including the package that grants admin
In TemprBac, admin rights to TemprBac itself are an access package like any other. That is deliberate — it means nobody holds standing admin in the product that exists to end standing admin — but it has a consequence here that we would rather state than let you find:
An org that turns on break-glass has decided that any member who can see the admin package can become an org admin after the wait, and that being told about it afterwards is enough.
For a two-person team whose real alternative is one of them holding admin permanently, that is plainly the better arrangement. For a four-hundred-person company whose admin package is visible to everyone, it is a surprise. The setting names the admin package in its warning for exactly this reason.
What you can do about it today is narrow who can see the admin package. A package's audience decides who can see and request it, and a package nobody outside the audience can request is a package nobody outside it can break the glass on. We have not yet built a per-package switch that excludes one package from break-glass while leaving the rest reachable. It is the obvious next step, and until it exists the honest description of the setting is the one above: it is org-wide.
What you get instead of a block
Noise, on a clock. Here is the timeline with the default wait and a four-hour package:
| When | What happens |
|---|---|
| 0:00 | The request is raised. The approval email leaves on the Worker's next pass, which runs every ten seconds. |
| 0:00 – 0:30 | Nothing new. Any approver can still approve or deny it the ordinary way, and if one does, break-glass never enters the picture. |
| 0:30 | The request turns red on the requester's own Approvals tab, and only there. Nobody else is offered the glass — an approver already holds the ordinary buttons. |
| When they use it | Two confirmations and a written reason of at least twenty characters. The decision is recorded the instant they confirm. |
| Seconds later | The Worker grants the access through the same path as any approval, and on its own ten-second pass emails the package's approvers and the org's admins with who, which package, how long it waited, and the reason. |
| Any time | An admin can remove the access early, and so can the requester once they are done. Removal is never blocked by anything. |
| Four hours after the grant | The access is removed automatically, exactly as an approved grant would be. |
| Permanently | A row in the Break-glass usage report: who, what, how long they waited, whether the access is still live, when it was removed, and what they said. |
Both groups are told, not one or the other. The approvers need to know because their queue was skipped; the owners need to know because their policy was. A notification that went only to whichever group happened to be configured would be the quiet version of this feature, and the quiet version is just an approval requirement that does not work.
What it does not cost you
- Longer access. A break-glass grant gets the package's ordinary window, 1 to 8 hours depending on how the package is set. There is no emergency grant that outlives a normal one, because there is no emergency grant path at all: break-glass writes an ordinary approval with a marker on it.
- A second thing to trust. The code that grants and removes break-glass access is the code that grants and removes everything else, on every request. It is not a special path that only runs during an incident and is therefore never tested.
- A stranded grant if you change your mind. Turning the setting off stops new uses. Anything already granted under it expires on its normal clock.
Why the wait has a floor and a ceiling
The wait can be set from 5 to 60 minutes. Five is the floor because a wait of zero is not break-glass, it is auto-approval, and auto-approval of sensitive access is the exact thing an approval requirement exists to prevent. Five minutes also means the request has genuinely been visible first: the approval email has been sitting in an inbox for minutes, not milliseconds, before anyone can go around it.
Sixty is the ceiling because past an hour this stops being an incident tool. It becomes a slow auto-approve that nobody is watching for, since by then everyone has stopped expecting it. An org that wants a longer wait already has one: an unanswered request closes after 24 hours.
When not to turn it on
- You have an approver rota that actually answers at 2am. Then the glass solves a problem you do not have, and an approval that always gets a human is a better control than any bypass of it.
- Your admin package is visible to a large population, and you cannot narrow its audience. Until the per-package switch exists, that is a real exposure, and the noise is the only thing standing in front of it.
- You have told an auditor "every grant is approved by a second person", in those words. Break-glass makes that sentence false. Change the sentence first — "every grant is approved by a second person, or reported to them immediately with a stated reason and removed on schedule" is a defensible control, but it is a different one.
For everyone else, the comparison that matters is not break-glass versus a perfect approval process. It is break-glass versus what your team actually does at 2am today — which, in our experience, is a standing admin nobody has got round to removing, or a shared password somebody will get round to rotating. We compared those honestly in break-glass vs. standing admin vs. a shared root password, and wrote up the mechanism in break-glass access, without leaving the glass broken.
A trade stated plainly is a control. The same trade discovered later is an incident.