Skip to content
arrow_back
search
ISM-1615 policy ASD Information Security Manual (ISM)

Testing Break Glass Accounts Post Credential Change

Ensure emergency accounts work properly after changing their passwords.

record_voice_over

Plain language

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.

Framework

ASD Information Security Manual (ISM)

Control effect

Preventative

Classifications

NC, OS, P, S, TS

ISM last updated

July 2020

Control Stack last updated

19 Mar 2026

E8 maturity levels

N/A

Official control statement

Break glass accounts are tested after credentials are changed.
policy ASD Information Security Manual (ISM) ISM-1615
priority_high

Why it matters

If break glass accounts aren’t tested after credential changes, emergency access may fail, causing lockouts and delaying critical recovery actions.

settings

Operational notes

After any break glass credential change, perform a controlled login test, confirm access paths work, and record the test outcome and date.

build

Implementation tips

  • 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.
fact_check

Audit / evidence tips

  • AskThe password change schedule: Request the calendar or system setting that outlines when break glass account passwords are updated GoodIncludes regular updates, at least quarterly, documented with reminders
  • AskTo see the secure document with account details: Ensure it contains up-to-date credentials and that access is limited to authorised personnel GoodIncludes a clearly labelled document with digital audit logs of who accesses it
  • GoodShows that successful logins were documented and any failures were recorded and resolved
  • GoodIncludes comprehensive logs with issue resolutions if any tests failed
  • AskEvidence of the backup access plan: Request documentation of the alternative methods available if break glass accounts fail GoodIncludes a plan with clear instructions and authorised personnel listed
link

Cross-framework mappings

How ISM-1615 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ISO 27001

Control Notes Details
handshake Supports (3) expand_less
Annex A 5.17 ISM-1615 requires organisations to test break glass accounts after changing their credentials to verify the updated authentication inform...
Annex A 5.30 ISM-1615 requires break glass accounts to be tested after their credentials are changed to confirm emergency access will still function w...
Annex A 8.32 ISM-1615 requires a specific post-change verification: testing break glass accounts after their credentials are changed

E8

Control Notes Details
handshake Supports (1) expand_less
E8-RA-ML2.5 E8-RA-ML2.5 requires break glass, local administrator and service account credentials to be long, unique, unpredictable and managed

These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.

Mapping detail

Mapping

Direction

Controls