Break Glass Access: How Emergency Access Works and How to Keep It Accountable

Most access controls are designed for routine operations. But what happens when the identity provider goes down, administrators lose access to critical systems, or a clinician needs to open a restricted patient record during an emergency? Break glass access provides a predefined way to recover access or override normal restrictions when the situation demands it. The challenge is making sure that emergency access remains available without creating an unmonitored backdoor.

Those emergency paths are also attractive targets. Microsoft blocks 7,000 password attacks every second, and a break glass account protected only by a long password sits in that line of fire. Microsoft has expanded mandatory MFA requirements for administrative access to services such as Azure, Microsoft Entra and Intune. Emergency access accounts require special consideration: organizations should ensure they remain usable during an outage while protecting them with authentication methods that do not depend on the systems they are designed to recover. In healthcare, the HIPAA Security Rule lists an emergency access procedure as a required safeguard.

This guide covers how break glass access works, where it is required, how to set up a break glass procedure, and the mistakes that turn an emergency path into a permanent backdoor.

What is Break Glass Access?

Organizations should define in advance the circumstances that justify emergency access. These typically involve a critical system outage, an inability to authenticate through normal channels, or a time-sensitive operational or clinical need that cannot be addressed through standard access procedures.

Break glass access is a pre-approved way to bypass normal access controls during an emergency, using credentials or permissions reserved for that purpose, limited in time, and audited on every use. The name comes from fire alarms behind a glass panel: anyone can pull it in a real emergency, and everyone knows when it has been pulled.

The term covers two related practices.

Break Glass Accounts in IT and Identity Systems

A break glass account, also called an emergency access account, is a highly privileged account created in advance for when the normal way in stops working. It sits outside your SSO, federation and PAM workflows so it still works when those systems are down. Its job is narrow: restore access, fix the problem, and go back in the safe.

Break-the-Glass in Healthcare EHRs

In electronic health records (EHRs), break-the-glass functionality allows an authorized clinician to access a restricted patient record when a legitimate care need requires it. Depending on the EHR and organization’s policies, the workflow may require the clinician to provide a reason, trigger additional authentication or approval, and generate an audit event for subsequent review.

When Organizations Need Break Glass Access

Break glass access is for situations where the normal path is unavailable. Common triggers include:

• IdP or SSO outage: Federation fails and no administrator can sign in to fix it. Because every admin account depends on the same identity provider, one outage can lock out the entire IT team at once. A break glass account that authenticates locally, outside the IdP, is often the only way back in to restore the connection.
• PAM or password vault failure: If emergency credentials live inside the PAM tool that just went down, that tool becomes a single point of failure. Vaults fail for ordinary reasons too, such as an expired certificate, a failed upgrade or a database outage. Keeping at least one sealed credential outside the vault means a PAM problem stays a PAM problem instead of a company-wide lockout.
• MFA provider or carrier outage: Admins cannot receive push notifications or SMS codes. Phone-based methods depend on mobile networks and third-party services that sit outside your control. Emergency accounts protected with hardware passkeys or certificates keep working when those services do not.
• Ransomware or account takeover: Attackers disable, lock or reset admin accounts. Removing defenders’ access is a common step before encryption or data theft, since it slows the response. A break glass account that attackers have not discovered gives your team a clean path to contain the incident and revoke compromised sessions.
• No administrator available: The last global admin has left, is locked out, or cannot be reached. This happens more often in smaller teams, after layoffs, or when admin rights were concentrated in one person. Without a pre-staged emergency account, recovery can mean days of waiting on vendor support to prove ownership of your own tenant.
• Clinical emergencies: An emergency department clinician needs a record flagged as sensitive or belonging to a patient outside their unit. Delays here affect care, so the override has to be fast enough to use at the moment. The documented reason and audit trail let compliance teams confirm afterward that the access was justified.

Break Glass Access and HIPAA Compliance

Under HIPAA Compliance, covered entities and business associates must establish procedures for obtaining necessary ePHI during an emergency. It is a required implementation specification, so a missing procedure is a compliance gap on its own.

Auditors typically look for three things:

• A written procedure stating who can break glass, under what conditions, and with whose approval
• Logs showing who used emergency access, when, and the reason given
• Evidence that those logs are reviewed

HIPAA does not prescribe a universal break-the-glass prompt for every patient record. Organizations must implement appropriate access controls and procedures to ensure that ePHI is available when needed for permitted purposes while limiting access to authorized users. Whether a specific EHR override workflow is appropriate depends on the organization’s risk analysis, policies and operational requirements.

How to Set Up a Break Glass Procedure

Define Trigger Conditions and Approvers

List the specific events that justify emergency access, who can request it, and who approves it. For EHRs, decide which record types are restricted rather than applying break-the-glass to everything.

Pre-Stage at Least Two Accounts Outside Your IdP

Microsoft recommends maintaining at least two cloud-only emergency access accounts for an Entra ID tenant. These accounts should be independent of on-premises identity infrastructure and protected using authentication methods that remain available if normal sign-in services fail.

For other critical systems, determine the appropriate number and type of emergency accounts based on the platform’s recovery requirements and the organization’s risk assessment. Avoid assuming that the same account model applies to every system.

Use Phishing-Resistant Authentication, Not an MFA Exemption

Older guidance told teams to exempt break glass accounts from MFA. That advice no longer holds. Microsoft recommends passkeys (FIDO2) or certificate-based authentication for emergency accounts. Store hardware keys in separate secure locations and keep PINs apart from the keys.

Reliability matters as much as security here. Microsoft found that people sign in successfully with a passkey 98% of the time, compared with 32% for passwords. During an outage, a failed password attempt costs more than a few seconds.

Require a Reason and Alert on Every Use

Every emergency access event should generate an audit record that captures the account or user, time of access, system or resource accessed, and the reason for activation where applicable. Send alerts to the appropriate security or operations team, and record privileged sessions when the platform supports it.

After the event, review the activity to confirm that access was justified and that no unauthorized actions occurred. Emergency access should never be invisible to the people responsible for security and compliance.

Rotate, Review and Test After Every Activation

After each use, rotate or reseal the credentials, review every action taken during the session, and document the outcome. Test emergency access on a defined schedule and after significant changes to identity providers, authentication policies, account credentials or key storage. Confirm that the account can be used as intended, that alerts and audit logs are generated, and that the recovery process works without relying on the systems it is designed to bypass.

Common Break Glass Access Risks and How to Avoid Them

Shared Credentials with No Individual Attribution

When five administrators share one account, the log says “BG_Admin,” not who signed in. The same problem appears in EHRs when a clinician breaks the glass on a shared workstation under someone else’s open session. The override is logged, but against the wrong person.

Using Break Glass as a Workaround

If emergency access is too easy, staff start using it for routine problems, such as getting past a forgotten password or a slow login. The second-order effect is worse: when overrides become routine, reviewers stop reading them, and real snooping hides in the noise.

Accounts Nobody Monitors or Tests

An untested account often fails when it is needed most, because a password expired, a key was lost, or a policy change blocked it. An unmonitored one can be used by an attacker for weeks without anyone noticing.

Break Glass Access on Shared Devices and Frontline Workflows

In hospitals, plants and warehouses, much of the work happens on shared workstations, nursing station PCs and tablets on carts. That creates a specific problem for break glass access: the audit trail is only as good as the identity behind the session.

If staff stay signed in to avoid slow logins, or share a generic account to get through a shift, every emergency override inherits that ambiguity. The fix is not more prompts. It is sign-in fast enough that people stop working around it, with every session tied to one verified person.

OLOID gives frontline teams passwordless authentication built for shared devices, so each user signs in individually in seconds. When someone breaks the glass, the record shows who it was.

Keep Emergency Access Secure, Available and Accountable

Break glass access exists because controls fail. A strong procedure keeps it available in a crisis, protected with phishing-resistant authentication, and attributable to a specific person every time. OLOID helps healthcare and frontline organizations remove shared logins from shared devices, so emergency access stays fast and accountable.

FAQs

1. How many break glass accounts should an organization have?

Microsoft recommends at least two cloud-only emergency access accounts for an Entra ID tenant. For other critical systems, organizations should determine the appropriate number based on their recovery requirements, risk assessment and platform guidance.

2. Should break glass accounts have an MFA?

Emergency accounts should use secure authentication that remains available when normal identity services fail. Microsoft recommends phishing-resistant methods such as FIDO2 security keys or certificate-based authentication for Entra ID emergency access accounts. Organizations should ensure that authentication policies do not prevent emergency access when it is needed.

3. What is breaking glass in healthcare?

In healthcare, break-the-glass functionality allows authorized clinicians to access restricted patient records when a legitimate care need requires it. Depending on the EHR and organizational policy, the workflow may require a reason, additional authentication or approval, and subsequent audit review.

4. Is break glass access required by HIPAA?

HIPAA requires covered entities and business associates to establish an emergency access procedure for obtaining necessary ePHI under 45 CFR §164.312(a)(2)(ii). It does not prescribe a universal break-the-glass prompt for every patient record. Organizations must implement appropriate access controls and procedures based on their risk analysis and operational requirements.

5. How often should you test break glass accounts?

Test emergency access accounts on a defined schedule and after significant changes to authentication policies, identity providers, credentials or key storage. Verify that the accounts remain accessible, alerts and audit logs work, and the recovery process does not depend on the systems it is designed to bypass.