Break-glass access is logged, reviewed later, and rarely questioned.

Every serious system has a door that opens when the rules say no, because the alternative is a patient who does not get treated or an outage that does not get fixed. The door is fine. What is not fine is that the only thing behind it is a text box and a log that nobody has the information to review.

Two in the morning, twice

An on-call platform engineer is paged at 2:14am. Checkout is failing for about a fifth of customers, the error is coming from a service she does not own, and the team that owns it is asleep in a timezone eight hours away. She has read access to her own team's systems and nothing else, which is correct, and is also why she cannot see the thing that is broken.

So she assumes the emergency role. There is a prompt. It asks her to type a reason. She types "checkout p1, investigating upstream" because that is true and because she is typing it with one hand while reading a dashboard with the other. She gets in, finds a bad config push, rolls it back, and goes back to bed at 3:40am. She did her job well.

Now a different building. An emergency department at the same hour. A patient arrives unidentified after a road traffic collision. The clinician who receives them has no treatment relationship in the record system, which is correct, and is also why she cannot see the allergy list. She clicks through the break the glass prompt, types "trauma activation", and gets what she needs. She also did her job well.

Six weeks later, a compliance analyst opens a spreadsheet with four thousand rows in it. Each row has a person, a timestamp, a record identifier, and a short string of free text. The analyst's job is to determine which of these four thousand accesses were inappropriate.

Consider what the analyst actually has. They have a claim, written by the system, that an account performed an access and that some text was submitted alongside it. They do not have the patient's condition that night, the staffing on that ward, or any way to distinguish "trauma activation" typed by the clinician who was there from "trauma activation" typed by someone who had heard the phrase. In the overwhelming majority of cases they will mark it fine, because it probably was fine, and because the cost of being wrong in the other direction is an accusation against a clinician based on a spreadsheet cell.

What is break-glass access, and why does every system need one?

Break-glass, sometimes called emergency access or break the glass, is a deliberate bypass of normal authorisation. The name comes from the little red boxes with a fire alarm behind glass: the barrier exists to make you think, not to stop you.

It is worth being clear that this is not a design failure or a shortcut. In healthcare it is a legal requirement. The HIPAA Security Rule includes an emergency access procedure as a required implementation specification under access control at 45 CFR 164.312(a)(2)(ii), which means a covered entity must establish procedures for obtaining necessary electronic protected health information during an emergency. The regulator looked at the tension between confidentiality and care and came down, correctly, on the side of the patient being treated.

The same pattern appears everywhere else under different names. Cloud platforms have emergency access accounts. Privileged access management products broker temporary elevation. Infrastructure teams keep a documented path to production for the night everything is on fire. In each case the reasoning is identical: a control that cannot be bypassed in a genuine emergency will either be bypassed unofficially, which is worse, or it will cause the harm it was meant to prevent.

So the door stays. The question is only what the door records.

Why does after the fact review stop working?

The standard answer to break-glass is log and review. The HIPAA Security Rule also requires audit controls at 164.312(b) and regular review of information system activity at 164.308(a)(1)(ii)(D). In cloud and infrastructure, the equivalent expectations appear in the audit and accountability control family of NIST SP 800-53 and in the common criteria that SOC 2 auditors test against.

On paper this is a complete control. In practice it degrades, and it degrades for four reasons that have nothing to do with anyone being lazy.

Volume beats attention

A mid-size hospital generates a very large number of emergency accesses, because the workflows that require them are common: covering clinicians, patients moved between units, unidentified arrivals, and staff filling in on a short-staffed night. Reviewing all of them properly would be a full time job for several people, and reviewing them improperly is what actually happens.

The reviewer does not have the context

This is the deepest problem and the least discussed. To judge whether an access was appropriate, you need to know what was happening clinically or operationally at that moment. The reviewer, six weeks later, has a log line. The information required to make the judgement was never captured, and could not easily have been captured, because it lived in the situation rather than in the system.

The social cost of asking is high

Challenging a senior clinician or a principal engineer about an access from six weeks ago, on the basis of a spreadsheet, is unpleasant, usually wrong, and professionally expensive for the person asking. Organisations respond to this rationally. The reviews get gentler over time.

The evidence is self-attested

The log is written by the system about itself. Where the concern is a compromised session or an insider with legitimate system access, the log is being produced by the environment whose integrity is in question. This is not a hypothetical worry: it is the whole reason external auditors prefer evidence they can verify independently.

Put those four together and you get a control that produces a record nobody acts on. That is worse than having no control, because the organisation believes it is covered. We made the general version of this argument in detection debt: spending that produces the appearance of coverage without the substance accumulates as a liability rather than an asset.

What does a typed reason actually prove?

Almost nothing, and it is worth being precise about why, because the free text box feels like it should be doing something.

The text proves that a string was submitted through a form by a browser session. It does not prove who typed it. It does not prove that the typed reason was the real reason. It is unverifiable by construction, since the whole point is that the system does not know the emergency context. And in the case that matters most, an attacker holding a stolen session, the reason field is simply an extra input the attacker fills in, and they will fill it in convincingly because they can read the placeholder text.

There is one thing the free text box does achieve, and it should not be dismissed: it creates a moment of friction and self-awareness. A person who is about to look at a record they should not look at, and is asked to type why, will sometimes stop. That is a real effect. It is just not evidence.

An analogy. A visitor book in an office lobby does not verify anybody. Its value is that people write their names in it, and knowing that you have written your name changes what you do in the building. But if someone burgles the third floor, the book tells the investigator very little, because the burglar either did not sign it or signed it as somebody else.

Can a stolen session invoke break-glass?

Yes, trivially, and this is the change that makes the old design untenable rather than merely imperfect.

Break-glass was designed against an insider threat model: the person is who they say they are, and the question is whether they should be looking. That model assumed the authenticated user and the human were the same. Session theft broke that assumption at scale. Adversary in the middle phishing kits harvest authenticated sessions after multi factor authentication completes, and infostealer malware harvests session material from endpoints, which is how attackers have reached data platforms holding very large volumes of records using nothing but valid credentials. We covered the mechanics in your MFA worked perfectly and the attacker was already inside the session.

An attacker who holds a valid session and finds an emergency access path has been handed the best tool in the building. The path is designed to bypass authorisation, it is designed to be fast, it is designed not to alert anyone in the moment, and it accepts a free text justification that the attacker writes. This is Session Inherited Authorization pointed directly at the control that was supposed to be the exception.

The same applies to shared on-call accounts, where attribution is impossible even in principle, which we wrote about in the audit log says admin, which human was that. And it increasingly applies to agents: an automated process with infrastructure access that encounters an authorisation barrier and an emergency path will use the emergency path, because that is what it is for.

What would signed break-glass look like?

The design goal is unusual and needs stating up front, because getting it wrong produces a dangerous system. The signature must not gate the access. Nobody should ever be waiting on a cryptographic ceremony while a patient is bleeding or checkout is down. The access is granted the moment it is requested, exactly as it is today.

What changes is that a second thing happens in parallel: the person's enrolled device produces a signature over a structured description of what they are doing and why. If the signature fails or the device is unavailable, the access still proceeds, and the absence of a receipt is itself recorded, which is a far stronger signal for the reviewer than anything they have today.

Here is the payload.

{
  "type":         "breakglass.invoke",
  "actor":        { "emp_ref": "E-40912", "role": "ED attending" },
  "scope":        { "system": "ehr.prod",
                    "subject_ref": "sha256:1c8e...ab30" },
  "reason_code":  "EMERGENT_CARE_NO_RELATIONSHIP",
  "reason_text":  "Trauma activation, patient unidentified on arrival",
  "duration_s":   3600,
  "requested_at": "2026-09-26T02:14:38Z",
  "nonce":        "9d13f0c2ea774b61"
}

And the flow, with the ordering that matters.

digest = sha256(canonical_json(payload))

grant_access_now(payload.scope, payload.duration_s)   // never blocks

sign_in_parallel({
  challenge: digest,
  userVerification: "required"     // biometric or PIN, on their own device
}).then(assertion => {
  attach_to_audit_event({
    payload, digest,
    credential_id: assertion.credentialId,
    signature:     assertion.signature
  })
}).catch(() => {
  attach_to_audit_event({ payload, receipt: "ABSENT" })   // this is a signal
})

Why structured reason codes beat free text

Notice that the payload has both a reason_code and a reason_text. The code is the part that makes review tractable. A reviewer facing four thousand rows of free text has an unbounded reading task. A reviewer facing four thousand rows of eleven possible reason codes has a sorting task, and can go straight to the categories that carry risk, or to the rows where the code and the circumstances disagree.

The free text stays because clinicians and engineers need to say things the taxonomy did not anticipate. It just stops being the primary index.

What the receipt changes for the reviewer

Three things, and the third is the one that matters most.

First, attribution becomes real. The receipt names an individual's credential rather than an account that six people share. That alone solves the on-call rotation problem.

Second, the review becomes sortable, because of the reason codes and because absent receipts sort to the top.

Third, and this is the structural change: the evidence is no longer self-attested. The receipt verifies against a published key. An auditor, a regulator, or the individual defending themselves can check it without trusting the log of the system under examination. That is the same property we described in verifying without calling the issuer, applied to access rather than credentials.

The deterrent effect is worth noting too, and it is not the cryptography doing the work. It is the knowledge that the record of this access carries your personal signature rather than a role name. That changes behaviour at the moment of invocation, which is the only moment where behaviour can still change.

How the designs compare

Honest limits

This does not stop a determined insider with a plausible reason. A clinician who is entitled to invoke emergency access, and who selects a legitimate reason code, will get in and will sign for it. What changes is that the access is attributable to them personally and provably, which is the difference between an investigation that concludes and one that does not. Deterrence and evidence, not prevention.

It adds friction to emergencies, and the budget is seconds. If a signing ceremony takes more than a few seconds, or fails in a stairwell with no signal, it will be routed around and you will have made things worse. The parallel design exists precisely for this, but it must be tested under realistic conditions, including bad connectivity, gloves, and someone else's workstation.

It only works if somebody reviews. This makes review cheaper and more conclusive. It does not make review happen. An organisation that does not look at its emergency access data today will not look at better data tomorrow.

Enrollment is the bottleneck. Every person who might invoke emergency access needs an enrolled device before the emergency, which is an operational programme rather than a switch. Locums, agency staff, and contractors are the hard cases, and they are also disproportionately represented in emergency access.

The identity provider vendors could build a version of this. Privileged access and identity platforms could add a per-invocation prompt on a registered device, and some already prompt for step-up. What they would not produce is an artifact that verifies outside their own system, across the several systems where a single person invokes emergency access, which is the whole point when the question under examination is whether that system's records can be trusted.

No standard covers this. FHIR AuditEvent gives healthcare a structured way to record that an access happened, which is genuinely useful, and it records rather than attests intent. There is no interoperable format for signed emergency access, which is a gap worth naming.

What to do this week

1. Count your emergency accesses for the last quarter. Just the number. Most teams are surprised, in one direction or the other, and both directions are informative.
2. Take a random sample of thirty and try to determine, from the record alone, whether each was appropriate. Time yourself. This exercise ends most debates about whether the current control works.
3. Replace the free text box with eight to twelve structured reason codes, keeping free text as a secondary field. This costs almost nothing and immediately makes review sortable.
4. Identify every emergency path that a shared or role-based account can invoke, and write down which human was on call for each invocation. If you cannot, that is your first fix.
5. Ask whether any automated process or agent in your environment can assume an emergency role. If so, decide deliberately whether it should, and record the decision.
6. Measure your latency budget honestly. How many seconds can you add at 2am before clinicians or engineers route around the control? Design to that number, not to a comfortable one.
7. Ask your auditor what evidence they would accept for emergency access, and specifically whether they distinguish evidence produced by the system under review from evidence produced independently.

Frequently asked questions

How should break-glass access be authorised and audited? Grant the access immediately, and in parallel require a signature from the individual's enrolled device over the resource, a structured reason code, and a duration. Store the receipt with the audit event so a reviewer can verify it independently later. The signature should never block the access, and a missing receipt should be recorded as a reviewable signal in its own right.

Is a typed reason enough for HIPAA break-glass? The HIPAA Security Rule requires an emergency access procedure and audit controls, and does not prescribe a specific technical form, so a typed reason may satisfy an auditor. The security question is separate from the compliance question: a free text field submitted inside a session proves only that text was submitted, which is why it is weak evidence when the access is genuinely disputed.

Can a stolen session invoke break-glass access? Yes. Emergency paths are built to bypass authorisation quickly without alerting anyone in the moment, and they accept a justification the requester writes, so an attacker holding a valid session can use one as readily as the legitimate user. That is why the invocation needs proof from a device the attacker does not hold rather than from the session.

Will requiring a signature slow down emergencies? Not if it is built correctly. The access is granted at the moment of request and the signature runs alongside it, so the clinical or operational path is never waiting. If the device is unreachable, access still proceeds and the missing receipt is logged. Any implementation that blocks the emergency on a cryptographic step has been built wrong.

What is the difference between break-glass and privileged access management? Privileged access management brokers and often records elevated sessions, which is a strong control where it is deployed. It establishes that a session was brokered to an account. Signed break-glass establishes that a specific human authorised a specific emergency access for a stated reason, which is a different claim and the one that answers an auditor's question about intent.

Does this help with record snooping by employees? Partially. It does not prevent someone entitled to invoke emergency access from doing so improperly. It makes the access personally attributable rather than attached to a role or a shared account, it makes the review tractable, and it changes behaviour at the moment of invocation because the person knows their own signature is on it.

Sources

1. HIPAA Security Rule, technical safeguards including the emergency access procedure at 45 CFR 164.312(a)(2)(ii) and audit controls at 164.312(b), eCFR Part 164.
2. US Department of Health and Human Services, Office for Civil Rights, HIPAA compliance and enforcement, hhs.gov.
3. NIST Special Publication 800-53 Revision 5, security and privacy controls, including the access control and audit and accountability families, csrc.nist.gov.
4. HL7 FHIR, AuditEvent resource, hl7.org/fhir/auditevent.
5. W3C Web Authentication (WebAuthn) Level 2, user verification and challenge binding, w3.org/TR/webauthn-2.
6. Manav developer documentation on signed actions and offline verifiable receipts, manav.id/docs. The privileged role grant demo gates an elevation this way.

Keep the emergency door unlocked. Just stop pretending that the sign-in sheet next to it is a security control.