They should validate that the account can still be used when the primary control path fails, that the approved custodians can reach it, and that access can be restored and revoked cleanly after the test. A break glass account that has never been exercised is not a reliable recovery control.
What makes an emergency access account worth testing?
An emergency access account is only useful if it still works when the normal identity stack does not. Testing should prove the account is genuinely independent of the control path it is supposed to replace, and that it is reserved for recovery, not everyday administration. That means validating both technical reachability and the governance steps that keep the account bounded, observable, and revocable.
What should the test prove end to end?
The first requirement is functional failover. The test should show that the account can be used when the primary login, directory, MFA, or privileged access path is unavailable. For a break-glass emergency access account, that means simulating the actual failure mode the account exists to cover, not just confirming that a password or token still exists.
The second requirement is controlled access. The approved custodians should be able to obtain and use the account through the intended recovery process, with any vaulting, approval, or escrow steps working as designed. A valid test also checks that the account is still usable after a system or directory incident, not only while the rest of the environment is healthy.
The third requirement is clean restoration. After the test, the organisation should be able to return the account to its protected state, rotate any credentials or secrets involved, and confirm that the account is again dormant until needed. Privileged Access Management guidance is useful here because emergency access is not a separate discipline, it is part of the same privilege lifecycle that must support vaulting, session control, and removal of standing access.
How do you test it without turning it into a security gap?
Test the account in a way that preserves accountability. Use a controlled window, document who authorised the test, and confirm that logging, alerting, and session records captured the activity. The account should not become a hidden back door just because it is meant for emergencies.
Also test the failure case, not only the success case. A good exercise checks what happens if a custodian is unavailable, if a vault is unreachable, if MFA is down, or if the directory is partially impaired. Those are the conditions under which emergency access either proves its value or fails when it is needed most.
Where organisations operate in regulated or high-assurance environments, this kind of exercise also aligns with resilience expectations in frameworks such as DORA and NIS2, because both treat operational continuity, access control, and recovery discipline as part of the control environment rather than optional extras.
Risk and Threat Considerations
Emergency access accounts become dangerous when they are assumed to be “for rare use” and then never exercised. The risk is not just failure during an outage, but silent drift: credentials expire, custodians change, logging breaks, or the account accumulates unnecessary privilege. A dormant account that cannot be recovered safely is a resilience weakness; a dormant account that is easy to abuse is an attack path.
Failure mechanism: The organisation mistakes existence for readiness, so the account is never tested under realistic failure conditions, never revalidated after changes, or never cleaned up properly after use.
Impact: Recovery fails when the primary control path is unavailable, or the account becomes a high-value credential that an attacker can use for persistent privileged access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Emergency access depends on secure credential storage, retrieval, rotation, and revocation. |
| AC-2 — Account Management | Emergency accounts must be provisioned, tested, reviewed, and deprovisioned under controlled ownership. | |
| AU-2 — Event Logging | Testing should confirm emergency access activity is recorded for later review and incident analysis. | |
| Recommendation — Exercise IA-5 by rotating and retiring emergency credentials after each test or use. Use AC-2 to govern custodianship, periodic review, and timely disablement of emergency accounts. Ensure AU-2 coverage captures activation, use, and restoration of emergency access accounts. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Emergency access testing is an access-control assurance activity that validates recovery without weakening governance. |
| A.8.2 — Privileged access rights | Break-glass accounts are privileged access paths that require explicit verification and cleanup after testing. | |
| Recommendation — Validate emergency access under A.5.15 with controlled approval and restricted use. Review privileged emergency access paths under A.8.2 and confirm they return to restricted state after use. | ||
| CIS Controls v8 | CIS-5 — Account Management | Emergency accounts are account-management assets that need testing, governance, and cleanup. |
| CIS-6 — Access Control Management | Testing should prove the account is only usable under approved access conditions. | |
| Recommendation — Apply CIS-5 to inventory, test, and retire emergency access accounts on a controlled cadence. Use CIS-6 to confirm emergency access remains tightly restricted outside the break-glass process. | ||
Practitioner Guidance
What to verify: Verify the account under the same constraints that would exist in a real incident, including who can retrieve it, how access is approved, whether logging survives the outage scenario, and whether the account can be returned to a known-good state immediately after use.
What good looks like: A successful test leaves behind evidence of controlled use, a verified restoration path, and a fresh credential or equivalent reset state. If the test cannot be completed without ad hoc manual work, the control is not yet reliable enough for emergency use.
Common mistake: Treating “we have a break-glass account” as the control. The control is the full recovery process, including custody, activation, monitoring, and revocation, and each part has to work when normal access has already failed.
Practitioner takeaway: Test emergency access the way you expect to rely on it, under failure conditions, with accountable custodians and a provable return to dormancy, otherwise it is only an unproven exception path.
Related resources from NHI Mgmt Group
- Why do non-human identities create more audit risk than human accounts?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern non-human identities alongside human accounts?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org