Token minting is the act of creating a signed identity artefact that other systems accept as proof of authentication or authorization. In a compromised issuer, minting becomes the line between a backend defect and enterprise-wide impersonation.
Expanded Definition
Token minting is the controlled creation of a signed token that a system accepts as proof of identity, session state, or delegated authorization. In NHI operations, the token may represent an application, workload, API client, agent, or service account rather than a human user. That distinction matters because token minting is not just issuance; it is the act of asserting trust in a portable artefact that can be replayed across systems until it expires or is revoked. The closest standards discussion sits within identity assurance and access control, including NIST Cybersecurity Framework 2.0, though no single standard governs token minting as a standalone term yet. Usage in the industry is still evolving across OAuth, OIDC, SPIFFE, and agentic AI platforms.
The core security question is who is allowed to mint, under what policy, and with what cryptographic binding to workload identity, trust domain, or session context. A minted token that is too broad, too long-lived, or too easy to generate collapses least privilege into impersonation at scale. The most common misapplication is treating minting as a routine backend function, which occurs when engineering teams expose signing or exchange endpoints without issuer hardening, policy enforcement, or auditability.
Examples and Use Cases
Implementing token minting rigorously often introduces latency, policy complexity, and key-management overhead, requiring organisations to weigh rapid service interoperability against tighter issuance controls.
- An OAuth authorization server mints access tokens for a SaaS integration, with scope restricted to one tenant and a short TTL.
- A workload identity platform mints SPIFFE-compatible SVIDs for ephemeral services, binding tokens to runtime attestation rather than static secrets.
- An AI agent mints delegation tokens to call internal tools, but only after step-up policy approval and tool-specific claims validation.
- A CI/CD pipeline mints build-time tokens for artifact signing, then revokes them immediately after the deployment job completes.
- A compromised issuer mints valid tokens for multiple downstream systems, which is why incidents such as the Salesloft OAuth token breach matter to NHI defenders.
For implementation patterns, SPIFFE is useful where workloads need verifiable identity tied to a trust domain, while token exchange and delegated authorization behaviours are often described in the OAuth ecosystem and adjacent guidance.
Why It Matters in NHI Security
Token minting becomes a high-impact control point because one issuer can create trust artifacts for many downstream applications, APIs, and agents. If the issuer, signing key, or policy engine is compromised, attackers do not need to steal every token individually; they can manufacture valid ones on demand. That is why token minting belongs in the same governance conversation as secret management, issuer isolation, and privilege boundaries. NHIMG research shows how frequently token and secret handling fails in practice: 91% of former employee tokens remain active after offboarding, and 44% of NHI tokens are exposed in the wild across tools such as Teams, Jira, Confluence, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
That operational reality is compounded by secret sprawl. In The State of Secrets Sprawl 2026, 64% of valid secrets leaked in 2022 are still valid and exploitable today, which underscores that minted tokens and the keys behind them must be revocable, short-lived, and observable. Organisations typically encounter the true blast radius only after a token issuer is abused or a downstream service starts accepting forged claims, at which point token minting 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 and CSA MAESTRO address the attack and risk surface, while NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Token issuance and issuer trust are central to NHI identity abuse and forgery risks. |
| NIST SP 800-63 | AAL2 | Token strength and assurance map to identity proofing and authenticator assurance concepts. |
| NIST Zero Trust (SP 800-207) | PR.AC | Zero Trust requires continuous verification of minted credentials before each access decision. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and least privilege directly govern what a minted token may do. |
| CSA MAESTRO | Agentic systems depend on safe token minting for delegated tool use and workload identity. |
Bind minted tokens to appropriate assurance levels and enforce expiry, replay resistance, and binding.
