Break-glass in the enterprise: the account that defeats every other control

Ask a security architect to describe their identity controls and they will give you a coherent, layered answer. Ask what happens when the identity provider is down and the answer involves a safe, an envelope, and a logbook.

Part of Access governance and certification

Prerequisites

• Your current emergency access procedure, including where credentials are stored and who can retrieve them.
• The exemption list: which conditional access policies, MFA requirements and monitoring rules these accounts bypass.
• Your last twelve months of break-glass invocations, if they were recorded.

Step 1 — Enumerate the exemptions honestly

Emergency accounts are exempt from the controls that could prevent their use during an outage. List them explicitly; most organisations have never written the list down in one place.

Each exclusion is individually justified. Collectively they describe an account with the highest privilege in the estate and the least oversight, which is exactly what an attacker would design if given the chance.

Step 2 — Test whether use is attributable

Run this as a tabletop. Someone used the break-glass account at 02:40 on a Sunday. Answer, using only records:

1. Which human retrieved the credential?
2. Was a second person present, as the procedure requires?
3. What did they do with it?
4. Who authorised the use?
5. Can any of the above be demonstrated to an auditor who assumes nothing?

In most organisations the honest answers are: the logbook says, probably, partially from cloud audit logs if those survived the outage, nobody formally, and no.

Step 3 — Understand the constraint

The reason break-glass attribution is weak is not negligence. It is that any attribution mechanism depending on the identity platform fails in exactly the scenario the account exists for.

So the requirement is unusual: attribution that works when the identity provider, the policy service, the monitoring pipeline and possibly the corporate network are all unavailable.

Step 4 — Offline dual signature

Two people, two hardware credentials, one canonical statement, verified locally against a published key with no network dependency.

{
  "type": "manav-stmt/1",
  "action": "emergency_access_invocation",
  "render": [
    "Incident: [reference or description]",
    "Account: [emergency account identifier]",
    "Intended scope: [systems, actions]",
    "Expected duration: [hours]",
    "Authorising basis: [on-call authority | incident commander]"
  ],
  "invoker": "[credential assertion]",
  "witness": "[credential assertion, distinct authenticator]",
  "at": "[timestamp]"
}

The witness requirement encodes the two-person rule that procedures already require and logbooks already fail to evidence. Distinct authenticators mean one person cannot produce both signatures.

Step 5 — Close the loop

An invocation receipt is the start of a record, not the whole of it. Pair it with a closing statement: what was actually done, when access ended, and whether the credential was rotated afterwards.

Rotation after use is in every procedure and is skipped more often than anyone admits, because the outage is over and the urgency has gone. A closing receipt that records whether rotation occurred makes the omission visible.

Failure traps

1. Requiring network connectivity for the signature. If verification calls anything, it fails in the scenario that matters.
2. Storing the verification key only in the systems that may be down. Distribute it to the devices that will perform verification.
3. Requiring the witness to be a specific named person. Define a role — any second on-call engineer — or the control blocks during the one night that person is unreachable.
4. Treating a missing witness signature as a hard failure. Record the exception and proceed; an emergency control that blocks the emergency has failed.

What a usable break-glass control looks like

The tension is real: a control that fails when the identity provider is down is not a break-glass control. That is why the verification has to be offline and the credential has to be something a responder holds.

Objections and honest limits

“Two signatures will slow an incident.” By the time it takes two people to touch a key. Set against the alternative — an account that bypasses everything and is protected by a text box — that is a good trade.

“We review break-glass use afterwards.” A review that reads a log naming a shared account can establish that the account was used. It cannot establish who used it, which is the question.

Making break-glass provable

1. Require two named signatures. Not one, and not an account.
2. Verify offline against cached keys. Or the control fails exactly when needed.
3. Render what is being granted. Scope and duration, so the signature covers something specific.
4. Treat every use as an incident. With a review that has an artefact to read.

Terms used here

Break-glass

An emergency credential granting broad access, deliberately exempt from normal controls.

Offline verification

Checking a signature against a locally cached key, so the control works when the identity provider does not.

Scope rendering

Displaying exactly what access is being granted and for how long, so the approval covers something specific.

Frequently asked questions

Does this prevent break-glass use? No, and it must not. It records who invoked it, with a witness, in a form that survives the outage and can be verified afterwards.

What if the second person is unreachable? Record the exception and proceed. Blocking emergency access to enforce a witness requirement would be a worse outcome than the attribution gap.

Can we not rely on cloud audit logs? They frequently capture the account's actions and not the human behind them, and during a platform outage they may be delayed or incomplete — which is precisely when you need them.

How often should we test this? Quarterly, as a drill on a non-incident. Organisations discover during drills that the envelope is in a safe nobody on-call can open.

Why can't break-glass depend on the identity provider? Because the identity provider being unavailable is one of the scenarios break-glass exists for. Verification must work offline.

Is two signatures too slow for an incident? It is the time for two people to touch a key. Against an account that bypasses every control, that is a good trade.

What does after-the-fact review achieve today? It establishes the account was used. It cannot establish who used it.

Sources and further reading

• Cloud provider emergency access account guidance and exclusion recommendations.
• CISA — known exploited vulnerabilities and incident reporting
• Audit standards addressing privileged access and emergency procedures.
• Two-person control practice in high-consequence environments.
• NIST SP 800-53 Rev. 5 — access enforcement