The Break-Glass Dilemma
Break-glass accounts are your organization's emergency parachute — essential when normal access fails, but dangerous if misused. The challenge is enabling rapid emergency access while maintaining security controls, audit trails, and automated monitoring that catch unauthorized use instantly.
What Is Break-Glass Access?
Break-glass (or "emergency access") accounts are highly privileged credentials used only when normal administrative access paths fail — federation outages, MFA service disruptions, conditional access lockouts, or critical security incidents requiring immediate action.
Break-Glass Account Characteristics
| Characteristic | Requirement | Why It Matters |
|---|---|---|
| Cloud-Only | No on-premises sync | Works when AD Connect fails |
| Permanent Role | Global Administrator | No PIM activation needed |
| Excluded from CA | Bypass all policies | Works during policy lockouts |
| No MFA | Or hardware token only | Works during MFA outages |
| Strong Password | 40+ characters, split custody | Compensating control for no MFA |
Why Break-Glass Monitoring Must Be Automated
Break-glass accounts are high-value targets for attackers and insider threats. Because they bypass normal security controls, any use — legitimate or malicious — requires immediate attention and investigation.
Scenario
Attacker compromises break-glass credentials
Risk
Full tenant takeover with no MFA barrier
Scenario
Insider abuses emergency access
Risk
Undetected privilege escalation
Scenario
Break-glass used but not reported
Risk
Compliance violation, audit failure
Scenario
Credentials exposed in documentation
Risk
Permanent backdoor for attackers
Detection Signals for Break-Glass Use
Automated monitoring should trigger on any of these signals, since legitimate break-glass use is rare (typically 0-2 times per year for most organizations).
Any Sign-In to Break-Glass Account
CriticalAny authentication attempt — successful or failed — requires immediate investigation
Source: Sign-in logs
Break-Glass Account Activity in Audit Logs
CriticalAny administrative action performed by a break-glass account
Source: Audit logs
Break-Glass Password or Credential Change
CriticalPassword reset, credential update, or authentication method change
Source: Audit logs
Break-Glass Account Properties Modified
HighRole assignment changes, group membership, or profile updates
Source: Audit logs
Break-Glass Account Added to Conditional Access Exclusion
HighAttacker adding persistence by ensuring account bypasses policies
Source: Audit logs
New Break-Glass Account Created
HighCreation of accounts matching break-glass naming patterns
Source: Audit logs
Automated Response Workflow
The key insight: legitimate break-glass use should always be pre-announced through your incident management process. Unannounced use is suspicious by default.
Response Decision Tree
Step 1: Immediate Alert (0-30 seconds)
- • Alert security team via high-priority channel (PagerDuty, Slack, Teams)
- • Alert IT leadership and security management
- • Create incident ticket automatically
- • Capture full sign-in context (IP, device, location, user agent)
Step 2: Automated Context Enrichment (30-60 seconds)
- • Check incident management system for active break-glass request
- • Query on-call schedule — is authorized person on duty?
- • Correlate IP/location with known admin locations
- • Check for concurrent security incidents that would justify use
Step 3: Conditional Response (1-5 minutes)
- • If pre-announced: Monitor session, log all actions, require check-in every 15 minutes
- • If NOT pre-announced: Escalate to security leadership, prepare containment
- • If suspicious indicators: Initiate containment (see below)
Step 4: Containment Actions (If Unauthorized)
- • Revoke all active sessions for break-glass account
- • Reset break-glass password immediately
- • Block source IP at firewall/WAF
- • Audit all actions taken during session
- • Initiate incident response procedures
Safe Controls for Break-Glass Accounts
Implementing these controls ensures break-glass accounts remain available for emergencies while minimizing abuse risk.
Split Custody Passwords
Divide password into 2-3 parts held by different people. Requires coordination to use.
Implementation
First 20 chars with Security Lead, last 20 chars with IT Director, stored in separate safes
Hardware Token MFA (Optional)
If MFA is used, use hardware tokens stored physically separate from passwords.
Implementation
FIDO2 key in secure safe, different location than password, requires physical presence
Naming Convention Detection
Use consistent naming so automated monitoring can identify break-glass accounts.
Implementation
Pattern: BreakGlass-[Number]@domain.com or EmergencyAdmin-[Region]@domain.com
Quarterly Access Verification
Test break-glass access works, verify credentials are correct, rotate passwords.
Implementation
Scheduled test with full documentation, password rotation, audit log review
Session Time Limits
Automated session termination after maximum duration regardless of activity.
Implementation
4-hour maximum session, forced re-authentication, requires new authorization
Action Logging with Immutable Storage
All break-glass session activity logged to WORM storage or external SIEM.
Implementation
Real-time log forwarding to separate tenant or third-party SIEM
Automation Decision Matrix
| Scenario | Automate | Human Review |
|---|---|---|
| Any break-glass sign-in | Alert + enrichment | Verify legitimacy |
| Unannounced use + suspicious IP | Session revocation | Incident response |
| Password/credential change | Alert + audit capture | Required approval |
| Pre-announced legitimate use | Monitor + log | Periodic check-in |
| Session exceeds time limit | Force termination | Re-authorization |
| Quarterly access test | Reminder + tracking | Execute test |
Compliance and Audit Requirements
Break-glass procedures must satisfy compliance frameworks while remaining operationally effective.
SOC 2
Documented emergency access procedures, audit trails for all privileged access
ISO 27001
Access control policy covering emergency access, regular testing of procedures
NIST 800-53
AC-2(2) Automated management, AU-2 Event logging, IR-4 Incident handling
PCI DSS
Requirement 7.2.3 - Emergency access must be documented and restricted
Common Break-Glass Mistakes
No monitoring on break-glass accounts
Consequence: Unauthorized use goes undetected for days or weeks
Fix: Alert on ANY sign-in or audit log activity
Break-glass credentials in shared documentation
Consequence: Credentials exposed to anyone with doc access
Fix: Split custody with physical storage, never digital
Single break-glass account for entire organization
Consequence: Single point of failure, no geographic redundancy
Fix: Minimum 2 accounts, different custody chains
Never testing break-glass access
Consequence: Discover credentials are wrong during actual emergency
Fix: Quarterly tests with full documentation
No session time limits
Consequence: Compromised session remains active indefinitely
Fix: Maximum 4-hour sessions, automatic termination
Key Takeaways
- •Alert on everything — any break-glass activity is significant enough to investigate
- •Pre-announcement is key — legitimate use should always be coordinated through incident management
- •Split custody prevents abuse — require multiple people to assemble credentials
- •Test quarterly — don't discover problems during an actual emergency
- •Immutable logging — break-glass session logs must be tamper-proof
Automate Break-Glass Monitoring with BitLyft AIR
BitLyft AIR provides instant alerting on break-glass account activity with automated context enrichment, session monitoring, and containment actions — ensuring emergency access is always visible and controlled.
See Break-Glass Monitoring in Action