ASD ISM 2145 Revoke user account credentials when no longer required
What it says
Credentials for user accounts are revoked when they are no longer required.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishPasswords, tokens, keys and other credentials tied to user accounts are actively withdrawn as soon as the need for them ends, so nothing usable is left behind.
Every user account carries one or more credentials: a password, a passphrase, a multi-factor token, a smartcard certificate, an API key or a session token. This control says that when the reason for a credential to exist goes away, the credential itself must be revoked, not just left to sit unused. The need for a credential ends in many ordinary situations: a person leaves the organisation, moves to a different role, finishes a project or contract, comes to the end of a period of temporary or emergency access, or replaces one credential with another (for example, a new smartcard or a rotated key). In each case the old credential should stop working. It matters because a credential that still works is an open door, regardless of whether anyone is supposed to be using it. Departed staff, former contractors, and anyone who obtained the credential through phishing, a leaked password list or a stolen token can keep authenticating for as long as the credential stays valid. Simply forgetting about an account is not the same as closing it. Revocation removes the ability to authenticate, which is the only reliable way to make sure the credential cannot be reused.
Free. Save your status, tasks and notes.
Why it matters
If credentials are not revoked when they are no longer required, former employees, ended contractors and anyone holding a leaked or stolen credential can continue to log in unnoticed. Because the account still looks legitimate, this access blends into normal activity and can be used to read, alter or exfiltrate information, or to pivot further into the environment. Orphaned credentials also accumulate over time, making the true set of people who can access a system unknown and undermining every other access control that depends on knowing who holds valid credentials.
How to implement
Identity and access administrators define the events that end the need for a credential (departure, role change, contract or project completion, expiry of temporary or emergency access, credential replacement) and document, for each event, which credentials are revoked and within what timeframe.
Human resources, procurement and line managers feed departure, role-change and contract-end notifications directly into the account management workflow or ticketing system so that revocation is triggered by the event rather than by someone remembering to raise it.
System administrators configure the identity provider and directory so that revoking an account invalidates every credential attached to it, including multi-factor authenticators, certificates, API and SSH keys, application passwords and active sessions or refresh tokens, and script this where the platform does not do it natively.
Access approvers set an expiry date on all temporary, emergency, contractor and project-based access at the time it is granted, and configure the identity platform to automatically revoke the credentials when that date is reached.
The identity team runs a scheduled reconciliation that compares active accounts and credentials against the current staff and contractor register and against last-use data, and raises revocation tickets for any credential whose owner or purpose can no longer be confirmed.
Keep it running
In practice this control lives inside the joiner, mover and leaver process and the day-to-day administration of identity systems. Human resources, contract managers and line managers need a dependable way to tell the team that manages accounts that a person has left, changed role or finished an engagement, and that notification needs to trigger revocation rather than sit in a queue.
Revocation should cover all of the credentials attached to the account, not only the primary password. That includes multi-factor authenticators, certificates, API keys, SSH keys, application-specific passwords and any long-lived sessions or refresh tokens that would otherwise keep working after the password is changed. Temporary, emergency and project-based access should carry an expiry date so revocation happens automatically instead of relying on someone to remember.
Periodic checks of accounts that have not been used, accounts whose owners no longer appear in the staff or contractor register, and credentials that were replaced but never withdrawn help catch anything the event-driven process missed. Each revocation should be recorded so the organisation can show when a credential stopped working and who actioned it.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the documented process that governs revoking user account credentials, including the triggering events and the expected timeframes.
Look at
Check that it names the events that end the need for a credential (leavers, role changes, contract and project completion, temporary access expiry, credential replacement) and states which credential types are revoked in each case.
Good evidence
A clear process that covers all credential types attached to an account, assigns responsibility for triggering and actioning revocation, and sets a defined timeframe.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a list of people who left or changed roles in a recent period, together with the corresponding revocation records from the identity system.
Look at
Compare each departure or role change date with the date the credentials were actually revoked, and look for any that were revoked late or not at all.
Good evidence
Every departure and role change has a matching revocation completed within the documented timeframe, and any exceptions are explained and closed.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see the configuration or evidence of how revoking an account affects the other credentials linked to it, such as multi-factor authenticators, certificates, keys and active sessions.
Look at
Check whether disabling or removing the account also invalidates these secondary credentials, or whether they can continue to authenticate afterwards.
Good evidence
Revocation invalidates all credentials and sessions tied to the account, either natively or through a documented and tested supplementary step.
- Check 4 of 5What an auditor asks for
Ask for
Ask for records of temporary, emergency, contractor and project-based access granted in a recent period.
Look at
Check that each grant carried an expiry date and that the credentials were revoked automatically or manually when that date passed.
Good evidence
All time-bound access has a recorded expiry and the credentials were revoked on or before it, with no open-ended temporary access remaining.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the most recent reconciliation of active accounts and credentials against the current staff and contractor register and last-use information.
Look at
Look at what the reconciliation found, how many credentials it identified as no longer required, and whether those were subsequently revoked.
Good evidence
The reconciliation runs on a defined schedule, its findings are tracked to closure, and few or no orphaned credentials remain after each cycle.
Mappings
Closest match in ISO/IEC 27001: A.5.16, Identity life cycle management, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.16.
ISM-2145 requires organisations to revoke user account credentials when they are no longer required. ISO/IEC 27001:2022 Annex A 5.16 requires management of the full identity lifecycle, which includes joiner/mover/leaver processes and associated credential deprovisioning. ISM-2145 is a specific credential-revocation requirement within the broader identity lifecycle scope of Annex A 5.16.
This control partially overlaps A.5.17.
ISM-2145 requires organisations to revoke user account credentials as soon as they are no longer required. ISO/IEC 27001:2022 Annex A 5.17 relates by requiring controlled allocation and management of authentication information, which typically includes processes for withdrawal/invalidating credentials when users change roles or leave. Annex A 5.17 is broader across the authentication information lifecycle (issuance, handling, protection), whereas ISM-2145 is specifically focused on timely revocation at end-of-need.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.