Skip to main content
DataRidge
Category: Access Control

Break-Glass Access

Also known as: Break Glass Access, Break-Glass Procedure, Break Glass Account, Emergency Access Procedure
Simply put

Break-glass access is an emergency procedure that lets an authorized person gain elevated access to a system when normal access methods fail or are insufficient during a critical situation. It works by bypassing the usual authorization controls, typically using specially designated high-privilege accounts that are held in reserve for such emergencies. The term draws its name from the idea of breaking the glass on a fire alarm: it is meant to be used only in genuine emergencies.

Formal definition

Break-glass access is a controlled form of privileged access invoked in emergency situations, in which a user with normally insufficient rights is granted elevated permissions to bypass standard authorization controls. Implementations commonly rely on pre-staged emergency accounts provisioned so they can be made available with reasonable administrative overhead. Break-glass is an information security control concerned with the availability of access during failure or emergency conditions; it is distinct from routine access provisioning and, because of its elevated risk, is generally paired with governance measures such as monitoring, logging, and after-the-fact review, though the specific controls and audit expectations depend on the implementing organization and applicable regime. This entry does not address the specific logging, retention, or review obligations that a given framework (for example HIPAA in a healthcare context) may impose, nor does it cover how break-glass interacts with data protection obligations, which vary by jurisdiction and system.

Why it matters

Break-glass access addresses a fundamental tension in access control: the same restrictions that protect a system during normal operation can become an obstacle when a genuine emergency demands rapid, elevated access. Without a pre-defined emergency procedure, responders may improvise workarounds under pressure, sharing credentials informally or disabling controls in ways that leave no reliable record. A break-glass mechanism gives organizations a sanctioned, bounded path to elevated access so that availability of access is preserved during failure or crisis conditions without abandoning oversight entirely.

The control matters precisely because it is high-risk by design. It intentionally bypasses the authorization controls that normally guard a system, which means a break-glass account, if misused or compromised, can provide an attacker or an insider with broad privileges. For this reason break-glass is generally paired with governance measures such as monitoring, logging, and after-the-fact review, so that any invocation can be scrutinized and justified. Accountability here depends on demonstrable evidence of who invoked the access, when, and why, rather than on the mere existence of a documented procedure.

The scope of what break-glass requires varies by regime and organization. In a healthcare context, for example, frameworks such as HIPAA may impose expectations around emergency access to critical systems containing electronic protected health information, but the specific logging, retention, and review obligations differ across regimes and implementations. Break-glass is an information security control focused on availability of access; it does not by itself resolve how emergency access interacts with data protection obligations, which vary by jurisdiction and system.

Who it's relevant to

Security and identity engineers
Teams responsible for privileged access management design and maintain the pre-staged emergency accounts, define the conditions under which they may be invoked, and ensure that invocation triggers monitoring and logging. They must balance the availability of emergency access against the elevated risk that a high-privilege reserve account represents if compromised.
Incident responders and operations teams
Those who may need to invoke break-glass access during a critical situation rely on the procedure to gain elevated access when normal methods fail. They benefit from a sanctioned path that avoids improvised workarounds, but they should understand that each invocation is expected to be justifiable and subject to after-the-fact review.
Information governance and audit functions
Governance and audit stakeholders are concerned with demonstrable evidence that break-glass access was used appropriately, including who invoked it, when, and why. Their focus is on the review, logging, and accountability wrapped around the control, which is distinct from the security engineering of the access mechanism itself.
Compliance leads in regulated sectors
In regulated environments such as healthcare, break-glass procedures for emergency access to critical systems may intersect with framework-specific expectations, for example under HIPAA for electronic protected health information. Compliance leads should confirm the specific logging, retention, and review obligations applicable to their regime, as these are not universal and are out of scope for this entry.

Inside Break-Glass Access

Emergency Access Procedure
A predefined mechanism that permits an authorized individual to bypass normal access controls to reach systems or data during an emergency where standard access paths are unavailable or too slow to prevent harm.
Justification and Triggering Conditions
Documented criteria that define when break-glass access may legitimately be invoked, so that its use is limited to genuine emergencies rather than routine convenience.
Elevated or Standby Credentials
The privileged accounts or credentials made available for emergency use, typically held in a controlled state and released only when the procedure is triggered.
Logging and Audit Trail
Detailed, tamper-resistant records capturing who invoked access, when, what was accessed, and the stated justification, supporting the demonstrable accountability that governance frameworks generally require.
Post-Access Review
A follow-up process to validate that each invocation was warranted, to detect misuse, and to remediate any residual elevated access after the emergency ends.
Governance and Security Overlap
Break-glass sits at the intersection of information security access control (confidentiality and availability) and data governance (ownership, accountability, and policy). The security controls enforce access while governance defines who is accountable and how use is evidenced.

Common questions

Answers to the questions practitioners most commonly ask about Break-Glass Access.

Does having a break-glass access mechanism mean the emergency access itself is automatically compliant or authorized?
No. A break-glass mechanism is a controlled path for exceptional access, not a blanket authorization. Each invocation still constitutes a processing activity that must have a defensible basis and must be justified, logged, and reviewed after the fact. The existence of the mechanism does not, by itself, make any given emergency access lawful or appropriate; that generally depends on the circumstances, the applicable policy, and, where personal data is involved, the relevant data protection regime. Accountability requires demonstrable evidence that the access was warranted, not merely the availability of the feature.
Is break-glass access the same as ordinary privileged or administrative access?
No, though they are frequently conflated. Ordinary privileged access is granted for expected, routine administrative duties and is governed by standing role assignments. Break-glass access is an exception path intended for genuine emergencies where normal access controls would otherwise block a necessary action. It is typically time-bound, requires elevated justification, and triggers heightened monitoring and mandatory review. Treating routine administration as break-glass, or using break-glass to bypass normal least-privilege controls for convenience, undermines both the security control and any governance record that relies on the distinction.
How should break-glass access be logged and reviewed?
Logging should capture who invoked the access, when, the stated justification, the scope of what was reached, and the duration the elevated access remained active. These logs generally need to be tamper-resistant and retained in line with the organization's applicable retention rules, which this entry does not specify. Post-incident review is typically part of the control: each invocation should be examined to confirm it was justified and to detect misuse. Under accountability-oriented governance frameworks, the review evidence itself matters, not only the fact that logging exists.
Should break-glass credentials be time-limited or automatically revoked?
In most implementations, break-glass access is scoped and time-bound so that elevated privileges expire or are revoked once the emergency is resolved. Common approaches include just-in-time elevation, session time limits, and automatic deactivation of the access path after use, followed by rotation of any static credentials that were exposed. The appropriate mechanism depends on the systems involved and the organization's risk tolerance; this entry does not prescribe specific technical settings.
Who is responsible for approving and overseeing break-glass access?
Responsibility is typically split between the parties who own the systems and the parties who own the governance and oversight functions. Approval authority, invocation rights, and review duties should be defined in policy and assigned to identifiable roles rather than left implicit. Where personal data is processed, the data controller generally bears the accountability for demonstrating that emergency access is governed appropriately, while operational execution may sit with system owners or a processor acting under instructions. This entry does not address how these responsibilities are allocated in any specific contract or jurisdiction.
How does break-glass access relate to least privilege and separation of duties?
Break-glass is generally designed as a controlled exception to least privilege rather than a replacement for it. To preserve separation of duties, the person who invokes break-glass access is often distinct from the person who approves or reviews it, and the access itself is confined to what the emergency requires. This keeps the exception path from becoming a routine way to accumulate standing privileges. The specific control design, and how it interacts with an organization's broader access model, falls outside the scope of this entry.

Common misconceptions

Break-glass access is a general-purpose backdoor administrators can use whenever normal access is inconvenient.
It is intended for defined emergency conditions only. Using it as a routine shortcut undermines the control and typically generates audit findings, because each invocation is expected to be justified and reviewed.
Enabling break-glass access on its own satisfies emergency-access or availability requirements in a compliance framework.
No single control guarantees compliance. Break-glass generally needs to be paired with triggering criteria, logging, and post-access review, and its adequacy depends on jurisdiction, applicable framework, and implementation. This entry does not address specific regulatory clauses or penalties.
Because access is logged, break-glass automatically demonstrates accountability.
Logs are necessary but not sufficient. Accountability under governance frameworks generally requires demonstrable evidence that logs are actually reviewed, misuse is acted upon, and elevated access is revoked, not merely that a log exists.

Best practices

Define explicit triggering conditions and scope for break-glass use, and distinguish them clearly from routine privileged access workflows.
Ensure every invocation is logged with actor, timestamp, resources accessed, and justification, and store those records in a tamper-resistant manner.
Require prompt post-incident review of each invocation to confirm it was warranted and to identify and remediate any misuse.
Revoke or rotate emergency credentials immediately after the emergency concludes so elevated access does not persist beyond its need.
Treat break-glass as both a security control and a governance obligation by assigning clear ownership for approval, review, and evidence retention.
Test the procedure periodically to confirm it functions when needed, and document that testing as part of demonstrable accountability.