CNSA 2.0 and the federal timeline

CNSA 2.0 is the NSA's algorithm suite for US national security systems in the post-quantum era. It is short, specific and unusually blunt about dates, which is why it has escaped its own jurisdiction and become the reference list in procurement questionnaires worldwide. If you sell software to anyone who sells to the US government, you will be asked about it.

#What CNSA 2.0 is

The Commercial National Security Algorithm Suite is the NSA's published list of commercial cryptographic algorithms approved for protecting classified and other national security information. Version 2.0 was announced in 2022 and replaces the elliptic-curve and RSA-based selections of CNSA 1.0 with post-quantum ones, alongside symmetric and hash algorithms that were already approved.

It is guidance to system owners and vendors rather than a statute. In practice it acquires force through the authorisation process: a national security system is accredited against it, and a supplier who cannot meet it is not in the running. Two US instruments sit behind it and are worth knowing by name. National Security Memorandum 10, issued in 2022, directed the migration of national security systems to quantum-resistant cryptography. The Quantum Computing Cybersecurity Preparedness Act, enacted in December 2022, put inventory and migration obligations on federal civilian agencies.

#The algorithm list

The suite is deliberately narrow. There is one selection per purpose, and where a parameter choice exists, the suite takes the strongest one.

What is absent matters as much as what is present. RSA, ECDSA, ECDH and finite-field Diffie-Hellman are not in the suite. Neither is any hybrid construction that keeps a classical exchange as a required component; hybrid deployment is a transition tactic here, not an end state. Note also that SLH-DSA (FIPS 205) is not the selection for software and firmware signing in this suite, even though it is the more operationally forgiving hash-based scheme. [PLACEHOLDER: whether SLH-DSA is now accepted in that role, confirmed against the current NSA guidance]

The choice of category-5 parameters throughout is the single most consequential line for anyone planning capacity. ML-DSA-87 signatures are 4,627 bytes and ML-KEM-1024 ciphertexts are 1,568 bytes, so a CNSA 2.0 handshake is the expensive end of the range described in FIPS 203, 204 and 205, mapped to output.

#Who it binds

CNSA 2.0 applies to US national security systems and to the products and services supplied into them. That is a narrower category than federal IT generally, and it is defined by statute and policy rather than by whether an agency happens to be involved.

• Directly bound. Operators of national security systems, and the components inside them.
• Bound by contract. Vendors whose product is a component of such a system. The requirement typically arrives as a clause and a delivery date, not as a regulation you can read in advance.
• Bound indirectly. Suppliers to those vendors. This is where most commercial software companies first encounter it, usually through a customer's supplier questionnaire.
• Not bound. Federal civilian systems that are not national security systems. Those follow NIST guidance and OMB direction instead, on a related but separate schedule.

If you are not sure which category you are in, the honest answer is that we cannot tell you. Scope determinations for national security systems are made by the authorising officials responsible for those systems.

#The published timeline, and how to cite it

The suite publishes two dates per category of system: the year by which a product should support and prefer CNSA 2.0 algorithms, and the year by which it should use them exclusively. The schedule below reflects the milestones we are confident are published. Where we are not confident, we have said so rather than guessed, because a wrong date in a compliance filing is worse than a blank one.

#Why this matters outside the United States

Theos Quantum is an Indian company and most of the estates we assess have no US federal exposure at all. CNSA 2.0 still shapes those engagements, for four reasons that have nothing to do with jurisdiction.

• Supply-chain pull-through. A requirement that binds one party propagates down the chain as contract language. A European bank has no CNSA 2.0 obligation; the hardware security module vendor it depends on may well have one, and its roadmap moves accordingly.
• Procurement questionnaires. CNSA 2.0 has become the default question because it is answerable. Alignment with a named algorithm list and a named parameter set produces a yes or a no. Broad resilience language does not.
• A de facto benchmark. It is the most specific published parameter guidance in existence. Boards ask about it because the answer is checkable, and security teams use it as a planning ceiling even where nothing compels them to.
• A useful performance upper bound. Designing to category-5 parameters means the numbers you measure are the worst case. If the estate absorbs ML-DSA-87, it will absorb anything lighter.

The counter-argument is worth stating too. Adopting category-5 parameters everywhere because a federal suite selects them is over-engineering if none of your systems are in scope, and it costs real latency. The decision should follow from your own data-lifetime arithmetic, which is set out in The migration window, with the arithmetic.

#How AutoPQC handles a CNSA 2.0 requirement

We treat CNSA 2.0 as a policy overlay on the inventory rather than as a separate scan. The inventory is the same; the question asked of each asset changes.

Input

The cryptographic inventory produced by discovery, as described in How discovery finds cryptography

Test applied

Whether each asset's algorithm and parameter set is on the CNSA 2.0 list, and if it is post-quantum, whether it meets the category-5 parameterisation

Output

A subset of the exposure report listing assets outside the suite, each with the named replacement and the sequencing dependency it introduces

What changes in sequencing

Signing and firmware paths move earlier, because the published exclusive-use dates for those categories are the nearest ones. See Sequencing a migration

What we record

The method version and the date of the suite revision the overlay was built against, so the finding stays interpretable later