Break-glass account/ Notfallkonto (Break-Glass-Konto)

A break-glass account (sometimes called an emergency access account) is a hardened, non-personal administrator identity that exists solely to regain control of systems when normal sign-in paths fail. 

For example, during a directory outage, Single Sign-On (SSO) misconfiguration, or a lockout caused by overly strict Conditional Access rules. Unlike everyday admin users, a break-glass account is isolated from routine work, has unique credentials stored out-of-band, and is invoked only under documented emergency procedures with immediate post-use rotation and review. 

In a mature program, it sits alongside Privileged Access Management (PAM) controls, uses phishing-resistant factors for strong proof of possession, and is continuously monitored even when some guardrails are temporarily bypassed to ensure availability.

How does it affect identity security?

Break-glass accounts reconcile two critical objectives: resilience and restraint. They provide a last-resort path to restore access when primary identity planes are unavailable, reducing mean-time-to-recover for identity incidents. 

At the same time, they can become high-risk if treated like ordinary admins or left with broad, always-on rights. The remedy is to govern them with least privilege, bind their activation to ticketed procedures, and pair their use with compensating controls such as independent logging, session recording, and immediate credential rotation via Secrets management and PAM. 

Many organizations exclude break-glass identities from some runtime policies to guarantee access during outages; when they do, they mitigate with longer and vaulted credentials, strict custody of authenticators, out-of-band alerting to the SOC on any sign-in, and rapid forensics after use. 

Aligning break-glass design with Just-in-Time (JIT) access and Zero Standing Privileges (ZSP) minimizes exposure: the account exists, but privileged scope is kept as narrow and short-lived as operationally possible. Regular reviews and attestations within Identity Governance and Administration (IGA) keep ownership, recovery steps, and audit trails current so an emergency login restores control without creating a new vulnerability.

Case study

A global manufacturer accidentally enforced a new Conditional Access policy that blocked all admin sign-ins through its cloud SSO. Operations teams could not modify the policy because their normal administrator identities were locked out. 

The company had prepared two break-glass accounts in its directory with long, vaulted passwords, phishing-resistant Multi-Factor Authentication (MFA) devices stored in separate safes, and SIEM alerting on any successful or failed attempt. Using one break-glass identity from a dedicated privileged workstation, the responder reversed the misconfiguration, restored normal admin access, and immediately rotated the break-glass credentials. 

Post-incident review in the IGA process verified custody of the authenticators, confirmed logs and approvals, and reduced the account’s standing entitlements to align with ZSP. The event demonstrated why an emergency access path, governed by PAM, least privilege, and rigorous after-action controls, is essential to both availability and security.

‍