Use Break Glass Accounts Only in Emergencies
Break glass accounts should be used only if normal login methods fail.
Plain language
A 'break glass' account is like an emergency key that should be used only if the usual way of getting into a computer system is not working. It's important because if you can use this emergency access too easily or often, it could let people sneak in who shouldn't be there, putting your organisation's sensitive information at risk.
Framework
ASD Information Security Manual (ISM)
Control effect
Responsive
Classifications
NC, OS, P, S, TS
ISM last updated
July 2020
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for personnel securityOfficial control statement
Break glass accounts are only used when normal authentication processes cannot be used.
Why it matters
Excessive use of break glass accounts can lead to unauthorised access, compromising sensitive data and weakening overall security posture.
Operational notes
Audit and review break glass use regularly; ensure each use is logged, monitored, and justified as an emergency.
Implementation tips
- The IT team should designate specific break glass accounts for emergency situations only. They will need to create these accounts with minimal permissions and securely store the credentials where only authorised personnel can access them in times of crisis.
- The system owner should ensure that appropriate personnel know when and how to use break glass accounts. This can be done by including this procedure in regular training or communication meetings, explaining the specific scenarios when it's permissible to use these accounts.
- Managers should enforce strict logging and monitoring whenever a break glass account is used. This means ensuring that every use is tracked with details such as user, time, and reason for access, ideally with automated alerts to flag any unusual activity.
- Senior management should periodically review the necessity of each break glass account with the IT department. They can do this by assessing how often these accounts are used and confirming that their use aligns with documented emergency scenarios.
- The cybersecurity officer should implement a regular audit to ensure break glass accounts are kept secure and not used for non-emergency access. They can do this by checking logs and conducting surprise checks to verify adherence to security protocols.
Audit / evidence tips
- AskThe log of break glass account usage: Request a report detailing each time a break glass account was accessed GoodEach entry matches a documented emergency situation and is verified by management approval
- AskTo see the list of authorised personnel: Request the latest list of staff authorised to use break glass accounts
- AskTraining records on break glass accounts: Request evidence of training related to the use of these accounts GoodIncludes details where training scenarios reflect actual emergency situations and the list of attendees includes all relevant personnel
- AskTo review security policy documentation: Request the latest version of your security policy, highlighting sections on emergency access GoodIs having documented step-by-step guidelines that align with best practices
- AskAn audit summary report: Request the latest audit results for break glass accounts
Cross-framework mappings
How ISM-1611 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| Annex A 5.15 | ISM-1611 requires break glass accounts to be used only when normal authentication processes cannot be used (i.e., emergency-only use) | |
| Annex A 8.3 | ISM-1611 limits the use of break glass accounts to emergencies when standard authentication is unavailable | |
| handshake Supports (2) expand_less | ||
| Annex A 5.17 | ISM-1611 reserves break glass accounts for emergency use only, reducing exposure from powerful credentials | |
| Annex A 8.15 | ISM-1611 mandates break glass accounts for emergency use only, implying the organisation should detect and investigate any non-emergency use | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.