Subscribe to the Non-Human & AI Identity Journal
Home Glossary Authentication, Authorisation & Trust Dormant OAuth Token
Authentication, Authorisation & Trust

Dormant OAuth Token

← Back to Glossary
By NHI Mgmt Group Updated August 1, 2026 Domain: Authentication, Authorisation & Trust

An OAuth token that has been issued successfully but has not been used for a meaningful period. In NHI governance, dormancy is not safety. A dormant token can still carry the same privileges as an active one until it is explicitly revoked or expires by policy.

Expanded Definition

A dormant oauth token is still a live credential artifact: it was issued through an authorization flow, may retain scopes, and can remain fully capable of acting on behalf of a user or service until revoked, rotated, or expired by policy. In NHI governance, dormancy describes inactivity, not reduced privilege. That distinction matters because token lifecycle risk is separate from login frequency. Standards guidance around access control and credential lifecycle is best interpreted through sources such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where periodic review, revocation, and least privilege are required.

Definitions vary across vendors on when a token becomes "dormant" versus merely "unused," because some platforms track last use, while others only expose issue and expiry timestamps. The practical NHI control question is whether the token is still authorized to access resources, not whether it has been observed in recent logs. This is why dormant tokens sit at the intersection of identity governance, secrets management, and authorization hygiene, as discussed in the State of Non-Human Identity Security. The most common misapplication is treating inactivity as de facto deprovisioning, which occurs when teams assume a quiet token has no operational reach because it has not been seen in recent monitoring.

Examples and Use Cases

Implementing dormant-token controls rigorously often introduces operational friction, requiring organisations to balance stronger revocation discipline against the risk of breaking unattended workflows, integrations, and scheduled jobs.

  • A SaaS integration token used by a CRM sync job has not called the API for 90 days, but it still has write permissions and must be revoked if the job is retired.
  • A third-party OAuth app connected to a collaboration platform remains authorized even though the original employee left the company, creating hidden access that only an app inventory review can expose.
  • An automation token embedded in a CI/CD pipeline has not been used since a deployment freeze, but it may still be present in runners or vaults, making The State of Secrets Sprawl 2026 relevant to the revocation workflow.
  • A long-lived API access token issued for reporting access remains dormant until a billing export job runs monthly; if the scope is broader than needed, it should be narrowed or replaced with shorter-lived credentials.
  • A dormant token linked to a compromised OAuth app can be reactivated by an attacker who already has the token string, which is why Salesloft OAuth token breach is a cautionary example of post-issuance risk.

Industry usage is still evolving, but the core management pattern is consistent: build inventory, identify last-seen use, compare privilege to current need, and revoke anything that no longer has a business owner.

Why It Matters in NHI Security

Dormant OAuth tokens matter because they create an authorization gap that is invisible to many access reviews. A token can look harmless if it is not actively generating traffic, yet it may still be valid for data access, administrative actions, or API-driven lateral movement. That is especially dangerous in environments where third-party OAuth apps are common and visibility is incomplete. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 64% of valid secrets leaked in 2022 are still valid and exploitable today, underscoring that detection without revocation leaves risk in place. For governance teams, the implication aligns with NIST control expectations for account and credential review, not just alerting.

The issue is also linked to broader NHI control failure: if a dormant token is never inventoried, monitoring cannot distinguish a forgotten integration from a maliciously preserved credential. That is why Guide to the Secret Sprawl Challenge and the State of Non-Human Identity Security are both relevant to operational governance, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control logic for review and revocation discipline. Organisations typically encounter dormant-token risk only after an audit, breach investigation, or offboarding failure reveals that an unused credential was still valid and had been quietly retaining access.

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.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02Dormant tokens are a secret lifecycle and revocation problem under NHI controls.
NIST CSF 2.0PR.AC-1Access rights must be managed across the full credential lifecycle, including inactivity.
NIST SP 800-63Identity assurance guidance informs token issuance, lifecycle, and revocation expectations.
NIST Zero Trust (SP 800-207)Zero Trust assumes every credential remains risky until explicitly validated and constrained.
NIST AI RMFAI governance depends on controlling unattended credentials used by agents and automations.

Apply strong lifecycle controls so issued tokens cannot linger beyond their business need.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org