ASD ISM 2148Revoke Sessions and Tokens on Reset, Compromise, Non-Compliance or Risky Sign-In
Kill 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.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Responsive
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system accessSection
Credential managementTopic
Protecting authentication artefacts
Official control statement
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.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk for the identity provider configuration and service desk procedure that governs password resets and credential re-enrolment.Look atLook 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.GoodEvery 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.
- AskAsk for the incident response playbook for compromised or suspected-compromised credentials and the records of the last few times it was used.Look atCheck 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.GoodRevocation is a documented mandatory step, incident tickets show it was performed promptly, and the identity provider logs corroborate the revocation.
- AskAsk how device compliance status is linked to session revocation and request an example of a device that recently fell out of compliance.Look atLook 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.GoodA 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.
- AskAsk for the configuration of high-risk sign-in detection and the automated response attached to it.Look atCheck 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.GoodSampled 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.
- AskAsk for the inventory of applications and services that issue their own sessions, tokens or API credentials outside the central identity provider.Look atFor each entry, check whether revocation is integrated with the central triggers or covered by a documented manual step in the relevant playbooks.GoodEvery token-issuing system is either wired to central revocation or has a tested manual step, and no significant application is missing from the list.
Cross-framework mappings
How ISM-2148 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(2)expand_less | ||
| Annex A 5.16 | ISM-2148 requires revocation of sessions and tokens in response to lifecycle and risk events (reset/re-enrolment, compromise, non-complia... | |
| Annex A 5.17 | ISM-2148 focuses on terminating active authentication states (sessions/tokens) under specific triggers such as resets, compromise suspici... | |
sync_altPartially overlaps(1)expand_less | ||
| Annex A 5.25 | ISM-2148 requires revoking sessions and tokens when compromise is suspected, devices are non-compliant, or risky sign-ins are detected | |
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.