ASD ISM 2148 Revoke sessions and tokens on reset, compromise, non-compliance or risky sign-in
What it says
Active sessions, refresh tokens and other authentication artefacts are revoked when credentials are reset or re-enrolled, when credentials are compromised or suspected of being compromised, when a device no longer meets compliance requirements, or when high-risk sign-in activity is detected.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKill existing logins, refresh tokens and similar artefacts whenever a credential is reset, compromised, a device falls out of compliance, or a risky sign-in is spotted.
When a person signs in, the system usually hands their browser or device an authentication artefact (a session cookie, an access token, a refresh token or similar) so they do not have to re-enter their credentials every few minutes. Those artefacts keep working on their own. Changing a password does not, by itself, cancel them. This control says that those artefacts must be actively revoked in four situations: when the credential is reset or re-enrolled, when the credential is compromised or suspected of being compromised, when the device holding the artefact no longer meets your compliance requirements, and when high-risk sign-in activity is detected. Why it matters: an attacker who has stolen a session or a refresh token can keep using it long after the victim has changed their password, because the token is what the system trusts, not the password. Likewise, a device that has lost its encryption, patch level or management status still holds a valid token that keeps granting access. If revocation does not happen, the credential reset or the compliance rule is largely cosmetic, and the attacker or the insecure device retains a live foothold.
Free. Save your status, tasks and notes.
Why it matters
If sessions, refresh tokens and other authentication artefacts are not revoked in these situations, a credential reset does not actually evict an attacker who already holds a token, a compromised account stays usable, a non-compliant device keeps its access, and a detected high-risk sign-in is allowed to continue. The result is prolonged unauthorised access to systems and data despite the organisation believing it has responded.
How to implement
Identity administrators configure the identity provider so that every password reset, credential re-enrolment (including MFA re-registration) and account re-provisioning automatically revokes all active sessions and refresh tokens for that account, and confirm that service desk reset tools call the same revocation.
The security operations team writes the suspected-credential-compromise playbook so that the first action is to revoke sessions, refresh tokens and any other authentication artefacts for the affected account (using the identity provider's revoke-all-sessions function or equivalent), followed by the credential reset, and they rehearse it against a test account.
Endpoint and identity administrators connect the device management platform's compliance signal to the identity provider's conditional access or session policy so that a device that falls out of compliance has its existing sessions and refresh tokens revoked, not just new sign-ins blocked, and set token lifetimes short enough that the revocation takes effect quickly.
The security operations team enables risk-based sign-in detection in the identity provider (or SIEM) and configures the high-risk classification to trigger an automated revocation of the account's sessions and refresh tokens, with an alert to the analyst queue for follow-up.
Application owners inventory every system that issues its own sessions or tokens outside the central identity provider (web apps, mobile apps, API keys, service accounts) and either integrate them with central revocation via back-channel logout or token revocation endpoints, or document a manual revocation step in the playbooks for each trigger.
Keep it running
Day to day, this control lives in the identity provider and in the systems that issue their own tokens. Password resets, MFA re-enrolments and account re-provisioning should all include a "sign out everywhere" step, whether triggered by the user, the service desk or an automated process. The incident response process needs a defined action for suspected credential compromise that revokes sessions and refresh tokens, not just a password change. Device compliance state from the device management platform should feed the identity provider so that a device dropping out of compliance loses its existing sessions, not only its ability to start new ones. Risk-based sign-in detection should be wired to a revocation action rather than only an alert. Expect some friction: users will be signed out of all devices and applications after these events, so the service desk should know why it happens and how to explain it. Also keep an eye on applications that hold long-lived tokens outside the identity provider (mobile apps, API clients, legacy services) because these are the ones most likely to be missed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the identity provider configuration and service desk procedure that governs password resets and credential re-enrolment.
Look at
Look for a setting or scripted step that revokes all sessions and refresh tokens at the point of reset or re-enrolment, and check that the service desk tooling uses that same path.
Good evidence
Every reset and re-enrolment channel, self-service and assisted, ends with sessions and refresh tokens revoked for the account, and a recent reset shows the revocation event in the logs.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the incident response playbook for compromised or suspected-compromised credentials and the records of the last few times it was used.
Look at
Check that the playbook explicitly revokes sessions, refresh tokens and other authentication artefacts, and that the incident records show that step was carried out and when.
Good evidence
Revocation is a documented mandatory step, incident tickets show it was performed promptly, and the identity provider logs corroborate the revocation.
- Check 3 of 5What an auditor asks for
Ask for
Ask how device compliance status is linked to session revocation and request an example of a device that recently fell out of compliance.
Look at
Look at the conditional access or session policy tied to the device management compliance signal and trace what happened to that device's existing sessions and tokens.
Good evidence
A non-compliant device loses its existing sessions and refresh tokens within the configured token lifetime, and the logs show the revocation, not just a block on new sign-ins.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the configuration of high-risk sign-in detection and the automated response attached to it.
Look at
Check that a high-risk classification triggers an actual revocation action on the account's sessions and refresh tokens rather than only an email or alert, and sample recent high-risk events to see the outcome.
Good evidence
Sampled high-risk sign-ins show sessions and tokens revoked automatically and an analyst follow-up recorded, with few or no cases where the session was left alive.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the inventory of applications and services that issue their own sessions, tokens or API credentials outside the central identity provider.
Look at
For each entry, check whether revocation is integrated with the central triggers or covered by a documented manual step in the relevant playbooks.
Good evidence
Every token-issuing system is either wired to central revocation or has a tested manual step, and no significant application is missing from the list.
Mappings
Closest match in ISO/IEC 27001: A.5.16, Identity life cycle management, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.16.
ISM-2148 requires revocation of sessions and tokens in response to lifecycle and risk events (reset/re-enrolment, compromise, non-compliance, risky sign-ins). Annex A 5.16 requires management of the full identity lifecycle, including changes, suspension and revocation actions when risk or status changes occur. ISM-2148 is a specific identity lifecycle response focused on invalidating current authenticated sessions/tokens, while Annex A 5.16 also covers onboarding, changes, deprovisioning and other identity governance activities.
This control partially meets A.5.17.
ISM-2148 focuses on terminating active authentication states (sessions/tokens) under specific triggers such as resets, compromise suspicion, device non-compliance, or high-risk sign-ins. Annex A 5.17 governs the allocation and management of authentication information (e.g. passwords, keys, token secrets) via a controlled process, which is commonly where reset and compromise-handling procedures are defined. ISM-2148 is a concrete operational control that can be implemented as part of the broader authentication-information management process in Annex A 5.17.
This control partially overlaps A.5.25.
ISM-2148 requires revoking sessions and tokens when compromise is suspected, devices are non-compliant, or risky sign-ins are detected. Annex A 5.25 requires assessing information security events and deciding whether they should be categorised as incidents, which commonly includes analysing risky sign-in alerts or suspected credential compromise. They overlap where risky sign-in/compromise signals trigger both event assessment (Annex A 5.25) and containment via session/token revocation (ISM-2148), but Annex A 5.25 is focused on classification and decision-making rather than enforcing authentication state revocation.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.