Standing token

Expanded Definition

A standing token is not just a token that exists for a long time; it is a credential that keeps authority beyond the immediate transaction or workflow step that created it. In NHI operations, that persistence can be intentional for service continuity, but it also creates standing access that should be treated as an exception, not the default. This is closely related to lifecycle governance, secret rotation, and privilege minimisation, and it becomes especially important when an app, pipeline, or integration is decommissioned, repurposed, or granted broader access than originally intended. NIST Cybersecurity Framework 2.0 frames the broader control expectation around protecting identities and reducing persistent risk, even though no single standard governs the term "standing token" itself. Definitions vary across vendors, but in practice the term usually covers API tokens, OAuth access tokens, refresh tokens, and service credentials that remain usable after the business moment has passed. The most common misapplication is treating a standing token as a harmless convenience token, which occurs when teams fail to tie expiry and revocation to the workflow lifecycle.

For a broader view of how long-lived access creates exposure in real environments, see NHI Management Group's analysis of the Guide to the Secret Sprawl Challenge and the Salesloft OAuth token breach. For the identity and access model behind this risk, NIST Cybersecurity Framework 2.0 remains a useful baseline for governance and control mapping.

Examples and Use Cases

Implementing standing-token controls rigorously often introduces operational friction, because shorter lifetimes and revocation checks can add engineering work and require more mature automation, but that tradeoff is usually preferable to broad, silent persistence of access.

• A CI/CD pipeline uses a deployment token that never expires, even after the repository is archived or the release target changes.
• An OAuth refresh token remains valid long after the original app integration is removed, allowing re-issuance of access without a fresh business justification.
• A service account token is embedded in a workflow and reused across multiple tools, creating a hidden dependency that survives application ownership changes.
• An external vendor integration keeps a token active after contract termination, leaving access open until someone manually discovers and revokes it.

These patterns show up repeatedly in breach writeups such as the Dropbox Sign breach and the JetBrains GitHub plugin token exposure, where persistent credentials outlived the original trust boundary. External guidance from NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to manage identity risk continuously rather than as a one-time provisioning event.

Why It Matters in NHI Security

Standing tokens matter because they collapse the normal security assumption that access should end when the task ends. When a token remains valid, compromise does not require fresh authentication, which means a leaked token can function like an open door until it is detected and revoked. That is especially dangerous in NHI environments where tokens are copied into tickets, build logs, chat threads, or configuration files and then forgotten. In the 2025 State of NHIs and Secrets in Cybersecurity, Entro Security reported that 44% of NHI tokens are exposed in the wild and that 91% of former employee tokens remain active after offboarding, underscoring how often persistence outlasts governance. NHI Management Group's Guide to the Secret Sprawl Challenge shows why revocation discipline is not optional when secrets spread across tools and teams.

Practitioners should treat standing tokens as a lifecycle control problem, not just an authentication issue, and verify ownership, expiry, scope, and revocation path for every non-human credential. Organisations typically encounter the damage only after a token is replayed from an unexpected location, at which point standing token cleanup becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is Zero Standing Privilege (ZSP) and how does it apply to NHIs?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• Why is OAuth token management critical in cloud environments?
• How should organizations respond to OAuth token abuse incidents?