Who should be accountable for break glass access when a breach occurs?

Why This Matters for Security Teams

break glass access is not just an emergency privilege problem. It is an accountability problem that spans identity, security operations, incident response, and recovery. When a breach is active, teams need to know who approved the emergency account, who used it, what it touched, and when it was returned to dormancy. That chain of custody is central to post-incident trust and to proving that emergency access did not become a hidden standing privilege.

This matters because break glass is often the first exception that becomes normalised under stress. NHI governance guidance treats emergency access as a high-risk identity control, and the OWASP Non-Human Identity Top 10 reinforces that secrets, service accounts, and privileged automation need explicit ownership and review. NHIMG’s 52 NHI Breaches Analysis shows how identity misuse repeatedly sits at the center of compromise patterns, which is exactly why emergency access cannot be left to informal verbal approval.

In practice, many security teams encounter break glass misuse only after audit gaps, not through intentional testing.

How It Works in Practice

Accountability should be split by function, but not diluted by ambiguity. The identity owner is typically accountable for the account lifecycle, the security owner for policy and monitoring, and the incident response owner for activation during a declared event. That structure works because break glass should be a controlled exception with a named approver, a named user, a specific incident ticket, and a defined deactivation step once the emergency ends.

Best practice is to make the approval path explicit before the breach occurs. That usually means pre-authorised emergency access, documented in policy, with alerts to security operations as soon as the account is enabled. If access is used, the event record should capture why it was needed, what systems were touched, and whether any compensating controls were applied. Where possible, the emergency identity should be tied to a distinct workload or admin identity and protected with strong logging, short-lived credentials, and automatic expiry.

Operationally, this is easier when teams treat break glass as a monitored control rather than a last-minute workaround. The 2024 ESG Report: Managing Non-Human Identities is a useful reminder that NHI compromise is not rare, which makes post-event verification of emergency access a real security requirement, not a paperwork exercise. The Anthropic report on AI-orchestrated cyber espionage also underscores how quickly automated adversaries can exploit any privileged exception they discover.

These controls tend to break down in distributed cloud environments where multiple teams can enable access independently and incident records are not synchronised.

Common Variations and Edge Cases

Tighter break glass controls often increase recovery time, so organisations have to balance speed against oversight. That tradeoff becomes sharper during ransomware, outage recovery, or cloud control-plane compromise, where waiting for multiple approvals may slow restoration. Current guidance suggests the answer is not to remove accountability, but to pre-wire it so emergency use is fast, logged, and reviewable.

There are a few common edge cases. In shared services, the identity owner may sit in one team while the incident commander sits in another, so the accountability model should specify who can activate access and who must verify revocation. In regulated environments, a dual-approval pattern may be required for activation, but the same rule should not apply to all emergencies if it would block restoration. For third-party support, accountability should extend to vendor access too, because a break glass pathway used by an external administrator still needs an internal owner and a clear revocation check.

Where there is no universal standard for this yet, the safest approach is to define a single accountable owner for the process, then assign operational responsibilities to identity, security, and IR separately. That aligns with evolving NHI governance expectations in the Ultimate Guide to NHIs — Key Challenges and Risks and helps prevent emergency access from lingering after the incident is closed.

Related resources from NHI Mgmt Group

• Why do access workflows break down when approvals live only in tickets?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when access workflows sit in ITSM but enforcement sits elsewhere?
• Why do manual access request and certification processes break down in SaaS environments?