Short answer: from 1 January 2027, CNSA 2.0 algorithms “will be required in all new products and services that provide cryptographic protection for users or for updates” in US National Security Systems (NSS). That is the rule in Committee on National Security Systems Policy 15 (CNSSP 15). Equipment that cannot be updated to CNSA 2.0 must be replaced by 31 December 2030, and CNSA 2.0 is mandatory for all protocol use by 31 December 2031. The rule allows exceptions and waivers, and the NSA’s own FAQ describes a route for buying products that will be updated later.
The NSA published version 2.2 of its CNSA 2.0 FAQ in October 2026. This post sets out what the policy and the FAQ actually say, which algorithms and parameter sets count, where common summaries go wrong, and what a supplier to the US national security market should be able to show before the date arrives.
What CNSA 2.0 is
The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is, in the NSA’s words, “the suite of QR algorithms approved for NSS use”, where QR means quantum-resistant. The NSA announced it in September 2022. CNSSP 15 made it policy: the current version, dated December 2024, was signed on 28 February 2025, and the NSA describes it as released on 4 March 2025. It replaces CNSA 1.0, which relied on RSA, Diffie-Hellman and elliptic curve cryptography.
| Function | Algorithm | Required parameters |
|---|---|---|
| Symmetric encryption | AES (FIPS 197) | 256-bit keys |
| Key establishment | ML-KEM (FIPS 203) | ML-KEM-1024 |
| Digital signatures | ML-DSA (FIPS 204) | ML-DSA-87 |
| Hashing | SHA-2 (FIPS 180-4) | SHA-384 or SHA-512 |
| Software and firmware signing | LMS and XMSS (NIST SP 800-208) | All parameters; LMS with SHA-256/192 recommended |
| Internal hardware integrity only | SHA-3 (FIPS 202) | SHA3-384 or SHA3-512, for example in boot-up integrity checks |
The parameter sets matter as much as the algorithm names. For ML-KEM and ML-DSA, CNSA 2.0 specifies the largest parameter set in each NIST standard. An estate that has adopted ML-KEM-768 or ML-DSA-65 has adopted NIST post-quantum cryptography, but not CNSA 2.0.
Who it applies to
CNSA 2.0 is a requirement for National Security Systems, not for the wider economy. The FAQ says it plainly: “NSA does not mandate requirements on any other entity outside of NSS.” The FAQ is written for NSS owners and operators, and for vendors who need to know what to implement. It also recommends guidance for the Department of War and the Defense Industrial Base, and notes that the requirements may be used more widely where interoperability with NSS matters.
Federal civilian systems follow a different track. Executive Order 14412 and OMB M-26-15 set their dates, which we covered in our posts on the US federal mandate and the 22 October agency plans. The FAQ confirms that the order’s timelines “apply to non-NSS systems” and “do not change CNSS Policy 15 and its timeline for NSS transition to CNSA 2.0”.
The dates that are actually in the policy
Paragraph 18 of CNSSP 15 sets three dates. Each applies unless an exception is published (on nsa.gov, in a protection profile or in a capability package) or a waiver is granted:
- 1 January 2027: CNSA 2.0 algorithms are required in all new products and services that provide cryptographic protection for users or for updates.
- 31 December 2030: equipment and services that cannot or will not be updated “must be phased out and replaced with equipment or services which support CNSA 2.0 algorithms by 31 December 2030”.
- 31 December 2031: “CNSA 2.0 algorithms are mandated for all protocol use by 31 December 2031”.
Behind those dates sits National Security Memorandum 10 (NSM-10), whose goal is quantum resistance by 2035. The FAQ says the NSA “intends that all NSS will be quantum-resistant well ahead of the 2035 goal”. CNSSP 15 also states: “All Exceptions and waivers to the previous version of CNSS Policy No. 15 are hereby cancelled.” Systems that relied on an old waiver had to come into compliance or apply again.
The 2022 timetable, and why it is not the rule
Many summaries of CNSA 2.0 lead with a table of dates by equipment type. It comes from the NSA’s original September 2022 advisory, which said the NSA “anticipates the following timetable”:
- Software and firmware signing: support and prefer CNSA 2.0 by 2025, and use it exclusively by 2030.
- Web browsers, servers and cloud services: support and prefer by 2025, and use exclusively by 2033.
- Traditional networking equipment such as VPNs and routers: support and prefer by 2026, and use exclusively by 2030.
- Operating systems: support and prefer by 2027, and use exclusively by 2033.
- Niche equipment such as constrained devices and large PKI systems: support and prefer by 2030, and use exclusively by 2033.
- Custom applications and legacy equipment: update or replace by 2033.
That advisory predates the NIST standards: it lists CRYSTALS-Kyber and CRYSTALS-Dilithium with the specification “TBD”. The binding dates are now the three in CNSSP 15, and the October 2026 FAQ restates those three rather than the 2022 table. The 2022 categories are still a useful guide to which technologies the NSA expected to move first, but a compliance plan should be built on 2027, 2030 and 2031.
Five common misreadings
1. Misreading: Products that are not compliant on 1 January 2027 cannot be bought. The FAQ addresses this directly. Where fully certified products are not available, “a deployment may be accepted based on a contractual commitment by a vendor to provide a CNSA 2.0 update when combined with a realistic deployment plan prioritizing partial QR that meets the 2030 deadline for full QR.” It adds that this must be tracked and reported, and that some components, “like firmware update options, likely cannot be transitioned after purchase”. The route exists, but it is narrow, and the NSA urges buyers to make sure firmware update options are quantum-resistant at the time of purchase.
2. Misreading: Hybrid post-quantum means compliant. It does not. The FAQ says NSS are only compliant “when using CNSA 2.0 algorithms in an NSA-approved manner” and that “something marketed as hybrid or composite does not necessarily make it quantum resistant.” The widely deployed TLS hybrid key exchange X25519MLKEM768 uses ML-KEM-768, not the ML-KEM-1024 that CNSA 2.0 requires. The NSA approves hybrids only in specific cases, such as its IKEv2 profile.
3. Misreading: Any NIST post-quantum standard will do. CNSA 2.0 is narrower than NIST’s list. The FAQ states that SLH-DSA “is not part of CNSA and is not approved for any use in NSS”, that the multi-tree schemes HSS and XMSSMT “are not allowed”, and that the pre-hash variant HashML-DSA is not allowed “at the present time”. It also says the NSA “does not anticipate adding FN-DSA to CNSA 2.0”.
4. Misreading: FIPS validation is enough. For NSS, commercial products generally also need National Information Assurance Partnership (NIAP) validation under CNSSP 11. The FAQ says that in 2027 NIAP “will no longer accept products for certification that have not started their quantum transition”. NIAP will archive certificates for partially quantum-resistant and quantum-vulnerable products, and the NSA expects that archiving “to start in late 2027”.
5. Misreading: Executive Order 14412 changed the NSS dates. It did not. The FAQ says NSS “will transition according to the schedule established in CNSS Policies, which is at least as fast as the EO.”
Roots of trust and firmware come first
The NSA is firmest about code that cannot easily be changed later. The FAQ says: “Starting in 2027, no new product for NSS should have a burned-in root of trust relying on a non-QR primitive.” Firmware validation algorithms are often fixed for the life of a device, which is why the NSA allowed LMS and XMSS for software and firmware signing before ML-DSA was widely available.
For PKI, the NSA advises against composite certificates: NSS “should not use novel mechanisms to support multiple algorithms within a single certificate.” The FAQ instead describes “standing up a parallel PKI using the new cryptographic algorithm”, with some devices holding credentials from both chains until the transition completes. Our post on NIST IR 8547 covers the draft civilian timetable NIST has proposed for retiring RSA and elliptic curve algorithms.
What a supplier should be able to show
For a vendor selling into US national security programmes, directly or through a prime contractor, the 1 January 2027 date turns into questions about specific products. Each one is answered from an inventory that records algorithms and parameter sets, not only protocol names:
- Key establishment: where ML-KEM is used, and whether it is ML-KEM-1024 or a smaller parameter set.
- Signatures: where ML-DSA is used and at which parameter set, and where RSA or ECDSA signatures remain.
- Firmware and software signing: which algorithm signs updates and which verifies them on the device, and whether that verification can be changed after shipment.
- Symmetric and hash choices: whether AES-256 and SHA-384 or SHA-512 are used throughout, and where SHA-3 appears outside internal hardware integrity checks.
- Hybrids: which hybrid constructions are negotiated and whether they include CNSA 2.0 parameter sets.
- Validation status: which modules hold FIPS 140 validation and which products hold or are seeking NIAP certification against updated protection profiles.
For UK organisations, CNSA 2.0 is not a domestic requirement. UK defence suppliers that sell into US programmes will meet it through contracts and certification. At home, the NCSC migration timeline expects discovery and an initial plan by 2028 and migration complete by 2035.
How this maps to the ECEM lifecycle
Enterprise Cryptographic Exposure Management (ECEM) describes post-quantum readiness as a continuous six-stage lifecycle: Discover, Inventory, Assess, Prioritise, Transition, Monitor. CNSA 2.0 raises the bar at the Assess stage. Finding post-quantum algorithms is not enough: each one has to be assessed against a specific approved list and parameter set. Prioritise is shaped by the policy itself, with firmware signing and roots of trust first. Monitor matters because the transition runs to 2031, with products negotiating a mix of CNSA 1.0 and CNSA 2.0 along the way.
Where Quantum Sentinel fits
- CNSA 2.0 as a separate claim. Findings distinguish NIST standardisation (FIPS 203, 204 and 205) from inclusion in CNSA 2.0, because those are different claims.
- Post-quantum and hybrid in use. Hybrid key exchange such as X25519MLKEM768 is reported by name and identified as hybrid rather than counted as either half. Post-quantum algorithms recognised include ML-KEM, ML-DSA, SLH-DSA, FN-DSA, HQC, LMS and XMSS.
- Libraries that gate migration. Cryptographic libraries on endpoints are reported with their versions and checked for whether they can perform ML-KEM and ML-DSA today.
- A record to share. Findings land in an Enterprise CBOM exported as CycloneDX 1.7, with reports in PDF, Word, Excel and CSV.
Quantum Sentinel does not perform NIAP evaluation or FIPS validation, and it does not certify CNSA 2.0 compliance. It supplies the inventory evidence that those processes and a vendor’s own compliance statement depend on. The cryptographic coverage page lists what is covered.
Frequently asked questions
What is the CNSA 2.0 deadline for 2027?
Under CNSSP 15, from 1 January 2027 CNSA 2.0 algorithms are required in all new products and services that provide cryptographic protection for users or for updates in US National Security Systems, unless an exception is published or a waiver is granted. Equipment that cannot be updated must be replaced by 31 December 2030, and CNSA 2.0 is mandatory for all protocol use by 31 December 2031.
Which algorithms are in CNSA 2.0?
AES with 256-bit keys, ML-KEM-1024 for key establishment, ML-DSA-87 for signatures and SHA-384 or SHA-512 for hashing. LMS and XMSS are allowed for software and firmware signing, and SHA3-384 or SHA3-512 only for internal hardware integrity checks. SLH-DSA, HSS and XMSS-MT are not approved.
Is X25519MLKEM768 CNSA 2.0 compliant?
No. X25519MLKEM768 uses ML-KEM-768, while CNSA 2.0 requires ML-KEM-1024 for key establishment. The NSA’s FAQ also states that something marketed as hybrid or composite does not necessarily make it quantum resistant, and that NSS are compliant only when CNSA 2.0 algorithms are used in an NSA-approved manner.
Does CNSA 2.0 apply to UK companies?
Not directly. The NSA states that it does not mandate requirements on any entity outside US National Security Systems. UK suppliers whose products are used in those systems, directly or through US prime contractors, will meet CNSA 2.0 through contracts and NIAP certification. UK organisations follow the NCSC’s own timeline, which expects migration to be complete by 2035.
Sources: Committee on National Security Systems, CNSSP 15, Use of Public Standards for Secure Information Sharing (December 2024, signed 28 February 2025); NSA, Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ (version 2.2, October 2026); NSA, Announcing the Commercial National Security Algorithm Suite 2.0 (September 2022); NSA, Post-Quantum Cybersecurity Resources.
Further reading: OMB M-26-15 and EO 14412: what the US mandate means for suppliers, three annotated CBOM examples in CycloneDX JSON and why post-quantum deadlines are really inventory deadlines.