ASD ISM 2145Revoke User Account Credentials When No Longer Required
Passwords, 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.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Official control statement
Credentials for user accounts are revoked when they are no longer required.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk for the documented process that governs revoking user account credentials, including the triggering events and the expected timeframes.Look atCheck 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.GoodA clear process that covers all credential types attached to an account, assigns responsibility for triggering and actioning revocation, and sets a defined timeframe.
- AskAsk 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 atCompare 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.GoodEvery departure and role change has a matching revocation completed within the documented timeframe, and any exceptions are explained and closed.
- AskAsk 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 atCheck whether disabling or removing the account also invalidates these secondary credentials, or whether they can continue to authenticate afterwards.GoodRevocation invalidates all credentials and sessions tied to the account, either natively or through a documented and tested supplementary step.
- AskAsk for records of temporary, emergency, contractor and project-based access granted in a recent period.Look atCheck that each grant carried an expiry date and that the credentials were revoked automatically or manually when that date passed.GoodAll time-bound access has a recorded expiry and the credentials were revoked on or before it, with no open-ended temporary access remaining.
- AskAsk for the most recent reconciliation of active accounts and credentials against the current staff and contractor register and last-use information.Look atLook at what the reconciliation found, how many credentials it identified as no longer required, and whether those were subsequently revoked.GoodThe reconciliation runs on a defined schedule, its findings are tracked to closure, and few or no orphaned credentials remain after each cycle.
Cross-framework mappings
How ISM-2145 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 5.16 | ISM-2145 requires organisations to revoke user account credentials when they are no longer required | |
sync_altPartially overlaps(1)expand_less | ||
| Annex A 5.17 | ISM-2145 requires organisations to revoke user account credentials as soon as they are no longer required | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.