NIST Publishes Guidance on Protecting Tokens and Assertions from Forgery, Theft and Misuse
The National Institute of Standards and Technology (NIST) has published NIST IR 8587 — Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers.
Published in September 2026, the report provides implementation guidance for protecting identity tokens, access tokens and assertions used in modern identity and access management systems.
The guidance builds on updates to NIST SP 800-53 and focuses on key management, token verification, token lifecycle controls, secure design, interoperability and continuous monitoring across single sign-on (SSO), federation and API access scenarios.
Why Token Security Matters
NIST developed the guidance in response to cybersecurity incidents in which attackers were able to steal, modify or forge identity tokens and assertions used in enterprise SSO and identity federation systems.
Such attacks can provide access to sensitive applications, data and communications, particularly where cryptographic signing keys are compromised or token verification mechanisms are improperly implemented.
The report is specifically scoped to federal environments, but its technical recommendations address cloud services and common IAM architectures that are also widely used outside government.
Identity Tokens, Access Tokens and Assertions
NIST explains that tokens and assertions allow protected resources to make authentication and authorization decisions without requiring users to authenticate directly every time they access a service.
The report distinguishes three common categories:
identity tokens and assertions, used to communicate identity and authentication information;
access tokens, used to grant access to specific resources, applications or services;
refresh tokens, which can be exchanged for new identity or access tokens to extend sessions.
These mechanisms are particularly relevant to SSO, federation, API access and non-human machine-to-machine communications.
Shared Responsibility Between Cloud Providers and Customers
NIST emphasises a shared responsibility model between Cloud Service Providers (CSPs) and consuming organisations.
CSP responsibilities may include core IAM services, token issuance and signing, secrets storage and infrastructure-level logging. Consumers typically remain responsible for IAM policy configuration, user and application access controls, secrets management, authentication setup, session management and application logging.
The table on page 3 of the report illustrates this distribution of responsibilities and identifies areas such as incident response, continuous monitoring and token revocation as shared activities.
Secure-by-Design Principles
For cloud service providers, NIST highlights principles including:
secure development and design;
transparency;
configurability;
interoperability;
resilience and recovery capabilities.
For consuming organisations, the report emphasises risk assessment, control selection, tailoring and secure configuration of cloud services.
Continuous Monitoring
NIST states that identity management controls should not be treated as “set and forget.”
CSPs and consuming organisations should continuously monitor accounts, clients and entities that issue, consume or validate tokens and assertions, while regularly reviewing access policies, entitlements, grants and account status.
The report notes that token-related compromises may only become visible through account activity monitoring and analysis of cloud service logs.
Artificial Intelligence and AI Agents
The report also addresses AI and agentic AI systems.
NIST notes that AI agents increasingly use signed tokens and assertions when accessing systems, data, tools and APIs. The recommendations in NIST IR 8587 should therefore be applied where AI agents rely on signed tokens for IAM purposes.
However, NIST clarifies that the report is not a comprehensive guide to AI-agent identity and access risks, noting that additional standards and guidance are still being developed.
IA-13: Identity Providers and Authorization Servers
A central part of NIST IR 8587 is IA-13: Identity Providers and Authorization Servers, introduced into NIST SP 800-53 following high-profile token-related incidents.
IA-13 addresses how identity providers and authorization servers manage human, device and non-person identities, attributes and access rights used for authentication and authorization decisions.
NIST requires organisations claiming conformance with the guidance to evaluate, design and document an architecture appropriate to their operational and security requirements.
Zero Trust and Contextual Access Decisions
NIST links token and assertion security directly to Zero Trust architectures.
The report states that authorization systems should not grant access solely because a token is technically valid. Access decisions should also consider the context in which the token is presented.
Token-based systems should therefore be integrated into the full identity lifecycle, including provisioning, deprovisioning, entitlements, least privilege, separation of duties and just-in-time access.
Protection of Cryptographic Keys
One of the most important areas addressed by NIST IR 8587 is protection of the cryptographic keys used to sign tokens and assertions.
A compromised signing key may allow an attacker to create apparently legitimate tokens and obtain unauthorised access to connected systems.
NIST recommends secure key generation, controlled distribution, isolated storage, documented usage periods, regular rotation, revocation and secure destruction.
For moderate-impact systems or above, signing keys should be stored using hardware-based, hardware-backed or otherwise isolated mechanisms rather than persistently within the applications, servers, virtual machines or containers that use them.
Key Rotation
NIST recommends defining documented cryptographic key usage periods and using automated key rotation where possible.
For high-impact systems, signing keys should generally have a maximum active usage period of 90 days. For moderate- and low-impact systems, longer periods may be appropriate but should generally remain under one year.
The guidance also recommends documented rollover procedures covering creation, publication, activation, overlap, deactivation, removal, revocation and destruction.
Token Verification
Before granting access, relying parties and resource servers should verify the source, integrity, validity and intended scope of tokens and assertions.
NIST stresses that signing keys should be limited to the lowest reasonable scope, such as a particular tenant, customer or environment. Keys should also not be reused for unrelated purposes.
The guidance further recommends validating issuer information, audience, timestamps, token identifiers and signatures before accepting tokens.
Short Token Lifetimes
NIST recommends keeping identity and access tokens short-lived to reduce exposure if they are compromised.
The report recommends that identity and access tokens should generally be valid for no more than one hour, although actual validity periods should reflect risk, application assurance requirements and available mitigating controls.
Cloud providers should also make token lifetime configurable so consuming organisations can adapt settings to their security requirements.
Token Revocation
The guidance recognises that immediate revocation can be difficult in stateless architectures.
NIST therefore recommends combining short-lived tokens with mechanisms such as refresh-token controls, reauthentication, revocation signalling and session termination.
Identity providers and token services should, where possible, propagate revocation information to relying parties so compromised sessions can be terminated quickly.
Audience Restriction
Tokens and assertions should only be accepted by the service or application for which they were issued.
NIST states that all tokens and assertions must contain explicit audience information and that access control systems should reject tokens with incorrect or missing audience restrictions.
This reduces the risk that a valid token issued for one service can be redirected and misused elsewhere.
Monitoring and Logging
Continuous session monitoring is another central recommendation.
Organisations should monitor token and assertion usage for indicators such as unusual geolocation, device information and behavioural anomalies, and integrate this information with SIEM, UEBA and other security monitoring technologies.
NIST also states that logging is critical for incident detection and investigation.
However, the tokens and assertions themselves — and personal information contained within them — must not be stored in logs.
Protecting Tokens From Exposure
Tokens must also be protected from accidental exposure in:
system logs;
CI/CD pipelines;
build outputs;
debugging information;
cache directories;
deployment artefacts.
NIST recommends retrieving secrets through approved secret-management systems and injecting them only temporarily when needed.
Non-Human and Workload Identities
The guidance devotes specific attention to workloads and machine-to-machine interactions.
Workload identities should use tightly scoped and short-lived tokens issued through approved identity platforms. Sender-constrained mechanisms such as mTLS or DPoP are recommended where feasible.
This is increasingly relevant as automated software services, APIs, connected devices and AI agents interact without direct human authentication.
Main Threats Identified by NIST
The report identifies several important threats involving tokens and assertions, including:
token or assertion forgery;
modification;
redirection;
replay;
signing-key compromise;
token theft.
Recommended mitigations include cryptographic signing, signature validation, key isolation and rotation, sender-constrained tokens, contextual authorization controls and tamper-resistant logging.
Post-Quantum Cryptography
NIST IR 8587 also addresses future migration toward post-quantum cryptography (PQC).
The report notes that common public-key mechanisms used today, including RSA, ECDSA and ECDH, could become vulnerable to cryptographically relevant quantum computers.
NIST recommends that agencies and CSPs begin inventorying public-key cryptography used throughout token and assertion ecosystems and evaluate the impact of migration to algorithms such as ML-KEM and ML-DSA.
The document also warns that larger post-quantum signatures and keys may affect JWT size, browser cookies, HTTP headers, metadata and token delivery architectures.
Relevance for Medical Device and Digital Health Organisations
NIST IR 8587 is not medical-device-specific and is formally scoped to U.S. federal environments. However, its technical recommendations may be relevant to medical device and digital health organisations that operate cloud platforms, APIs, SSO systems or connected services using token-based authentication.
Relevant areas for cybersecurity and software teams may include:
cloud IAM architecture;
API authentication;
SSO and federation;
cryptographic key protection;
token verification;
short-lived access credentials;
machine and workload identities;
AI-agent access;
Zero Trust controls;
CI/CD secret protection;
security logging;
session monitoring;
incident response;
post-quantum migration planning.
For connected medical devices, SaMD platforms and digital health infrastructure using these technologies, the broader lesson is that token security should be treated as part of the complete identity and access lifecycle rather than as an isolated authentication mechanism.
