ASD ISM 1615 Testing break glass accounts post credential change
What it says
Break glass accounts are tested after credentials are changed.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure emergency accounts work properly after changing their passwords.
Break glass accounts are special accounts that give emergency access to critical systems. We need to make sure these accounts work correctly after their passwords are changed, because if they don't, you might be locked out when you most need access during an emergency.
Free. Save your status, tasks and notes.
Why it matters
If break glass accounts aren't tested after credential changes, emergency access may fail, causing lockouts and delaying critical recovery actions.
How to implement
The IT team should schedule regular password changes for break glass accounts.
They can do this by setting calendar reminders or using software tools that enforce password expiry, and then update passwords accordingly.
The system owner should ensure all relevant staff know about the break glass accounts and their updated credentials.
This can be done by maintaining a secure document with account details, which is shared with authorised personnel only.
IT support staff should test the functionality of break glass accounts immediately after a credential change.
They can do this by attempting to log in with the new credentials to verify access works as expected.
The security manager should document each test of the break glass accounts.
They can create a log noting the date and result of each test, ensuring any issues are promptly addressed.
The system owner should have a backup plan in place for accessing systems if a break glass account fails.
This might include having a trusted third-party service or another emergency access method ready to prevent any operational downtime.
Keep it running
After any break glass credential change, perform a controlled login test, confirm access paths work, and record the test outcome and date.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The password change schedule: Request the calendar or system setting that outlines when break glass account passwords are updated.
Look at
The frequency of updates and any reminders set.
Good evidence
Includes regular updates, at least quarterly, documented with reminders.
- Check 2 of 5What an auditor asks for
Ask for
To see the secure document with account details: Ensure it contains up-to-date credentials and that access is limited to authorised personnel.
Good evidence
Includes a clearly labelled document with digital audit logs of who accesses it.
- Check 3 of 5What an auditor asks for
Look at
Details about the outcomes of these tests after each password change.
Good evidence
Shows that successful logins were documented and any failures were recorded and resolved.
- Check 4 of 5What an auditor asks for
Look at
Entries that detail the testing date, who performed the test, and the result.
Good evidence
Includes comprehensive logs with issue resolutions if any tests failed.
- Check 5 of 5What an auditor asks for
Ask for
Evidence of the backup access plan: Request documentation of the alternative methods available if break glass accounts fail.
Good evidence
Includes a plan with clear instructions and authorised personnel listed.
Mappings
Closest match in ISO/IEC 27001: A.5.17, Management of authentication information, which this control supports.
ISO/IEC 27001: 2 mappings
This control supports A.5.17.
ISM-1615 requires organisations to test break glass accounts after changing their credentials to verify the updated authentication information works operationally. This supports Annex A 5.17 because it strengthens the management process for authentication information by adding an assurance check for a high-impact credential lifecycle event (credential change) on emergency accounts. Annex A 5.17 is broader, covering allocation, handling and management rules for authentication information generally, while ISM-1615 is specifically about post-change functional testing rather than how credentials are issued or protected.
This control supports A.5.30.
ISM-1615 requires break glass accounts to be tested after their credentials are changed to confirm emergency access will still function when needed. This supports Annex A 5.30 by providing a concrete, repeatable test activity that evidences ICT continuity readiness for a critical recovery mechanism (emergency administrative access). Annex A 5.30 is broader and lifecycle-focused (plan, implement, maintain and test ICT continuity), while ISM-1615 focuses on post-change validation for one continuity-enabling control (break glass access).
ASD Essential Eight: 1 mapping
This control supports E8-RA-ML2.5.
E8-RA-ML2.5 requires break glass, local administrator and service account credentials to be long, unique, unpredictable and managed. ISM-1615 strengthens that management requirement by ensuring break glass accounts are tested after credential changes, reducing the risk of unusable emergency access. ISM-1615 does not set credential strength/uniqueness requirements, but it supports operational assurance around the primary control's management intent.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.