Resetting a compromised password does not log the attacker out: every session and token already issued keeps working until something ends it. D3-ST Session Termination is the MITRE D3FEND countermeasure for that gap. D3FEND defines it as "Forcefully end all active sessions associated with compromised accounts or devices." It sits in the Evict tactic as a child of Process Eviction, and D3FEND models it as a technique that deletes the Session artefact. This card covers what session termination has to reach, which ATT&CK techniques D3FEND relates it to, where it is done on common platforms, how to prove it worked, and where it falls short. It is written for incident responders and identity engineers who run containment, not for readers new to sessions. For the containment plan around it, see the Incident Scoping and Containment Strategy Guide.
Key takeaways
- A session is not one thing. An identity provider session, an application cookie, an OAuth refresh token, an access token and a remote desktop or SSH session each need their own termination step.
- Each revoke action has a documented scope. Microsoft Entra, Okta, Google Workspace and AWS each state in their own documentation what their revoke action does not reach, such as application cookies or access tokens already issued.
- Order matters. Block re-entry first (disable the account or reset the credential), then terminate sessions, or the attacker simply signs in again.
- Patching is not eviction. CitrixBleed showed that sessions stolen before a fix stay valid until someone kills them.
- Prove it with logs. A termination is done when no request from the old session or token succeeds after the cut-off time, not when the button was pressed.
D3-ST at a glance
| Field | D3-ST Session Termination |
|---|---|
| D3FEND ID | D3-ST |
| Tactic | Evict |
| Parent technique | Process Eviction (siblings: Host Shutdown, Process Suspension, Process Termination) |
| Digital artefact | Session (D3FEND: the technique "deletes" a Session) |
| D3FEND knowledge base note | "Defined in NIST 800-53 as AC-12", with NIST SP 800-53A Rev 5 as the reference |
| What it changes | Removes live authenticated state so that the next request must authenticate again |
| Typical implementation points | Identity provider, cloud control plane, SaaS admin consoles, VPN and remote access gateways, Remote Desktop Session Host, Linux hosts, privileged session tools |
| Main limitation | Each platform terminates only the session types it owns; self-contained tokens stay valid until expiry unless the resource checks revocation |
What session termination has to reach
D3FEND's definition is broad on purpose: "all active sessions". In practice an account or device compromise leaves several layers of authenticated state, and each layer is held by a different system.
| Session layer | Where it lives | Ends when |
|---|---|---|
| Identity provider session | Single sign-on cookie at the identity provider | The identity provider clears it (admin revoke, sign-out, account disable) |
| Refresh tokens | Issued by the identity provider, held by apps and clients | Revoked at the issuer, or expiry |
| Access tokens | Self-contained bearer tokens held by clients | Expiry, unless the resource supports a revocation signal |
| Application sessions | Each application's own cookie or server session | The application invalidates it server side |
| Cloud temporary credentials | Role sessions issued by the cloud provider's token service | Expiry, or a deny policy keyed on issue time |
| Interactive host sessions | Remote Desktop, SSH and console logons on servers | Logoff on the host, which ends the session's processes |
| Gateway sessions | VPN, VDI and application delivery controllers | Gateway kill command for the user or for all sessions |
The OWASP Session Management Cheat Sheet sets the baseline for the application layer: logout must invalidate the session "at least on server side", all identifiers belonging to the same logical session (including earlier rotations) must be revoked together, and applications should let users view and remotely terminate their active sessions. If an application cannot do server-side invalidation, D3-ST cannot be applied to it at all, and the only lever left is the session lifetime.
ATT&CK techniques D3FEND relates to D3-ST
Relationship type: inferred only. D3FEND lists these ATT&CK techniques for D3-ST because they act on the Session artefact that D3-ST deletes. D3FEND labels the relationship inferred and experimental (checked November 2026). Every ID was checked against ATT&CK v20. The last column is NHI Mgmt Group's assessment, not D3FEND content.
| ATT&CK ID | Technique | What termination changes (NHI Mgmt Group assessment) |
|---|---|---|
| T1133 | External Remote Services | Strong at the gateway: ends VPN or remote access sessions, but only lasts if the credential is also blocked |
| T1199 | Trusted Relationship | Partial: ends partner and supplier sessions you can see; delegated access granted in the partner's own tenant needs separate revocation |
| T1134.003 | Make and Impersonate Token | Partial: logoff destroys the logon session the token belongs to; a new token made from stolen credentials needs the credential reset too |
| T1021.001, T1021.004 | Remote Services: Remote Desktop Protocol, SSH | Strong for the live session: logoff ends its processes; keys or passwords still allow a new session |
| T1563.001, T1563.002 | SSH Hijacking, RDP Hijacking | Strong: ending the legitimate user's session removes the session that was being hijacked |
Session techniques that sit closest to D3-ST in practice are not in D3FEND's list for it: T1539 Steal Web Session Cookie and T1550.004 Web Session Cookie. Terminating the server-side session is the direct response to both. See the MITRE ATT&CK T1539 Steal Web Session Cookie, the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide and the MITRE ATT&CK T1563 Remote Service Session Hijacking.
Where it is implemented
Platforms are listed alphabetically. Each row states the action and the scope its own documentation gives (checked November 2026).
| Platform | Termination action | Scope stated in the vendor docs |
|---|---|---|
| AWS IAM roles | Revoke active sessions on the role, which attaches the inline policy AWSRevokeOlderSessions; or a custom deny policy with the aws:TokenIssueTime condition | Denies all actions to role sessions issued before the cut-off (the console adds about 30 seconds for propagation); applies to every user of the role; IAM Identity Center permission set sessions are revoked in Identity Center; service-linked role sessions cannot be revoked; clear the CLI credential cache |
| Google Workspace | Admin console: user, Security, Sign-in cookies, Reset; separate Sign Out User action for managed computers | Signs the user out of browsers and mobile devices but apps such as Gmail and Drive for desktop are signed out as a separate step; third-party app access is revoked separately; suspending a user resets sign-in cookies |
| Microsoft Entra ID | Revoke sessions in the admin centre, or Revoke-MgUserSignInSession, after disabling the account | Revokes refresh tokens and sign-in sessions; access tokens stay valid until expiry (default one hour) unless the app supports Continuous Access Evaluation; application session cookies must be revoked by the application |
| Okta | Clear user sessions: DELETE /api/v1/users/{userId}/sessions | Ends the user's Okta sessions; OAuth and OIDC tokens only with oauthTokens=true (default false); sessions created by web or native apps are ended in those apps; forgetDevices clears remembered factors |
| Windows Remote Desktop Session Host | logoff with the session ID or name, with /server for a remote host | Ends all processes in the session and removes it; needs Full Control to log off other users; cannot log off the console session |
On Linux hosts running systemd, loginctl can terminate a session or all sessions of a user, which ends their processes. Gateways and application delivery controllers have their own commands: after CitrixBleed, Citrix advised customers to kill all active and persistent sessions after upgrading. Privileged session tools can usually terminate a live brokered session; see the Privileged Session Management Guide. For standards-based sign-out across relying parties, see the OpenID Connect Logout and Session Management Guide and the Global Token Revocation Guide.
How to run it during an incident
- Scope the identity and devices. List the compromised accounts, their linked identities in each SaaS tenant and cloud account, and the devices they used. D3-CCSA Credential Compromise Scope Analysis covers this step.
- Block re-entry first. Disable the account or reset the password (Microsoft's guidance for synced accounts is to reset the on-premises password twice), and remove attacker-registered MFA methods, keys and app consents. Terminating sessions before this lets the attacker sign straight back in.
- Terminate at the identity provider. Revoke sign-in sessions and refresh tokens, including OAuth tokens where that is an option rather than a default.
- Terminate at each application and gateway. Work through the applications that keep their own sessions, then VPN, VDI and remote access gateways.
- Terminate cloud and host sessions. Apply issue-time deny policies to roles the identity assumed, and log off host sessions found on servers.
- Clear caches. Pair with D3-ANCI Authentication Cache Invalidation for cached credentials and Kerberos tickets on hosts.
- Record the cut-off time. Write down the UTC time of each termination; it is the line against which verification queries run.
Rollback is simple but disruptive: terminated users re-authenticate and may lose unsaved work. AWS warns that a role-wide revoke denies every current session of that role, so for a shared role, plan the impact on workloads before using it. For the wider identity response, see the Identity Incident Response Playbook.
How to verify it works
- Replay test in exercises: capture a test user's cookie and refresh token, run the termination procedure, then replay both. Each should be refused. Run this per application before an incident, so you know which apps honour revocation.
- Post-cut-off log search: search identity provider, application, cloud and gateway logs for successful requests from the affected identity after the recorded cut-off, grouped by session or token identifier. Any success means a layer was missed.
- Token lifetime check: for access tokens that cannot be revoked, wait out the documented lifetime and confirm no request using the old token succeeds after it.
- Host check: list sessions on servers the identity touched and confirm none remain.
| Metric | What it shows | Example target (illustrative, not a standard) |
|---|---|---|
| Time from containment decision to last session terminated | Speed of eviction across all layers | Under one hour for priority incidents |
| Successful requests from terminated sessions after cut-off | Missed session layers | Zero |
| Share of critical applications that support server-side or admin session revocation | Whether D3-ST can be applied at all | Rising; gaps listed with compensating lifetimes |
| Applications covered by a tested termination runbook | Readiness | All applications holding sensitive data |
| Re-entry sign-ins by the attacker after termination | Whether re-entry was blocked first | Zero |
For dwell-time signals that tell you a session needs terminating, see D3-SDA Session Duration Analysis.
Limits, bypasses and failure patterns
- Patching without terminating: in CitrixBleed 2023, cookies leaked before the fix stayed valid after upgrade, and Citrix told customers to kill all active and persistent sessions. Treat any gateway or token store compromise as a termination event.
- Terminating before blocking: if the password, MFA method or OAuth consent the attacker used still works, termination buys minutes.
- Trusting a single revoke button: each identity platform's documentation states the scope of its revoke action, and some layers are handled elsewhere, such as application cookies, access tokens or desktop apps. Those layers need their own step.
- Forgetting non-human identities: tokens issued to service principals, OAuth apps and CI/CD jobs are sessions too. User session revocation does not touch them; revoke the client secret, key or grant. See the Workload Identity Compromise Response Playbook.
- Persistence outside the session: scheduled tasks, new accounts, added keys and mailbox rules survive termination. D3-ST removes live access, not footholds.
- Applications without server-side sessions: stateless designs that trust a long-lived token cannot be terminated early. Short lifetimes are the only control; see Device-Bound Session Credentials (DBSC) Guide for reducing cookie replay.
Framework mapping
| Framework | Reference | Relationship to D3-ST |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-12 Session Termination | The control D3FEND names as the definition source; automatic termination after defined trigger events |
| NIST SP 800-53 Rev 5 | AC-2(3) Disable Accounts, SC-10 Network Disconnect | Companion controls: blocking re-entry and ending network sessions |
| NIST CSF 2.0 | RS.MI-01 | Incidents are contained |
| MITRE ATT&CK | M1026 Privileged Account Management | NHI Mgmt Group view, not a D3FEND link: privileged session controls usually carry the terminate capability |
Related countermeasures
- Siblings under Process Eviction: Host Shutdown, Process Suspension and Process Termination act on hosts and processes; D3-ST acts on authenticated state.
- Credential eviction: D3-ANCI Authentication Cache Invalidation and D3-AL Account Locking block the credential that would recreate a session.
- Deception: D3-DST Decoy Session Token detects replayed session material.
Practitioner checklist
- List every session layer for each critical application: identity provider, refresh and access tokens, app cookie, gateway, host.
- For each, record the termination action, who can run it, and what its documentation says it does not reach.
- Block re-entry before terminating: disable or reset, remove attacker MFA methods, keys and consents.
- Turn on OAuth token revocation options that are off by default when clearing identity provider sessions.
- Prefer applications and resources that honour revocation signals; set short access token lifetimes where they do not.
- Include service principals, OAuth apps and workload tokens in the termination runbook.
- Record the UTC cut-off and search all logs for successes after it.
- Test the runbook with a replay exercise at least once a year and after platform changes.
Standards and references
- MITRE D3FEND: Session Termination (D3-ST)
- NIST: SP 800-53 Rev 5, Security and Privacy Controls (AC-12)
- OWASP: Session Management Cheat Sheet
- AWS: Revoke IAM role temporary security credentials
- Google: Sign a user out of a managed Google Account
- Microsoft: Revoke user access in Microsoft Entra ID
- Okta: Revoke all user sessions API
- Microsoft: logoff command reference
Related NHI Mgmt Group resources: Incident Scoping and Containment Strategy Guide · Identity Incident Response Playbook · Global Token Revocation Guide · MITRE D3FEND Guide