On this page

Break-Glass Access

Break-glass access provides emergency administrative credentials when normal authentication systems fail or when authorised personnel cannot access critical systems through standard channels. You invoke break-glass procedures during incidents where authentication infrastructure is compromised, when the sole administrator is unavailable, or when time-critical recovery requires immediate privileged access that cannot wait for normal approval workflows.

Break-glass account: A pre-provisioned administrative account with credentials stored offline or in a secure vault, accessed only during declared emergencies when normal authentication is unavailable.
Dual control: A security mechanism requiring two authorised individuals to independently provide credentials or approval before access is granted, preventing any single person from unilaterally accessing emergency accounts.
Witness: An individual who observes break-glass invocation without possessing credentials, providing independent verification that procedures were followed correctly.
Sealed credential: A password or key stored in tamper-evident packaging (physical envelope, cryptographic seal, or vault with access logging) that reveals when access has occurred.

Prerequisites

Before invoking break-glass access, confirm the following conditions. Proceeding without meeting these prerequisites creates audit gaps and may invalidate the emergency justification.

You must have documented evidence that normal access paths have failed. This evidence takes the form of error messages, authentication logs, or confirmation from your identity provider that services are unavailable. Take screenshots or copy log entries before proceeding, as these form part of the post-incident record.

You must have authorisation from a designated emergency approver. Your organisation should maintain a list of individuals authorised to approve break-glass invocation, typically including the IT Director, Chief Operating Officer, or designated deputies. In a true emergency where no approver is reachable within 15 minutes, proceed with break-glass access and document the attempts to reach approvers.

You must have a second authorised person available for dual-control procedures. This person must be on the approved break-glass access list. If your organisation uses physical sealed credentials, both individuals must be present at the credential storage location. If using a credential vault with split knowledge, both must have network access to their respective vault components.

You must have a witness if your policy requires one. The witness role differs from the dual-control participant: witnesses observe and document but do not possess credentials. Smaller organisations may combine the witness and second authorised person roles where staffing constraints make three-person requirements impractical.

Prerequisite	Verification method	Fallback if unavailable
Normal access failure documented	Screenshots, log exports, IdP status page	Written attestation with timestamp
Emergency approver authorisation	Verbal approval (recorded), email, messaging	Document attempts; proceed after 15 minutes
Second authorised person	Physical presence or video call	Defer if possible; solo access requires executive approval within 1 hour
Witness (if required)	Physical presence or video call	Document in post-incident report

Gather the following information before beginning credential retrieval: the specific system or account requiring emergency access, your user identifier and the second authorised person’s identifier, current date and time with your time zone, a summary of the incident necessitating break-glass access in two to three sentences, and contact details for the emergency approver who authorised invocation.

Procedure

The break-glass procedure consists of four phases: invocation declaration, credential retrieval, system access, and session documentation. Execute each phase completely before proceeding to the next.

Phase 1: Invocation Declaration

Contact the designated emergency approver using the fastest available channel. State: “I am requesting break-glass access to [system name] because [brief reason]. Normal access has failed due to [cause]. I have [second person name] available for dual control.”
Record the approver’s response, including their name, the time of approval, and any conditions they impose. If using voice communication, send a follow-up message summarising the approval for the written record.
If the emergency approver is unreachable after attempts via phone, messaging, and email over a 15-minute period, document each attempt with timestamps. You may proceed with break-glass access under the emergency exception clause, but you must notify the approver within 1 hour of completing the procedure.
Open an incident ticket or create a written record with the invocation details. The record must include the date and time, your name and role as the declaring party, the second authorised person’s name and role, the witness name and role if applicable, the system requiring access and its purpose, the reason for invocation in two to three sentences, a reference to the evidence of normal access failure, and the approver’s name, role, time of approval, approval method, and any conditions imposed.
```
BREAK-GLASS INVOCATION RECORD

Date/Time: 2024-11-16 14:32 UTC
Declared by: [Your name and role]
Second authorised person: [Name and role]
Witness (if applicable): [Name and role]

System requiring access: [System name and purpose]
Reason for invocation: [2-3 sentence summary]
Normal access failure evidence: [Reference to screenshots/logs]

Approver: [Name, role, time of approval]
Approval method: [Phone/email/in-person]
Conditions imposed: [Any limitations specified by approver]
```
Confirm with the second authorised person that they understand their role and are prepared to participate in credential retrieval. Both parties must verbally acknowledge the invocation before proceeding.

Phase 2: Credential Retrieval

Credential retrieval procedures differ based on your storage mechanism. Follow the section matching your organisation’s configuration.

Physical Sealed Credentials

Physical sealed credentials use tamper-evident envelopes stored in a secure location such as a safe, lockbox, or security deposit box. The envelope contains printed credentials and is signed across the seal to reveal tampering.

Both authorised persons travel to the credential storage location together. Do not photograph or transmit safe combinations or access codes.
Open the secure storage using the appropriate access method. For safes with dual-control combinations, each person enters their portion of the combination in sequence. For key-based storage, use the designated break-glass key stored separately from normal access keys.
Locate the sealed envelope for the required system. Verify the envelope is intact by checking that the seal is unbroken, signatures across the seal are undisturbed, and the envelope has no tears, holes, or evidence of steaming.
If the envelope shows signs of tampering, do not proceed. Document the condition with photographs, return the envelope to storage, and escalate immediately to the security team.
Both authorised persons sign the envelope exterior with the current date and time before opening. This creates an audit trail showing who accessed the credentials and when.
Open the envelope in the presence of both parties and extract the credential document. The document typically contains the account username, password or passphrase, any required secondary factors such as recovery codes or hardware token serial numbers, and the system access URL or connection details.
Record the envelope serial number if present and the date and time of opening in your invocation record.

+----------------------------------------------------------+
|            PHYSICAL CREDENTIAL RETRIEVAL                 |
+----------------------------------------------------------+
|                                                          |
|  +------------------+     +------------------+           |
|  | Person A         |     | Person B         |           |
|  | (Authorised)     |     | (Authorised)     |           |
|  +--------+---------+     +--------+---------+           |
|           |                        |                     |
|           +------------+-----------+                     |
|                        |                                 |
|                        v                                 |
|           +------------+------------+                    |
|           | Travel to storage       |                    |
|           | location together       |                    |
|           +------------+------------+                    |
|                        |                                 |
|                        v                                 |
|           +------------+------------+                    |
|           | Open secure storage     |                    |
|           | (dual combination/keys) |                    |
|           +------------+------------+                    |
|                        |                                 |
|                        v                                 |
|           +------------+------------+                    |
|           | Verify envelope         |                    |
|           | integrity               |                    |
|           +------------+------------+                    |
|                        |                                 |
|           +------------+------------+                    |
|           |                         |                    |
|     Intact|                         |Tampered            |
|           v                         v                    |
|  +--------+--------+      +---------+---------+          |
|  | Both sign       |      | Document          |          |
|  | envelope        |      | Do not open       |          |
|  +--------+--------+      | Escalate          |          |
|           |               +-------------------+          |
|           v                                              |
|  +--------+--------+                                     |
|  | Open envelope   |                                     |
|  | Extract creds   |                                     |
|  +--------+--------+                                     |
|           |                                              |
|           v                                              |
|  +--------+--------+                                     |
|  | Record serial   |                                     |
|  | and timestamp   |                                     |
|  +-----------------+                                     |
|                                                          |
+----------------------------------------------------------+

Figure 1: Physical sealed credential retrieval requiring both authorised persons

Credential Vault with Split Knowledge

Split-knowledge vaults store break-glass credentials in a system where no single person can retrieve the complete credential. Common implementations include HashiCorp Vault with Shamir’s Secret Sharing, password managers with shared folders requiring multiple approvals, or custom solutions using split encryption keys.

Both authorised persons access the vault interface from their respective devices. Do not share screens or credentials during this process.
Navigate to the break-glass credential store. In HashiCorp Vault, this is typically at a path such as secret/break-glass/[system-name]. In team password managers like 1Password or Bitwarden, look for a shared vault named “Break-Glass” or “Emergency Access.”
Initiate the credential retrieval request. The vault will prompt for approval from the required number of authorised persons. For a two-person requirement, both must approve within the configured time window, commonly 15 to 30 minutes.
In HashiCorp Vault with Shamir’s Secret Sharing, Person A provides their unseal key first, then Person B provides theirs. After the threshold is met, retrieve the credential using the vault command line.
Terminal window
```
# Person A provides their unseal key
vault operator unseal [person-a-key-share]

# Person B provides their unseal key
vault operator unseal [person-b-key-share]

# After threshold is met, retrieve the credential
vault kv get secret/break-glass/domain-admin
```
Once both approvals are registered, the vault reveals the credential. Copy the credential directly to the system requiring access. Do not store it in intermediate locations such as text files, notes applications, or messaging systems.
The vault automatically logs the retrieval, including the identities of both approvers and the timestamp. Export or note the audit log entry reference for your invocation record.

+------------------------------------------------------------------+
|                  VAULT CREDENTIAL RETRIEVAL                      |
+------------------------------------------------------------------+
|                                                                  |
|  +------------------+                    +------------------+    |
|  | Person A         |                    | Person B         |    |
|  | (Authorised)     |                    | (Authorised)     |    |
|  | Device A         |                    | Device B         |    |
|  +--------+---------+                    +--------+---------+    |
|           |                                       |              |
|           v                                       v              |
|  +--------+---------+                    +--------+---------+    |
|  | Access vault     |                    | Access vault     |    |
|  | interface        |                    | interface        |    |
|  +--------+---------+                    +--------+---------+    |
|           |                                       |              |
|           v                                       v              |
|  +--------+---------+                    +--------+---------+    |
|  | Navigate to      |                    | Navigate to      |    |
|  | break-glass path |                    | break-glass path |    |
|  +--------+---------+                    +--------+---------+    |
|           |                                       |              |
|           v                                       v              |
|  +--------+---------+                    +--------+---------+    |
|  | Provide key      |                    | Provide key      |    |
|  | share / approval |                    | share / approval |    |
|  +--------+---------+                    +--------+---------+    |
|           |                                       |              |
|           +-------------------+-------------------+              |
|                               |                                  |
|                               v                                  |
|                  +------------+------------+                     |
|                  | Threshold met           |                     |
|                  | Credential revealed     |                     |
|                  +------------+------------+                     |
|                               |                                  |
|                               v                                  |
|                  +------------+------------+                     |
|                  | Audit log entry         |                     |
|                  | generated automatically |                     |
|                  +-------------------------+                     |
|                                                                  |
+------------------------------------------------------------------+

Figure 2: Vault-based retrieval with split knowledge requiring independent approval

Cloud Identity Provider Emergency Access

Cloud identity providers such as Microsoft Entra ID, Okta, and Google Workspace provide dedicated emergency access account mechanisms. These accounts bypass conditional access policies and federation, allowing access when the identity infrastructure itself has failed.

Access the emergency access account credentials from your secure storage. These credentials should be stored outside the cloud identity provider itself, typically in physical sealed envelopes or an on-premises credential vault.
Navigate directly to the cloud provider’s login page, such as https://login.microsoftonline.com for Microsoft Entra ID. Do not use bookmarks or links that may route through failed federation endpoints.
Enter the emergency access account username. This account should have a format that clearly identifies it as an emergency account, such as emergency-admin-01@contoso.onmicrosoft.com.
Enter the password from your retrieved credentials. Emergency access accounts should not use federated authentication or conditional access policies that depend on other systems.
If the account requires MFA, use the pre-registered method. Emergency access accounts should use authentication methods that function independently of your primary infrastructure: FIDO2 security keys stored with the break-glass credentials, TOTP codes from an authenticator app on a dedicated device, or SMS to a phone number controlled by the organisation rather than an individual.
Upon successful login, the cloud provider logs the authentication event. Note the sign-in timestamp and session ID from the provider’s audit logs.

Emergency account security

Emergency access accounts in cloud identity providers require special configuration: exclude them from all conditional access policies, do not assign them to groups that trigger additional security requirements, and ensure their MFA methods function independently of your primary identity infrastructure.

Phase 3: System Access

With credentials in hand, access the target system and perform only the actions necessary to address the emergency. The scope of break-glass access is strictly limited to resolving the incident that triggered invocation.

Connect to the target system using the retrieved credentials. Record the exact timestamp when you successfully authenticate, the account used, and the system accessed.
```
System access established: 2024-11-16 15:07 UTC
Account used: emergency-admin-01
System: Azure AD (login.microsoftonline.com)
```
Before making any changes, document the current state of the system or configuration you intend to modify. Take screenshots, export configurations, or run diagnostic commands that capture the pre-change baseline.
For a Windows server, capture the current date, local users, and local groups to a baseline file:
Terminal window
```
Get-Date | Out-File C:\break-glass-session\baseline.txt
Get-LocalUser | Out-File C:\break-glass-session\baseline.txt -Append
Get-LocalGroup | Out-File C:\break-glass-session\baseline.txt -Append
```
For Linux systems, capture equivalent information:
Terminal window
```
date > /root/break-glass-session/baseline.txt
cat /etc/passwd >> /root/break-glass-session/baseline.txt
cat /etc/group >> /root/break-glass-session/baseline.txt
```
Perform the minimum actions required to resolve the emergency. Narrate your actions to the second authorised person or witness, who should maintain their own notes. Do not explore the system, review unrelated configurations, or perform housekeeping tasks.
After each significant action, record what you did and the outcome. Include timestamps for every change, such as resetting a password, verifying authentication works, and confirming access to dependent services.
```
15:12 UTC - Reset password for user jsmith@contoso.com
15:14 UTC - Verified jsmith can authenticate to Azure AD
15:15 UTC - Confirmed jsmith can access SharePoint
```
When the emergency is resolved, log out of the system immediately. Do not leave sessions open. Record the logout timestamp and calculate the total session duration.
```
Session terminated: 2024-11-16 15:18 UTC
Total session duration: 11 minutes
```

Phase 4: Session Documentation

Complete documentation within 2 hours of concluding the break-glass session. Delays in documentation create gaps that complicate security reviews and may raise questions about the legitimacy of the access.

Compile the full session record. Include the invocation declaration from Phase 1, credential retrieval evidence such as envelope signatures or vault audit logs, system access timestamps, all actions performed with timestamps, baseline and post-change configurations, and logout confirmation.
Have both authorised persons review and sign the session record. If using digital signatures, each person signs the complete document. If using physical records, both sign each page.
Submit the session record to your incident management system or security team. Link it to the incident ticket created during invocation.
Store copies of the session record according to your retention policy. Break-glass records typically require 7 years retention for audit purposes.
Schedule the post-incident review within 5 business days of the break-glass event. The review process is described in the Post-Incident Review section below.

Credential Reset

Break-glass credentials must be rotated after every use. The credentials retrieved during the emergency are now known to the individuals who invoked the procedure and may have been observed or recorded. Resetting credentials restores the security of the break-glass mechanism.

Generate new credentials for the break-glass account. For passwords, use a cryptographically random generator producing at least 20 characters with mixed case, numbers, and symbols.
On Linux or macOS:
Terminal window
```
openssl rand -base64 24
```
In PowerShell:
Terminal window
```
[System.Web.Security.Membership]::GeneratePassword(24, 4)
```
Update the break-glass account with the new password. Test the new password by logging in and immediately logging out, confirming authentication succeeds.
Prepare new sealed credentials using your storage mechanism.
For physical envelopes, print the new credentials on paper, place them in a new tamper-evident envelope, sign across the seal with the date, record the new envelope serial number, and store the envelope in the secure location.
For credential vaults, update the secret at the break-glass path, verify dual-control retrieval still functions, and confirm audit logging captures the update.
Securely destroy the old credentials. Shred physical documents using a cross-cut shredder. For digital records, use secure deletion.
On Linux:
Terminal window
```
shred -u old-credentials.txt
```
On macOS:
Terminal window
```
rm -P old-credentials.txt
```
Document the credential reset in your asset inventory or credential management system. Record the reset date, who performed it, and the new envelope serial number or vault entry version.

+-------------------------------------------+
|    POST-INCIDENT RESET SEQUENCE           |
+-------------------------------------------+
|                                           |
|  +---------------------------+            |
|  | Break-glass event         |            |
|  | completed                 |            |
|  +------------+--------------+            |
|               |                           |
|               v                           |
|  +------------+--------------+            |
|  | Generate new credentials  |            |
|  | (20+ char random)         |            |
|  +------------+--------------+            |
|               |                           |
|               v                           |
|  +------------+--------------+            |
|  | Update break-glass        |            |
|  | account password          |            |
|  +------------+--------------+            |
|               |                           |
|               v                           |
|  +------------+--------------+            |
|  | Test new credentials      |            |
|  | (login/logout)            |            |
|  +------------+--------------+            |
|               |                           |
|               v                           |
|  +------------+--------------+            |
|  | Prepare sealed storage    |            |
|  | (envelope or vault)       |            |
|  +------------+--------------+            |
|               |                           |
|               v                           |
|  +------------+--------------+            |
|  | Destroy old credentials   |            |
|  | (shred/secure delete)     |            |
|  +------------+--------------+            |
|               |                           |
|               v                           |
|  +------------+--------------+            |
|  | Document reset in         |            |
|  | asset inventory           |            |
|  +---------------------------+            |
|                                           |
+-------------------------------------------+

Figure 3: Credential reset sequence restoring break-glass security

Post-Incident Review

Conduct a post-incident review within 5 business days of every break-glass invocation. The review serves two purposes: validating that the break-glass event was legitimate and identifying improvements to prevent future emergency access needs.

Assemble the review participants. Include the individuals who invoked break-glass, the emergency approver, a representative from the security team, and the system owner for the accessed system.
Review the session documentation against the organisation’s break-glass policy. Confirm that prerequisites were met before invocation, dual-control procedures were followed, only necessary actions were performed, documentation is complete and signed, and credentials have been reset.
Examine the audit logs from the accessed system. Compare the logs against the session documentation to verify they are consistent. Investigate any discrepancies.
Identify the root cause that necessitated break-glass access. Common categories include identity provider outage, sole administrator unavailable due to illness or departure or being unreachable, configuration error blocking normal access, security incident affecting authentication systems, and credential loss or compromise.

Determine corrective actions to reduce future break-glass likelihood.

Root cause	Corrective action
IdP outage	Implement redundant IdP or offline access capability
Single administrator	Ensure at least 2 administrators for every critical system
Configuration error	Add pre-change validation and rollback capability
Security incident	Address through separate incident response process
Credential loss	Improve credential management and recovery procedures

Document the review findings and corrective actions. Store with the original session record.
If the review identifies policy violations or unexplained actions, escalate to appropriate governance bodies for investigation.

Verification

After completing the break-glass procedure and credential reset, verify the break-glass mechanism is ready for future use.

Confirm the new credentials work by testing with dual-control retrieval. Both authorised persons retrieve the new credentials following the standard procedure, authenticate to the break-glass account, and immediately log out. This test validates that the reset credentials are correct and the storage mechanism functions properly.

Verify audit logging captured all expected events. Check the identity provider or system audit logs for the original break-glass authentication during the incident, the authentication test with new credentials, and any password change events for the break-glass account.

Confirm the documentation chain is complete. The incident management system should contain the initial invocation record, session documentation with both signatures, credential reset confirmation, and post-incident review findings.

Validate that the credential storage is properly secured. For physical envelopes, confirm the new envelope is in the secure storage location with intact seals. For vaults, confirm access controls remain correctly configured and audit logging is active.

Troubleshooting

Symptom	Cause	Resolution
Cannot reach any emergency approver within 15 minutes	All approvers unavailable simultaneously	Proceed under emergency exception; document all contact attempts; notify approver within 1 hour of completion
Second authorised person unavailable	Staffing constraint or timing	If truly urgent, proceed with solo access but require executive sign-off within 1 hour; document the exception
Physical envelope shows signs of tampering	Possible unauthorised access attempt	Do not open; photograph the condition; escalate to security immediately; use alternative break-glass credentials if available
Vault retrieval fails after both approvals	Vault service issue or credential corruption	Attempt retrieval from secondary vault if configured; fall back to physical sealed credentials; document the failure
Break-glass account login fails	Password incorrect, account disabled, or expired	Verify account status in admin portal using another admin account; contact cloud provider support if account is locked
MFA method for break-glass account unavailable	Hardware token lost, phone number disconnected	Use backup MFA method if configured; contact cloud provider for account recovery procedures
Cannot determine which break-glass account to use	Unclear system mapping	Review break-glass account inventory; match system name to account; consult system owner if unclear
Actions performed exceed what was documented	Incomplete logging or documentation error	Review system audit logs to reconstruct actual actions; investigate discrepancy; update documentation
Credential reset fails	Account policy prevents password change	Check password complexity requirements; verify admin rights on the account; consult identity team
Post-incident review identifies unauthorised actions	Possible abuse of break-glass access	Escalate to security and governance; preserve all logs; consider suspending individuals pending investigation

Configuration

Establish break-glass accounts and storage before you need them. The following configuration ensures break-glass mechanisms are available when emergencies occur.

Create dedicated break-glass accounts for each critical system. These accounts should be local or use authentication methods independent of your primary identity infrastructure. For cloud identity providers, create at least two emergency access accounts in case one becomes compromised or locked.

Configure break-glass accounts with the minimum privileges required for emergency recovery. This is typically global administrator or equivalent, as break-glass scenarios often require full access to restore service. Document the privilege level and justification for each account.

Exclude break-glass accounts from all conditional access policies, MFA enforcement through group membership, and automated account lifecycle management. These accounts must function when normal identity infrastructure has failed.

Configure alerting on break-glass account usage. Any authentication to a break-glass account should trigger immediate notification to security personnel:

# Example: Azure AD alert configuration
Alert name: Break-glass account sign-in
Condition: Sign-in by user in list [emergency-admin-01, emergency-admin-02]
Action: Send email to security@organisation.org
Action: Send SMS to security on-call

Establish the credential storage infrastructure. For physical sealed credentials, obtain tamper-evident envelopes from a security supplier, establish a secure storage location such as a rated safe, bank safety deposit box, or equivalent, and define who has access to the storage. For credential vaults, configure the break-glass path with dual-control requirements:

# HashiCorp Vault policy example
path "secret/break-glass/*" {
  capabilities = ["read"]
  required_parameters = ["reason"]
  min_wrapping_ttl = "30m"
}

Document the break-glass account inventory in a table that records each account, its associated system, storage location, authorised persons, and last test date:

Account	System	Storage location	Authorised persons	Last tested
emergency-admin-01@contoso.onmicrosoft.com	Microsoft Entra ID	Safe A, Envelope 001	IT Director, COO, Security Lead	2024-10-15
emergency-admin-02@contoso.onmicrosoft.com	Microsoft Entra ID	Safe A, Envelope 002	IT Director, COO, Security Lead	2024-10-15
local-admin-breakglass	Domain Controller	Vault path: secret/break-glass/dc	IT Director, Senior SysAdmin	2024-10-20

Test break-glass procedures quarterly. A test follows the full procedure except that the “emergency” is simulated and documented as a test. Testing validates that credentials work, storage is accessible, authorised persons know the procedure, and audit logging functions correctly.