NIST and CISA tell agencies how to stop attackers walking in on stolen login tokens
The joint report tells federal agencies and cloud providers how to lock down the digital passes that keep users signed in across cloud services.

Key points
- NIST and CISA published the final version of a joint report on protecting identity tokens and assertions used across federal cloud systems.
- The guidance targets the signed digital passes that let users move between apps without logging in again, which attackers try to steal or forge.
- It updates an earlier public draft with feedback on token validation, secrets handling, and detection at scale.
- The document supports Executive Order 14306 on secure software development and expands on NIST's catalogue of security and privacy controls for federal systems.
- CISA gathered industry input through its Joint Cyber Defense Collaborative before finalising the report.
The National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA) have released the final version of a joint report telling federal agencies and cloud providers how to defend the digital credentials that quietly keep modern cloud services running.
Those credentials are called tokens and assertions. They're short signed messages a system hands your browser or app to prove you've already logged in, so you don't have to type a password every time you open a new service. Steal or forge one and you can walk into systems as someone else, no password required.
What does the guidance actually cover?
The report sets out how agencies and their cloud vendors should generate, sign, validate and monitor these tokens across hybrid setups, meaning environments that mix on-premises servers with one or more public clouds. It focuses on the machinery behind single sign-on (one login for many apps), federation (one organisation trusting another's logins), and APIs, the pipes that let software talk to other software.
All of these lean on signed tokens. The guidance treats those tokens as prime targets: a stolen or forged one lets an intruder move sideways through a network and reach sensitive data without triggering a normal password alarm.
What changed from the draft?
This is the final report, not a proposed one. It folds in comments the agencies received on how systems should validate tokens, how secrets such as signing keys should be stored and rotated, and how defenders can spot token abuse at scale. CISA also pulled in input from government and private-sector experts through its Joint Cyber Defense Collaborative, the public-private group the agency uses to coordinate on operational cyber defence.
Where does it fit in the wider rulebook?
The document expands on NIST's existing catalogue of security and privacy controls that federal systems are already expected to follow, and it supports Executive Order 14306, which directs agencies toward secure software development practices.
It pushes for defences built on Secure by Design principles, meaning products should ship safe rather than depending on customers to bolt on protection later. Consistency across cloud providers matters here too: agencies using more than one vendor shouldn't end up with mismatched controls.
Our earlier story on a proposal to auto-cancel stolen API keys within sixty seconds showed just how fast credential abuse can move once a token or key is out in the wild. This report addresses the same problem at the architecture level.
Who has to pay attention?
Federal agencies and the cloud service providers that sell to them are the direct audience. There's no compliance deadline attached: it's an interagency report that sits alongside existing controls and executive orders, not a regulation on its own.
Private-sector security teams running similar single sign-on and API setups will recognise most of the architectural advice. Vendors serving federal customers will be expected to align with it. And given that half of real-world attacks now target login systems, the audience for this kind of guidance is wider than Washington.
My read: token theft has quietly become one of the most reliable ways into a modern cloud tenant, and this report is Washington acknowledging that passwords and multi-factor prompts aren't the only credentials worth guarding. Watch whether agency assessors start citing it in reviews next year.
Common questions
What is a token, in plain English?
It's a short signed digital pass a service hands your device after you log in, so other apps can trust you without asking for the password again.
Does this apply to private companies?
Not directly. The report targets federal agencies and their cloud providers, but the architectural advice is useful for any organisation running single sign-on or APIs across multiple clouds.



