Session and token revocation is the process of invalidating active access so a user, device, or application can no longer authenticate with previously issued credentials. It is a core containment control because it allows organisations to terminate access after offboarding, suspicious activity, or policy changes, provided the revocation is recorded and enforced promptly.
Expanded Definition
Session and token revocation is the controlled termination of active access so a previously issued session, bearer token, refresh token, or similar credential can no longer be used. In NHI operations, it is the mechanism that turns off access after offboarding, compromise, scope change, or automation decommissioning.
Definitions vary across vendors on whether revocation means immediate invalidation at the issuer, expiry at the resource server, or both. In practice, the distinction matters because an access token may remain usable until validation checks fail, while a refresh token may continue to mint new access if it is not revoked at the source. NIST SP 800-53 Rev 5 Security and Privacy Controls treats session termination and credential management as related safeguards, but implementation details depend on token format, protocol, and trust boundary. For NHI programs, revocation should cover both human sessions and machine identities, including OAuth grants, API tokens, workload certificates, and agent tool access. The most common misapplication is assuming password reset or account disablement automatically revokes all active tokens, which occurs when downstream systems do not consult the issuer or maintain token status checks.
Examples and Use Cases
Implementing revocation rigorously often introduces coordination overhead between identity providers, application services, and secrets systems, requiring organisations to weigh rapid containment against added latency and operational complexity.
- After employee offboarding, a platform administrator revokes refresh tokens and active sessions so the former user cannot continue accessing SaaS and internal tooling, a failure pattern highlighted in the 2025 State of NHIs and Secrets in Cybersecurity.
- When an OAuth app is abused, teams revoke the grant at the identity provider and invalidate associated tokens across connected services, similar to the access-chain risk described in the Salesloft OAuth token breach.
- In CI/CD, leaked deployment credentials are revoked immediately and replaced with newly issued short-lived tokens, aligning with the containment model described by the NIST SP 800-53 Rev 5 Security and Privacy Controls.
- For service-to-service access, a workload identity certificate is revoked after an image is found compromised, preventing the same identity from being reused across clusters.
- During secret-sprawl remediation, teams identify tokens stored in tickets, chat, or code and revoke them at the source, consistent with the lifecycle failures discussed in the Guide to the Secret Sprawl Challenge.
Why It Matters in NHI Security
Revocation is one of the few controls that can stop ongoing abuse after a credential is exposed, which is why it sits at the centre of NHI incident response. Without it, leaked tokens remain functionally valid even when the owning account is disabled, the workstation is wiped, or the application is removed.
This matters especially for non-human identities because their credentials often live longer than human sessions and are reused across pipelines, agents, and integrations. NHIMG research shows that 91% of former employee tokens remain active after offboarding, a stark signal that lifecycle controls frequently fail where they matter most. Token revocation must therefore be paired with inventory, issuer-side invalidation, and downstream enforcement, not treated as a cosmetic cleanup step. It also supports blast-radius reduction when a single NHI is overused across multiple applications, a pattern that can multiply the impact of one exposed credential.
Organisations typically encounter the need for revocation only after a token leak, anomalous API calls, or post-incident forensics reveal that access was still live, at which point session and token revocation becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret and token lifecycle management that revocation is meant to stop. |
| NIST CSF 2.0 | PR.AC-3 | Addresses access enforcement and credential revocation as part of controlled access. |
| NIST SP 800-63 | Defines session management concepts that inform termination and reauthentication requirements. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification, making revoked credentials unusable by design. | |
| NIST AI RMF | AI risk governance includes access governance for agents and their credentials. |
Track issued tokens, revoke exposed credentials fast, and verify downstream enforcement after invalidation.
Related resources from NHI Mgmt Group
- Who is accountable when identity threats are contained by session revocation or token invalidation?
- How should security teams respond when a SaaS session token is stolen?
- What is the difference between token rotation and token revocation?
- What is the difference between token revocation and least privilege?
