Break glass for privileged accounts: are your controls ready?

TL;DR: Break-glass access is a pre-staged emergency path for privileged accounts when IAM, PAM, MFA, or federation failures block legitimate access, and StrongDM says it should be monitored, time-limited, and rotated after use. The governance issue is not whether emergency access exists, but whether it is governed tightly enough to avoid becoming standing privilege by another name.

NHIMG editorial — based on content published by StrongDM: Break Glass Explained, Why You Need It for Privileged Accounts

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

Questions worth separating out

Q: What breaks when break-glass access is not tightly governed?

A: Break-glass access turns into permanent privileged backdoor risk when it is not tightly governed.

Q: Why do privileged emergency accounts need special lifecycle controls?

A: Privileged emergency accounts need special lifecycle controls because their purpose is temporary, but their impact is extreme.

Q: How do security teams know whether break-glass access is actually working?

A: Security teams know break-glass access is working when it is used rarely, leaves a complete audit trail, and is fully revoked after the event.

Practitioner guidance

• Define break-glass invocation criteria Limit emergency access to explicit outage, lockout, or incident conditions and document who can authorise use before any account is issued.
• Separate emergency identities from daily admin roles Keep break-glass accounts isolated from routine privileged workflows, with distinct storage, distinct ownership, and distinct approval paths.
• Rotate and disable after every use Revoke the used secret immediately after the incident closes, generate a new credential, and confirm the replacement is the only valid path forward.

What's in the full article

StrongDM's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step break-glass account setup for cloud and on-premises environments.
• The exact emergency workflow StrongDM describes for granting and documenting access.
• Practical notes on dual-control vaulting, including Shamir Secret Sharing and hardware storage.
• Post-incident cleanup steps for disabling or deleting the used account and recreating credentials.

👉 Read StrongDM's explanation of break-glass access for privileged accounts →

Break glass for privileged accounts: are your controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →