Steal a token and you get one session. Steal the key that signs tokens and you can mint any session you like, for anyone, without ever touching a password. NIST and CISA published the final version of Interagency Report 8587 on September 15, setting out implementation recommendations for protecting identity assertions, access tokens and the cryptographic machinery behind them.
The report is written for federal agencies and cloud service providers, and it is worth reading well outside that audience. Any organisation running single sign-on, identity federation or API access has the same structure: a small amount of key material whose compromise invalidates every authentication decision downstream.
What the report actually is
NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers, is dated September 2026 and authored by Ryan Galluzzo and Andrew Regenscheid of NIST's Information Technology Laboratory, with Christine Lazcano of CISA's Cybersecurity Division and Stephanie Nelson of Accenture Federal supporting CISA. It is the final version; an initial public draft went out for comment, with the comment period closing January 30, 2026.
The report's own abstract states that it builds on updates to NIST SP 800-53 (Release 5.1.1), outlines principles for cloud service providers and consuming agencies, details architectural considerations for identity providers and authorization servers, and recommends enhancements to key management, token verification and life cycle controls. Its stated scope is single sign-on, federation and API access.
It is grounded in real incidents rather than theory: the reference list includes Microsoft's 2023 analysis of Storm-0558 token forgery and CISA's advisory on the SolarWinds-era supply chain compromise. The report is careful about this, stating that its threat table “is not an analysis of one specific event, nor is it a comprehensive set of protections” against threats to devices and endpoints such as malware, compromised endpoints and insider threats.
The threat model in one line
The report's own description of assertion or token manufacture is the sentence to take away: the attacker generates a false assertion or modifies one, and this is “typically executed in conjunction with a signing key compromise.” Every other control in the document exists because that one event is catastrophic and nearly invisible. A forged token does not look like a break-in. It looks like a legitimate login by a legitimate user.
What it recommends, in practical terms
The technical substance clusters into four areas, all of which apply to organisations that will never file a federal compliance report:
- Key custody. Signing keys generated and held in hardware security modules, rotated on a schedule, and destroyed properly when retired. The report treats key management as the foundation the rest of the stack sits on, not as a deployment detail.
- Token verification. Rigorous validation on the consuming side, including audience restriction—a token issued for one application must not be accepted by another. The report returns to audience handling repeatedly.
- Lifetime and binding. Short-lived access tokens, plus sender-constrained tokens so a stolen bearer token is not enough on its own. The report covers proof-of-possession approaches including DPoP and mTLS, and devotes a section to device-bound session credentials.
- Revocation and monitoring. Working revocation paths, replay controls, and logging of token and assertion events so unusual issuance can actually be spotted. Revocation is the single most frequently discussed topic in the document.
Its principles for cloud providers are worth quoting to your own vendors: secure development and design, transparency about architecture and system-generated data, configurability so consumers can tune security features, interoperability, and continuous monitoring. The transparency principle is explicitly framed as giving customers enough information to make informed risk decisions—and the report notes it is not intended to add audit or compliance obligations.
There is also a forward-looking section on post-quantum cryptography migration for this part of the stack, which is a reasonable prompt to inventory where your signing algorithms are pinned before that becomes urgent.
What the report does not do
It is guidance, not an incident report and not a regulation. Publication does not mean a new breach occurred, and following it does not establish compliance with anything by itself. It also explicitly does not cover the endpoint side of the problem—malware, compromised devices, insider access—which remains a separate and substantial risk to the same tokens. Treat it as a well-sourced checklist, not a certification.
The operational gap: moving key material safely
Here is the part the guidance necessarily leaves to you. Key rotation is a procedure with humans in it. Someone generates the new key, someone configures the relying parties, someone holds the break-glass credential for the HSM, and someone has to hand over an initial secret or a recovery code to a person who is not in the room.
That handover is where well-run organisations quietly undo their own key management:
- Prefer never exporting the key. A key generated inside an HSM and used there is a key that has no handover problem. Design the rotation so no human ever sees the private key material.
- Separate what must be split. For HSM administrator credentials, break-glass codes and recovery material, require more than one holder to reconstruct the value. A single compromised mailbox should not be enough to reach the key that signs your tokens.
- Do not put recovery material in the incident channel. Incident tickets and war-room chats get widely shared, exported and read months later by people who were not there. If a signing key is suspect, the coordination channel may be suspect too.
- Use a channel that expires rather than one that archives. When a person genuinely must receive a value, deliver it in a form that stops existing shortly afterwards instead of sitting in a searchable history.
- Test revocation before you need it. The report emphasises revocation heavily for a reason. A revocation path nobody has exercised is a plan, not a control.
Where Secretus fits—and where it does not
Secretus can reduce plaintext exposure when an authorized person must deliver a small, temporary value—an enrolment code, a recovery credential, an initial secret during a rotation—over a channel that does not retain it the way chat and ticketing do. Team Split can require several holders to reconstruct a high-value text secret such as a break-glass code, which lines up with the report's emphasis on protecting the credentials that guard signing keys.
It is not a key management system, not an HSM, not an identity provider, and not a way to store signing keys. It does not verify recipient identity, issue or validate tokens, or tell you whether a token in your logs was forged. Read IR 8587 for the architecture; use a one-time channel only for the narrow human step of moving a value between two people who have already verified each other.