Who is accountable when break-glass access is used during a P0 incident?

Accountability should sit with the incident owner, the privilege owner, and the governance function that defines the emergency access policy. The process should require a clear reason for use, a named approver or authoriser where possible, and a documented closure step so responsibility does not disappear after recovery.

Why This Matters for Security Teams

Break-glass access is not just a technical exception. It is a governance decision that temporarily suspends normal privilege controls during a P0 incident, so accountability has to be explicit before the emergency occurs. If the owner is unclear, teams often overuse standing access, rely on informal approvals, or fail to document why the access was justified. That creates audit gaps, weakens post-incident review, and can turn an emergency measure into a permanent privilege path.

The practical risk is higher in environments where non-human identities already have broad reach. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is why emergency access must be treated as a controlled exception, not an informal rescue option. The control expectation is consistent with the OWASP Non-Human Identity Top 10, which stresses tighter lifecycle and privilege governance for machine identities. In practice, many security teams discover accountability failures only after the incident is closed and no one can prove who authorised the privilege escalation.

How It Works in Practice

Accountability for break-glass access should be shared, but not blurred. The incident owner is accountable for the operational decision to invoke the exception, the privilege owner is accountable for the design and scope of the access path, and the governance function is accountable for the policy that defines when emergency access is allowed and how it must be reviewed. That division matters because a P0 incident compresses time, but it does not eliminate control.

Good practice is to require three things at minimum: a stated reason for use, a named approver or authoriser where the environment allows it, and a closure step that proves the elevated access was removed or expired. Current guidance suggests that the closure step should be logged as part of the incident record, not handled as an afterthought. For NHI-heavy environments, this often means pairing the emergency path with time-bound credentials, scoped access, and automatic revocation. The operational logic aligns with the broader lifecycle discipline described in NHIMG’s Ultimate Guide to NHIs and with the OWASP guidance on machine identity privilege minimisation.

• Define who can declare a break-glass event before the outage happens.
• Log the incident ticket, justification, approver, start time, and end time.
• Make revocation automatic wherever possible, especially for NHI credentials.
• Review every use in post-incident governance, not only in technical remediation.

Where this breaks down is in 24/7 operations with no available approver and no automation for expiry, because emergency access then becomes a manual trust exercise instead of a controlled exception.

Common Variations and Edge Cases

Tighter break-glass controls often increase incident friction, so organisations have to balance fast recovery against the risk of unaudited privilege use. There is no universal standard for this yet, especially where regulated environments, legacy platforms, and outsourced operations overlap. In some teams, the incident commander is the effective authoriser; in others, the privilege owner must sign off; in highly mature environments, policy may allow self-authorisation only when evidence of system failure is recorded and reviewed later.

The key edge case is when the break-glass path is used for a non-human identity rather than a person. That is where time-to-live, secret rotation, and post-use revocation become critical, because machine credentials can be reused faster and more silently than human accounts. The 52 NHI Breaches Analysis and OWASP guidance both reinforce that emergency privilege should not become standing privilege by accident. Current guidance suggests keeping the accountability model simple enough that it survives chaos: one owner for the incident, one owner for the privilege, and one policy authority for the exception process.

That model also helps when break-glass use is repeated across a prolonged P0. In that case, the governance function should decide whether the event remains an exception or whether the incident has become a sustained operating state that demands a formal change, not continued emergency access.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access causes a production incident?
• How should security teams govern API keys used for generative AI access?
• Who should be accountable for break glass access when a breach occurs?
• Who is accountable when sustained infrastructure attacks disrupt access and availability?