Modern identity platforms rely on strong authentication, conditional access, and least privilege to protect privileged accounts. These controls strengthen security. But they can also block legitimate administrators from reaching critical systems during an identity provider outage, an authentication failure, or a policy misconfiguration.
A break glass account provides a secure recovery path when standard administrative access is unavailable. To work when it matters most, the account needs careful provisioning, protection, monitoring, and testing. Creating an emergency access account alone is not enough.
In Bitwarden, you would create a service account as an "Owner" and then store the credentials and MFA outside of Bitwarden, in a secure place that can be accessed by authorized members. One option is using Log in with Passkey (such as a Yubikey) which bypasses the need for entering a username, a password, and even 2FA. Just store the yubikey and its access PIN in a safe, and you have an easy way to regain access. Learn more about owners here.
This guide covers how to set up a break glass account, when to use one, and the governance practices that keep emergency access ready without weakening day-to-day security.
Setting up a break glass account involves more than creating a privileged user account. Organizations typically follow five steps:
Create at least two independently managed emergency access accounts with shared organizational ownership.
Provision the accounts outside the primary identity dependency chain.
Secure credentials with controlled storage and documented retrieval procedures.
Configure only the policy exclusions necessary for emergency access.
Monitor, audit, and regularly test the accounts to keep them usable.
The sections below walk through provisioning, credential security, governance, monitoring, and testing in detail, starting with when a break glass account should and shouldn't be used. For platform-specific configuration guidance, see the administrative break glass account configuration.
A break glass account is a highly privileged emergency access account reserved for situations where standard administrative accounts cannot be used. Common triggers include identity provider outages, multifactor authentication (MFA) failures, conditional access lockouts, or incident response scenarios that require immediate administrative recovery.
Unlike a standard privileged administrator account, a break glass account is not intended for routine operational work. It should stay inactive unless an authorized emergency requires its use. Frequent or unnecessary use weakens confidence in the control, complicates auditing, and raises the risk of unauthorized access.
Treating a break glass account as a governed recovery mechanism, rather than a convenience account, preserves both security and operational resilience.
Provisioning a break glass account starts by removing unnecessary dependencies that could block access during an emergency. Organizations typically address this by:
Creating cloud-only accounts in Microsoft Entra ID environments that stay available even if federated identity services go down
Establishing accounts within an enterprise identity and access management (IAM) solution that supports centralized administration, role-based access, and auditing
Assigning only the privileged roles required for recovery
Documenting ownership and reviewing configurations after significant identity or policy changes
A single break glass account is a single point of failure. Most organizations maintain at least two, independently managed, to guarantee emergency access survives a credential issue or personnel change.
Emergency accounts | Maintain at least two independently managed accounts | Single point of failure |
Identity source | Use cloud-only accounts where appropriate | Federated identity outage |
Role assignment | Assign only required emergency administrative roles | Excess standing privilege |
Account ownership | Organizational ownership with documented custodians | Personnel changes or orphaned accounts |
Configuration reviews | Review accounts after major identity or policy changes | Configuration drift |
Securing break glass credentials matters as much as provisioning accounts. Strong credential generation, secure storage, and dual-control retrieval procedures help authorized administrators recover access without introducing new risk.
Store break glass credentials in a secure enterprise password manager or a privileged access management (PAM) solution that supports encryption, access controls, and audit logging. Depending on organizational requirements, an encrypted offline copy or sealed physical backup supports the disaster recovery plan. Document retrieval procedures require dual-control approval where appropriate and restrict access to authorized personnel.
Modern break glass accounts use phishing-resistant multifactor authentication, such as FIDO2 security keys or passkeys, whenever organizational requirements permit. Earlier break glass strategies often relied on password-only accounts to guarantee access during authentication outages. Organizations now strengthen security while maintaining documented recovery procedures if hardware authenticators or supporting identity services become unavailable.
Bitwarden guidance on two-step login for high-risk accounts and break glass account passkey requirements outlines how to align emergency access with current authentication practices. Review authentication methods periodically to confirm they continue supporting secure emergency access.
A break glass account should bypass only policies that could prevent administrators from restoring access during an emergency, such as conditional access exclusions for device compliance or trusted location requirements. Review these policies regularly to ensure designated break glass accounts remain usable during a lockout. Every exclusion should be documented, narrowly scoped, and tested as part of ongoing governance.
For example, requiring all administrator accounts to authenticate from compliant devices could unintentionally block emergency access if device compliance services go down. A limited exclusion for designated break glass accounts preserves recovery access without weakening security elsewhere.
Administrators should validate that policy changes have not inadvertently removed or expanded emergency access.
The final step is confirming that emergency accounts stay ready when needed. Because break glass accounts are rarely used, any activity warrants immediate attention.
Ongoing monitoring should include:
Sign-in attempts on break glass accounts
Credential changes
Privilege modifications
Prompt investigation of unexpected activity
When emergency credentials must be shared, controlled access and auditability, rather than email or chat, keep the process secure.
After every emergency use, complete these follow-up steps:
Document the incident and capture supporting evidence
Confirm retrieval procedures were followed
Rotate credentials
Verify that permissions and recovery procedures remain current
Regular testing should include controlled dry runs, without normalizing routine use of the account. These dry runs validate sign-in, the availability of privileged roles, monitoring and alerting, and credential retrieval procedures. Emergency access vault management workflows should be included in recovery exercises to confirm designated contacts and to verify that approval processes function as expected. Documenting the testing cadence, approvers, and results helps identify configuration drift before an actual emergency.
Effective emergency access depends on secure credential storage, controlled access, centralized identity management, and ongoing visibility into privileged account activity. Encrypted credential vaults, SSO integration, enterprise policies, role-based permissions, auditable event logs, and secure sharing reinforce documented recovery procedures and operational readiness.
Enterprise break glass accounts differ from Bitwarden emergency access. Bitwarden emergency access enables trusted individuals to access another user's vault under predefined conditions, while break glass accounts restore administrative access to enterprise systems during exceptional circumstances.
A well-designed break glass account strengthens organizational resilience by enabling administrators to recover access without weakening everyday security controls. Learn how enterprise security consolidation and access management simplify privileged credential management and strengthen an emergency access strategy today.
What is a break glass account?
A break glass account is a highly privileged emergency access account used to restore administrative access when standard authentication methods or identity services are unavailable. It should stay inactive except during approved emergency situations.
How many break glass accounts should an organization have?
Most organizations maintain at least two independently managed break glass accounts. This reduces the risk of losing emergency access because of a single account failure, credential issue, or personnel change.
Should a break glass account use multifactor authentication?
Yes, when possible. Many organizations protect break glass accounts with phishing-resistant multifactor authentication methods, such as FIDO2 security keys or passkeys. Documented fallback authentication procedures confirm emergency access remains available if primary authentication methods are unavailable.
How often should a break glass account be tested?
Organizations should test break glass accounts regularly as part of disaster recovery or identity resilience exercises. Testing should verify authentication, privileged role assignments, monitoring, credential retrieval procedures, and documented recovery workflows without normalizing routine use of the account.
What is the difference between a break glass account and Bitwarden emergency access?
A break glass account restores administrative access to enterprise systems during an identity or authentication emergency. Bitwarden emergency access allows designated trusted contacts to access another user's vault under predefined conditions. Both support business continuity, but they serve different purposes and work best as complementary recovery mechanisms.