Token forgery is the creation of a valid-looking authentication token without legitimate authorization from the identity provider. It usually depends on exposing signing keys, encryption secrets, or recovery material. In identity programmes, forgery matters because it bypasses login controls and turns stolen secrets into direct impersonation.
Expanded Definition
Token forgery is not simple token theft. It is the creation or reconstruction of a token that looks authentic to downstream systems, usually after an attacker obtains signing keys, encryption secrets, or recovery material. In NHI security, that distinction matters because validation can succeed even when the original identity provider never issued the token.
Definitions vary across vendors on whether forgery includes only fully minted tokens or also manipulated JWTs and session artifacts, but the operational risk is the same: a forged token can impersonate a service account, agent, or user-equivalent workload without reauthentication. The strongest control model treats token forgery as a credential integrity failure, not just an access event. That is why guidance from NIST Cybersecurity Framework 2.0 and identity assurance practices should be read alongside token lifecycle controls, key custody, and revocation discipline.
The most common misapplication is treating any token-related incident as mere theft, which occurs when teams ignore signing-key exposure, key reuse, or weak rotation and assume expiration alone will stop impersonation.
Examples and Use Cases
Implementing token controls rigorously often introduces more key rotation, stronger custody, and tighter deployment gates, requiring organisations to weigh developer convenience against the cost of preventing silent impersonation.
- A CI/CD runner leaks a private signing key, and an attacker forges access tokens that are accepted by APIs until the key is revoked.
- A compromised secrets vault allows a malicious operator to mint valid-looking tokens for a privileged NHI, bypassing login flows entirely.
- A stolen recovery secret lets an attacker rebuild a token-signing context after incident response has already begun, prolonging exposure.
- A SaaS integration uses weak token validation, so forged bearer token are accepted because the application trusts format more than issuer integrity.
- Post-incident analysis ties the abuse to exposed credentials in Salesloft OAuth token breach, showing how a token can become a reusable impersonation artifact when secret material is compromised.
For implementation context, token forgery should be evaluated alongside the validation and token binding principles described in the NIST Cybersecurity Framework 2.0, especially where NHIs, agents, and automation accounts exchange credentials without human review. The practical lesson is to verify issuer trust, signing key rotation, and audience restrictions, not just token presence.
Why It Matters in NHI Security
Token forgery is one of the fastest paths from a secret leak to full-blown identity compromise because the forged artifact inherits the trust of the original issuer. In NHI environments, that can mean API access, orchestration control, data movement permissions, or agent execution authority. The danger is amplified when teams overuse tokens, duplicate them across systems, or leave former credentials active after offboarding.
That risk is not theoretical. GitGuardian reported that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase, which shows how often the raw material for forgery is exposed in ordinary engineering workflows. Entro Security also found that 44% of NHI tokens are exposed in the wild, often across collaboration tools and code commits, which makes forged-token scenarios more likely than many organisations assume.
This is why practitioners should pair token signing controls with zero standing privilege, short token lifetimes, and immediate revocation paths. When teams later inspect strange API calls or unexpected agent actions, token forgery often becomes obvious only after the compromise has already been used for lateral movement or data exfiltration, at which point identity recovery is no longer optional.
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 SP 800-63 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-02 | Token forgery stems from weak secret and token lifecycle controls. |
| NIST SP 800-63 | Digital identity guidance informs assurance, binding, and token trust decisions. | |
| NIST CSF 2.0 | PR.AC-1 | Access control practices must prevent forged tokens from gaining unauthorized trust. |
Require strong issuer validation and token binding so forged artifacts cannot pass as legitimate identity.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
