ASD ISM 1612 Restricted use of break glass accounts for emergencies
What it says
Break glass accounts are only used for specific authorised activities.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse special accounts only for approved emergency activities to maintain system security.
Break glass accounts are special user accounts used only in emergencies, like when there's a critical system issue, and normal login methods fail. If these accounts are misused, it could lead to security vulnerabilities, as they often bypass normal security checks. Restricting their use helps prevent unauthorised access to sensitive systems.
Free. Save your status, tasks and notes.
Why it matters
Misuse of break glass accounts can bypass normal controls, enabling unauthorised privileged access and increasing the likelihood of serious breaches.
How to implement
IT Managers should create a strict policy for using break glass accounts.
This involves drafting a document that outlines when and how these accounts can be used, ensuring all staff understand the emergency nature of these accounts.
System Owners should limit access to break glass accounts.
They can do this by only providing this access to key personnel, storing the account details securely, and ensuring it's not shared unnecessarily.
IT Teams should set up a monitoring system for break glass account usage.
This involves using logging tools to track who accesses the account and when, ensuring that every use is justified and documented.
HR and Security Teams should regularly train staff on the appropriate use of break glass accounts.
Conduct training sessions to explain the risks and procedures associated with these accounts, emphasising their emergency-only use.
Managers should conduct regular reviews of break glass account policies.
Hold quarterly meetings to revisit the policy's effectiveness, update access lists, and ensure compliance with industry standards like those from the Australian Cyber Security Centre (ACSC).
Keep it running
Log and review all break glass account use; restrict to approved emergency activities, require approval, and investigate any unexpected access immediately.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The break glass account usage log: Request the documented records of when these accounts were accessed.
Look at
The dates, times, user identities, and reasons for access.
Good evidence
Record will show infrequent, justified use with clear authorisation noted.
- Check 2 of 5What an auditor asks for
Ask for
The break glass account policy document: Request the written policy governing the use of these accounts.
Look at
Specifics like roles authorised to use the account and conditions for use.
Good evidence
Policy is clear, comprehensive, and aligns with organisational security practices.
- Check 3 of 5What an auditor asks for
Ask for
Evidence of secure storage of break glass account credentials: Request details on how credentials are kept secure, such as a password vault.
Look at
Controlled access to these credentials.
Good evidence
Practice includes encryption and limited access to the vault.
- Check 4 of 5What an auditor asks for
Ask for
Training records: Request evidence of training sessions provided to relevant staff about the use of break glass accounts.
Look at
Attendance lists and training materials. Good evidence will show recent, regular sessions with all key personnel trained.
- Check 5 of 5What an auditor asks for
Ask for
Policy review logs: Request records of the most recent policy review meeting.
Look at
Meeting minutes and any changes made to the policy. Good records demonstrate regular reviews, with updated procedures and sign-offs from senior management.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.15.
ISM-1612 requires that break glass accounts are only used for specific authorised activities. This is narrower than Annex A 5.15 because Annex A 5.15 requires an organisation to establish and implement access control rules and procedures for physical and logical access based on business and security requirements. ISM-1612 is one specific access rule within those broader procedures, defining an explicit purpose limitation for emergency privileged accounts.
This control partially meets A.8.2.
ISM-1612 requires that break glass accounts are only used for specific authorised activities. This is narrower than Annex A 8.2 because Annex A 8.2 broadly requires the allocation and use of all privileged access rights to be restricted and managed, across the organisation. ISM-1612 is a specific privileged-access usage rule focused on a high-risk privileged account type (break glass) and its permitted emergency use cases.
This control partially meets A.8.3.
ISM-1612 requires that break glass accounts are only used for specific authorised activities. This is narrower than Annex A 8.3 because Annex A 8.3 requires access to information and associated assets to be restricted in accordance with an access control policy, covering all users and assets. ISM-1612 applies that policy concept to a particular high-risk mechanism (break glass accounts) by limiting their use to authorised emergency actions only.
This control partially overlaps A.5.18.
ISM-1612 requires that break glass accounts are only used for specific authorised activities. This overlaps with Annex A 5.18 because Annex A 5.18 requires access rights to be provisioned, reviewed, modified, and removed according to access control rules, which commonly includes defining conditions for emergency account access and use. Annex A 5.18 is broader across the full access-rights lifecycle, while ISM-1612 is specifically a usage constraint (purpose/authorisation) for break glass accounts once they exist.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML2.5.
ISM-1612 requires that break glass accounts are only used for specific authorised activities (i.e., emergency-only use with explicit authorisation). This overlaps with E8-RA-ML2.5 because it also targets break glass accounts, requiring their credentials to be long, unique, unpredictable, and managed to reduce the likelihood of unauthorised use. ISM-1612 primarily constrains when/why the account may be used, while E8-RA-ML2.5 primarily constrains how the account is protected (credential strength and management).
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.