NIST IR 8587, finalized September 15, 2026, addresses forgery, theft, and misuse of identity tokens and assertions. It is aimed primarily at federal agencies and cloud service providers, but its operational lesson is wider: token protection depends on governing the cryptographic keys, verification paths, and lifecycle decisions behind each token—not merely on choosing a strong signing algorithm.
NIST’s announcement explains that the final report expanded guidance on cryptographic key usage, protection, and storage, while making key-protection recommendations more outcome-based. The report also adds high-level considerations for AI and post-quantum migration. Those additions do not turn it into a complete PQC implementation manual. They do make clear that identity architecture, cryptography, and operational ownership are becoming harder to separate.
A token is only as trustworthy as its issuance and verification chain
Identity and access tokens often look like a small application detail. In reality, they can authorize access across many services. A signing key may be held by an identity provider, a cloud service, or a federation partner; a consuming application may fetch verification keys, cache them, and apply its own validation rules. Every boundary creates a different failure mode.
A token can be stolen even if its signature is valid. A forged token can appear legitimate if a signing key is compromised. A verifier can accept a token for the wrong audience, issuer, or lifetime. A key rotation can fail if consumers keep stale verification material. These are not all solved by a more advanced primitive. They require sound architecture, configuration, monitoring, and incident procedures.
NIST cites a past attack in which forged tokens derived from a stolen signing key enabled access to agency email. The operational point is not to replay that incident as a universal pattern. It is to recognize that one cryptographic asset can carry risk across many downstream applications. Inventory and ownership need to reflect that blast radius.
Make signing keys and relying parties visible
A useful inventory for token security should identify each issuer, authorization server, key or key set, algorithm, storage boundary, rotation method, and set of relying parties. It should also distinguish a provider-managed key from a customer-controlled key and record which party can revoke, replace, or investigate it.
That map should include evidence, not just architecture diagrams. Teams should know which keys are configured, which versions are active, which verifiers consume them, how recently the relationships were checked, and where coverage is incomplete. For critical federation paths, test what happens during emergency rotation and token revocation. A plan that depends on an undocumented cache lifetime or manual coordination is not a reliable control.
Because tokens frequently cross organizational boundaries, provider and customer responsibilities deserve explicit review. A provider may protect a signing key but leave token lifetimes, audiences, revocation options, and application verification settings to the customer. Conversely, a customer may configure its applications correctly while depending on opaque provider-side key handling. Neither side should assume the other owns the whole chain.
Post-quantum planning belongs in the same record
The final publication includes high-level PQC considerations, not a mandate to switch every identity token to a particular algorithm today. Identity migrations have multiple dependencies: signing services, hardware security modules, certificate formats, federation protocols, client libraries, token sizes, verifier compatibility, and long-lived trust anchors.
Before making a PQC claim, an organization should distinguish what a product supports from what its deployed configuration uses. It should know which tokens and assertions depend on quantum-vulnerable public-key signatures, which parties must change together, and how rollback would work. Some use cases may have longer-term integrity needs than others; prioritization should reflect the sensitivity and lifetime of the assertion and the consequences of a forged or unverifiable record.
Crypto agility here means retaining the ability to change signing mechanisms and key management without losing control of identity relationships. It is not a checkbox or a promise that a standards update automatically reaches every relying party.
Practical next steps
- Map the trust graph. List issuers, signing keys, authorization servers, verifiers, applications, and external federation partners.
- Assign lifecycle owners. Identify who can rotate keys, revoke tokens, change verification policy, and respond to a compromise.
- Test adverse states. Exercise key theft, emergency rotation, verifier misconfiguration, and delayed revocation.
- Preserve evidence. Record key versions, configurations, observations, test dates, exceptions, and known blind spots.
- Plan PQC as a dependency change. Evaluate the whole identity path, not just the signing algorithm.
How Vista Platform can help
Vista Platform is a self-hosted cryptographic system of record. Its operating loop is discovery, canonical inventory, evaluation, action, and proof. It can help teams connect cryptographic observations to assets, configurations, certificates, algorithms, findings, and remediation work so that token-related cryptography is governed in context.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. It tracks and governs post-quantum migration; it does not issue tokens, generate PQC keys, or perform every migration step. Selected-asset Active Scan is not indiscriminate network scanning. Vista is not a vulnerability scanner, and a discovery gap is not proof of absence. See Vista’s PQC approach or try Core.
Where uncertainty remains
NIST IR 8587 provides recommendations and architectural considerations, not a single implementation profile for every token format or cloud service. The new PQC material is explicitly high-level. Teams must assess their own provider contracts, deployed configurations, and standards maturity before deciding what to change and when.
Sources
- Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers, NIST and CISA, final September 15, 2026.
- NIST Finalizes Guidelines on Protecting Online Identity and Access Tokens From Misuse, NIST, September 15, 2026.