Post-quantum cryptography migration:
CNSA 2.0, OMB M-23-02 and the NIST FIPS 203/204/205 standards explained.
Three US mandates now drive the move off quantum-vulnerable cryptography. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, Sept 2022) names the approved algorithms for National Security Systems. OMB M-23-02 (Nov 18, 2022) orders every federal civilian agency to inventory its active cryptography and report quantum-vulnerable use to ONCD and CISA. NIST finalized the underlying algorithm standards on Aug 13, 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA).
This page explains what each document requires, the migration deadlines that matter (software signing exclusively CNSA 2.0 by 2030, NSS by 2033, new acquisitions CNSA 2.0 by Jan 1, 2027), and how to build the cryptographic inventory those mandates depend on.
A "harvest now, decrypt later" threat with hard federal deadlines already on the clock.
A cryptographically relevant quantum computer would break RSA, Diffie-Hellman and elliptic-curve cryptography. Adversaries do not have to wait for that machine. Encrypted traffic captured today can be stored and decrypted later, which is why migration timelines start now rather than when quantum hardware arrives.
CNSA 2.0 sets the destination for National Security Systems: ML-KEM-1024 for key establishment, ML-DSA-87 for general signatures, and the stateful hash-based schemes LMS and XMSS for software and firmware signing (per NIST SP 800-208), alongside AES-256 and SHA-384 or stronger. The NSA wants software and firmware signing on CNSA 2.0 exclusively by 2030, broad NSS migration by 2030, full exclusivity by 2033, and new NSS acquisitions to support CNSA 2.0 by January 1, 2027.
OMB M-23-02 makes the first step concrete for civilian agencies: you cannot migrate what you cannot see. Agencies must inventory active cryptographic systems, prioritize High Value Assets, report quantum-vulnerable algorithms to ONCD and CISA, and estimate migration cost. That inventory is the foundation of every later step, and it is exactly where most organizations have the least visibility.
Find it before attackers do. Catch it if they try. Fix it fast.
Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.
Test like an AI-assisted attacker
An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.
Detect and block exploitation at runtime
A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.
Auto-patch what is reachable
Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.
The clock by finding type
Indicative fix windows. Tightest where exposure and active exploitation meet.
How to build a cryptographic inventory for OMB M-23-02
M-23-02 is built around one deliverable: a prioritized inventory of cryptographic systems, with High Value Assets and high-impact systems first. Agencies submitted their first inventory by May 4, 2023 and continue annually through 2035, reporting where quantum-vulnerable RSA, Diffie-Hellman and ECC are in use.
O3 generates a CBOM/QBOM in CycloneDX directly from source and dependencies, inventorying cryptographic assets and the libraries that implement them, which feeds the M-23-02 inventory and CNSA 2.0 planning. SCA and SBOM surface the crypto-library dependencies behind each finding.
How to map your stack to CNSA 2.0 approved algorithms
CNSA 2.0 specifies the algorithms that replace today's public-key cryptography for National Security Systems. Knowing the targets lets you plan substitutions rather than discovering them mid-migration.
How to sequence migration against the CNSA 2.0 timeline
The deadlines are staggered, so sequencing matters. Signing systems lead, broad NSS migration follows, and new acquisitions must support CNSA 2.0 well before exclusivity dates.
A continuously updated QBOM lets you watch quantum-vulnerable usage trend toward zero across the 2030 and 2033 milestones instead of relying on point-in-time audits.
How to design for crypto agility so the next transition is cheaper
Hard-coded algorithms are why this migration is painful. Crypto agility means cryptographic choices are configurable and discoverable, so future changes (including algorithm deprecations) do not require rewrites.
O3's source-level CBOM identifies where cryptographic primitives are called directly in code, helping locate the hard-coded usage that blocks crypto agility.
How to assess vendors and dependencies for PQC readiness
Much of your cryptography ships inside third-party libraries, products and services. M-23-02 and CNSA 2.0 only succeed if the supply chain moves too, which makes vendor visibility part of the inventory.
SCA and SBOM enumerate the open-source crypto libraries you depend on, and reading cosign/SLSA provenance supports assessment of the software signing chain that CNSA 2.0 targets first.
How to report quantum-vulnerable cryptography to ONCD and CISA
M-23-02 is not only an internal exercise. Agencies report quantum-vulnerable cryptography to the Office of the National Cyber Director and CISA, and submit prioritized inventories annually through 2035.
A CycloneDX CBOM/QBOM is exportable, machine-readable evidence of cryptographic assets and quantum-vulnerable usage, suitable for repeated annual reporting rather than manual spreadsheets.
Every mandate and algorithm across CNSA 2.0, OMB M-23-02 and the NIST FIPS standards.
All 20 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.
Build the cryptographic inventory your PQC migration depends on
M-23-02 and CNSA 2.0 both start with one question: where is your cryptography? O3 generates a CycloneDX CBOM and QBOM straight from your code and dependencies, inventorying cryptographic assets, flagging quantum-vulnerable usage, and giving you machine-readable evidence you can re-run every year. See how O3 maps your stack against the post-quantum deadlines.
Read the NSA CNSA 2.0 advisory- CNSA 2.0 is the NSA's Commercial National Security Algorithm Suite 2.0, issued in September 2022. It names the post-quantum algorithms approved for National Security Systems and their vendors, including ML-KEM-1024, ML-DSA-87, and LMS/XMSS for signing. It applies to NSS owners and the suppliers building products for them.
- Per the NSA timeline, software and firmware signing should be exclusively CNSA 2.0 by 2030, broad NSS migration is targeted for 2030, and full CNSA 2.0 exclusivity across NSS is expected by 2033. New NSS acquisitions must support CNSA 2.0 by January 1, 2027, so procurement starts early.
- M-23-02 (Nov 18, 2022) directs federal civilian agencies to inventory active cryptographic systems, prioritize High Value Assets, report quantum-vulnerable RSA, Diffie-Hellman and ECC to ONCD and CISA, and estimate migration cost within 30 days of the inventory. Inventories are submitted annually through 2035.
- They are the NIST post-quantum standards finalized August 13, 2024. FIPS 203 is ML-KEM for key establishment, FIPS 204 is ML-DSA for digital signatures, and FIPS 205 is SLH-DSA, a stateless hash-based signature scheme. CNSA 2.0 selects ML-KEM-1024 and ML-DSA-87 from these standards.
- A CBOM (cryptographic bill of materials) and QBOM inventory the cryptographic assets and quantum-vulnerable algorithms in a system, expressed in CycloneDX. Because M-23-02 requires a prioritized crypto inventory and CNSA 2.0 requires migration planning, a machine-readable CBOM/QBOM is the foundational artifact for both.
- Because of harvest-now-decrypt-later. Adversaries can capture encrypted data today and decrypt it once a cryptographically relevant quantum computer exists. Long-lived secrets are at risk immediately, which is why CNSA 2.0 and M-23-02 set deadlines that begin years before quantum hardware is expected.
- CNSA 2.0 specifies the stateful hash-based signature schemes LMS and XMSS for software and firmware signing, per NIST SP 800-208. These signing use cases lead the migration: CNSA 2.0 calls for software and firmware signing to be exclusively CNSA 2.0 by 2030.
- Start with discovery, since you cannot migrate what you cannot see. Build a cryptographic inventory across code, libraries, protocols, certificates and firmware, flag quantum-vulnerable RSA, DH and ECC, prioritize High Value Assets per M-23-02, then sequence replacements toward the CNSA 2.0 deadlines using NIST SP 1800-38 as practical guidance.
See O3 Security in Action
See why security and engineering leaders trust O3
to secure their entire software supply chain.