Security2 publishers2 min readPublished
NIST and CISA finalize the token forgery guidance cloud customers can now cite
NIST and CISA have finalized IR 8587, guidance that spells out how signing keys, token verification and revocation are supposed to be handled in cloud identity systems.
The Watch · Security desk
What happened
- NIST and CISA have finalized NIST IR 8587, guidance on protecting identity assertions and access tokens from forgery, theft and misuse at federal agencies and cloud service providers.
- The report cites an intrusion in which foreign actors forged tokens with a stolen commercial signing key to reach government email accounts, taking more than 60,000 emails from one agency.
- The final version updates the initial public draft with feedback on token validation, secrets management and detection at scale, including industry input CISA gathered through its Joint Cyber Defense Collaborative.
- NIST says organizations should apply the same token protections to AI agents, while acknowledging that agents raise wider identity and access problems this report does not cover.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Customers never touch a provider's signing key, but the report puts configuration, access policy, permission review and control usage on their side of the line, so those are the items an assessor will ask them about after a token incident.
- decision Revocation, signal sharing and joint investigation now have a written expectation behind them. Who can revoke a compromised signing key becomes a contract and onboarding question.
- capability An identity team pressing a cloud provider on key usage limits can point to a federal document tied to Executive Order 14306 and the existing controls catalog instead of relying on a vendor security page.
- precedent By extending token controls to AI agents before agent-specific standards exist, NIST sets the baseline reviewers are likely to apply to agent access in the interim.
A token signed with a stolen key verifies correctly at every service that trusts the issuing key, so signature checking alone will not catch it [18]. IR 8587 builds its recommendations on that point: protect the cryptographic keys used to sign tokens and assertions, limit how those keys can be used, verify tokens properly before granting access [4]. It also addresses token lifetimes, revocation, session management, logging, and protections against the reuse of stolen tokens [4]. The main scope is identity and access management built on digitally signed assertions and tokens using asymmetric cryptography, the pattern behind single sign-on, identity federation, API access and workload access; systems without asymmetrically signed tokens come up where relevant but sit outside it [5].
Once a signing key is out, the work shifts to telemetry. NIST tells organizations to collect information about token use and look for activity that could indicate stolen credentials, forged tokens or unauthorized access, to keep logs that support monitoring and incident investigation, to watch for changes to access permissions and configurations, and to have procedures ready for tokens or keys that may be compromised [12].
The document is an interagency report from NIST and CISA aimed at federal agencies and cloud service providers [16]. It expands on the NIST special publication on security and privacy controls for information systems and organizations, and supports Executive Order 14306 on secure software development practices [15]. The published announcements do not include a compliance date [17].
The part identity teams can put in front of a provider is the division of labor. The provider is responsible for securing identity providers and authorization servers, protecting signing keys, issuing tokens securely, and giving customers security features and configuration options [6]. The customer is responsible for configuring the services it uses, managing access policies, reviewing permissions, and actually using the controls the provider makes available [7]. Four tasks land on both sides at once: responding to compromised tokens or signing keys, sharing security signals, revoking access, and investigating incidents [8][9]. Each of those needs a counterpart and a procedure agreed before an incident, because during one there is no time to negotiate who can revoke what.
"This publication provides implementation considerations for protecting tokens appropriately," said Ryan Galluzzo, NIST Digital Identity Program Lead and one of the publication's authors [10]. "Anyone who is using tokens as part of their access management infrastructure can look to this for insights, whether they are in government or commercial industry," Galluzzo said [11].
What to watch
- Whether federal assessors and cloud authorization packages start quoting IR 8587 sections when reviewing identity providers.
- The follow-on NIST guidance on agent identity, which IR 8587 says is outside its scope.
- Whether providers begin publishing how they constrain signing key usage and how fast they can revoke a compromised key.