CNSA 2.0 is the National Security Agency's Commercial National Security Algorithm Suite 2.0 — the algorithms that US National Security Systems must use, and the timeline for adopting them.
If you sell to, or operate, a national security system, this is the mandate that binds. If you do not, it still matters as the clearest signal of direction that any government has published.
Required algorithms
| Purpose | Algorithm | |---|---| | Key establishment | ML-KEM-1024 (FIPS 203) | | Digital signatures | ML-DSA-87 (FIPS 204) | | Symmetric encryption | AES-256 | | Hashing | SHA-384 or SHA-512 |
Note the parameter sizes. CNSA 2.0 requires ML-KEM-1024, while the web has converged on ML-KEM-768 via the hybrid group X25519MLKEM768. Deploying what browsers negotiate by default does not make you CNSA 2.0 compliant.
Timeline
The transition is phased by system class, with most deadlines falling between 2030 and 2033:
- Software and firmware signing — exclusive use by 2030
- Traditional networking equipment — by 2030
- Web browsers, servers, and cloud services — support and prefer by 2025, exclusive use by 2033
- Operating systems — by 2033
"Support and prefer by 2025" for web servers has already passed. A server negotiating classical key exchange by default is behind that marker now.
What this means practically
CNSA 2.0 is a requirement to use post-quantum algorithms, not merely to support them. The distinction matters: a server with a hybrid group enabled but not preferred satisfies neither the spirit nor eventually the letter.
Because the suite specifies pure post-quantum algorithms at the top parameter sizes, an organisation in scope generally needs a deliberate plan rather than an incidental upgrade that arrives with a library bump.
Getting an inventory first
Every one of these deadlines assumes you know what cryptography you are running. In practice most organisations do not, particularly across externally facing services that accumulated over a decade. That inventory — a CBOM — is the prerequisite for any of the rest.