Government & Defense PQC
CNSA 2.0 and its dated mandates, National Security Systems and CSfC, Federal PKI and the draft post-quantum certificate profile, and the procurement rules that push all of it down the supply chain.
Why this matters: Government is the one sector where post-quantum migration is already binding rather than advisory — CNSA 2.0 is required for new National Security System acquisitions from 1 January 2027, and vendors selling into that market inherit the deadline whether or not they have planned for it.
Start here: Pick a system class in the Federal Mandate Explorer — National Security System, federal civilian, or a nonfederal system handling CUI — and see which instruments bind it and whether any of them has a dated deadline.
For your role
- Executive / Business Leader
- CNSA 2.0 is required for new National Security System acquisitions from 1 January 2027; the CNSA 1.0 to 2.0 comparator and the Federal Mandate Explorer say which instruments bind a system you sell into or run.
- Researcher / Academic
- The suite comparator maps every public-key purpose line by line, and the Federal PKI Profile Pair puts the classical Common Policy profile beside the draft PQC certificate profile.
The Commercial National Security Algorithm Suite is the algorithm list National Security Systems are required to use. CNSA 1.0 is the classical suite carried in CNSSP 15 Annex B; CNSA 2.0 replaces every public-key line in it. Reading the two side by side is the clearest illustration of crypto agility available in a real standard — the symmetric rows barely move, and the asymmetric rows are replaced wholesale.
| Purpose | CNSA 1.0 | CNSA 2.0 |
|---|---|---|
| Software & firmware signing | RSA-3072 / ECDSA P-384 | LMS or XMSS (NIST SP 800-208) |
| Key establishment | ECDH P-384 / RSA-3072 | ML-KEM-1024 (FIPS 203) |
| Digital signatures (general use) | ECDSA P-384 / RSA-3072 | ML-DSA-87 (FIPS 204) |
| Symmetric encryption | AES-256 | AES-256 |
| Hashing | SHA-384 | SHA-384 or SHA-512 |
Software & firmware signing: NSA moved this use case first, for three stated reasons: NIST had already standardised the algorithms, the use case is more urgent than others, and stateful hash-based signatures have the longest cryptanalytic history — their performance costs matter least here. NSA recommends Leighton-Micali with SHA-256/192, though all SP 800-208 algorithms are approved.
Key establishment: Level-5 parameters only. CNSA 2.0 does not offer the lower ML-KEM parameter sets that FIPS 203 defines — an NSS-specific narrowing of the standard.
Digital signatures (general use): Again level-5 only. ML-DSA-44 and ML-DSA-65 are FIPS-approved but not CNSA 2.0-approved.
Symmetric encryption: Unchanged. Grover gives at most a quadratic speed-up, so a 256-bit key retains a 128-bit security margin. The advisory describes this section as only a modest change from CNSA 1.0, allowing a little more flexibility.
Hashing: Symmetric primitives survive the transition. This is the part of the estate that does not need replacing — worth knowing before budgeting to replace it.
Same requirement, two vocabularies
The 2022 advisory names CRYSTALS-Kyber and CRYSTALS-Dilithium. The December 2024 FAQ names ML-KEM-1024 and ML-DSA-87 for the same algorithms. The advisory predates FIPS 203/204 final. Both documents remain current and in force; only the naming changed.
This matters operationally: an estate search for “Kyber” will not find anything written after standardisation, and a search for “ML-KEM” will not find anything written before it. Inventory tooling has to know both.
Hybrids: not required, not forbidden
NSA "has confidence in CNSA 2.0 algorithms and will not require NSS developers to use hybrid certified products for security purposes." That is a decision not to *require* hybrids — not a prohibition. The FAQ explicitly allows that "product availability and interoperability requirements may lead to adopting hybrid solutions," and acknowledges that some protocols may need hybrid-like constructions simply to carry the larger ML-KEM-1024 and ML-DSA-87 objects.
NSA’s stated objections, which are worth knowing because most of the commercial world has taken the opposite default — see Hybrid Cryptography:
- Added protocol and library complexity: extra negotiation, extra error handling, modified APIs, more testing.
- Interoperability gets harder, not easier — every party must share both the component algorithms and the hybridisation method.
- It buys a second transition later, when classical components are eventually dropped.
- More security products fail from implementation flaws than from cryptanalysis, so added complexity is itself a risk.
Check off all sections and mark this reading done.
Related modules
- 5G SecuritySame track · Industries · Same migration phase · Shares ML-KEM, ML-DSA, X.509
- Automotive PQCSame track · Industries · Same migration phase · Shares ML-DSA, ML-KEM, NSM-10
- Compliance & Regulatory StrategyShares ML-DSA, ML-KEM, EO 14306
- PQC Governance & PolicyShares ML-DSA, ML-KEM, OMB M-23-02
In the Industry Landscape
Check your understanding
5 questions on Government & Defense PQC, each with its answer and the reason.
Take the quizNext step
Produce the artifact: MTI NegotiatorThis module belongs to phase 5 (Pilots & Migration); MTI Negotiator produces a deliverable of that phase in the Command Center.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.