In September 2022, NSA's Cybersecurity Directorate published the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) – a directive requiring that all National Security Systems transition from classical public-key cryptography to post-quantum algorithms on a defined schedule. For defense organizations, this is not a research question or a future planning item: procurement requirements are already incorporating CNSA 2.0 readiness criteria, and new systems deployed from 2025 onward are expected to support the mandated algorithms from day one.

The migration challenge is substantial. Classical public-key cryptography – RSA, Elliptic Curve Cryptography (ECC), and Diffie-Hellman – is embedded throughout defense IT infrastructure: TLS endpoints, VPN gateways, PKI certificate authorities, key management systems, firmware signing pipelines, and encrypted data archives. Replacing these dependencies in a large organization is a multi-year programme requiring careful sequencing, vendor coordination, and risk management during the period when classical and post-quantum systems must interoperate.

This article lays out a practical migration roadmap: what CNSA 2.0 requires, which algorithms replace which, how to sequence the transition across a defense organization, and what to demand from vendors supplying CNSA 2.0-capable systems.

What CNSA 2.0 requires and why

The cryptographic threat driving CNSA 2.0 is Shor's algorithm – a quantum algorithm that, when run on a sufficiently large quantum computer, breaks the mathematical problems underlying RSA (integer factorization), ECC (elliptic curve discrete logarithm), and Diffie-Hellman (discrete logarithm). A quantum computer capable of running Shor's algorithm against 2048-bit RSA or 256-bit ECC would require millions of logical qubits operating with low error rates. That capability does not exist today, but credible public estimates place a "cryptographically relevant quantum computer" (CRQC) somewhere in the 2030–2035 window.

The "harvest now, decrypt later" (HNDL) threat collapses this timeline for defense purposes. Adversaries collecting encrypted traffic today – strategic communications, intelligence reporting, capability assessments – can store it and decrypt it once a CRQC becomes available. The secrecy of data encrypted today with classical algorithms therefore has an effective expiration date correlated with CRQC availability. For data with secrecy requirements measured in decades, that expiration is already a present operational concern.

CNSA 2.0 addresses this by mandating a specific set of post-quantum algorithms for NSS, with a transition timeline designed to ensure migration completes before CRQC availability. The key mandates:

  • ML-KEM (FIPS 203 / CRYSTALS-Kyber) – replaces RSA and ECDH for all key establishment. CNSA 2.0 mandates ML-KEM-1024 (the highest security parameter set) for NSS applications.
  • ML-DSA (FIPS 204 / CRYSTALS-Dilithium) – replaces RSA-PSS and ECDSA for digital signatures in most applications. Provides fast signing and verification with reasonable key and signature sizes.
  • SLH-DSA (FIPS 205 / SPHINCS+) – an alternative signature algorithm based on hash functions rather than lattice mathematics. Used where diversity from lattice-based algorithms is required, or where lattice-based algorithms are not permitted. Signatures are significantly larger than ML-DSA but security is based on well-understood hash function properties.
  • LMS and XMSS – stateful hash-based signature schemes approved for specific use cases, particularly firmware signing in constrained environments. Require careful state management to avoid key reuse.
  • AES-256 and SHA-384 – retained from CNSA 1.0 for symmetric encryption and hashing; these are not threatened by quantum computers at practical scale.

Deprecated algorithms that must be phased out under CNSA 2.0 include: RSA (all key sizes, all applications), ECDH and ECDSA (all curves), Diffie-Hellman (classical and elliptic curve), and SHA-256 for NSS applications (where SHA-384 is now mandated). AES-128 and AES-192 are also deprecated in favor of AES-256 for NSS.

Key insight: Many defense IT teams focus on the 2030 deadline for migrating existing systems and overlook the 2025 requirement for new systems. A software product or platform delivered to a DoD customer after January 2025 is expected to support CNSA 2.0 algorithms. Products built on classical-only cryptographic libraries will fail CNSA 2.0 compliance assessments at the point of delivery, not at the point of quantum threat materialization.

Approved algorithms in detail

ML-KEM (Module-Lattice Key Encapsulation Mechanism) is based on the hardness of the Module Learning With Errors (MLWE) problem – a lattice problem that no known quantum or classical algorithm solves efficiently. ML-KEM operates as a key encapsulation mechanism: the sender encapsulates a shared secret under the recipient's public key; the recipient decapsulates to recover the shared secret. The shared secret then seeds a symmetric key derivation function. ML-KEM-1024 produces public keys of 1,568 bytes, ciphertexts of 1,568 bytes, and shared secrets of 32 bytes – larger than RSA-2048 keys (256 bytes) but acceptable for most protocol contexts.

ML-DSA (Module-Lattice Digital Signature Algorithm) is based on the hardness of the Module Short Integer Solution (MSIS) and MLWE problems. ML-DSA-87 (the highest security level, corresponding to AES-256 security) produces public keys of 2,592 bytes and signatures of 4,627 bytes. By comparison, ECDSA P-256 produces 64-byte signatures. The larger signature sizes require adjustment in protocols and storage systems that assumed compact signatures – certificate chains, firmware images, and bandwidth-constrained links need capacity planning.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) has no algebraic structure exploitable by either classical or quantum algorithms beyond generic hash function attacks; its security reduces entirely to collision resistance of the underlying hash function. The trade-off is performance and size: SLH-DSA-SHA2-256s signatures are 29,792 bytes at the lowest parameter set, and signing is orders of magnitude slower than ML-DSA. SLH-DSA is appropriate as a secondary signature algorithm to provide security diversity, particularly for firmware and software signing where signature size and signing frequency are manageable.

The four migration phases

A well-structured CNSA 2.0 migration proceeds through four phases. Organizations may be in different phases simultaneously across different system types – a large defense organization will typically have PKI migration in Phase 2 while tactical edge systems are still in Phase 1.

Phase 1 – Cryptographic Inventory. Before any migration work can be planned, the organization must know what it has. Cryptographic inventory encompasses: every TLS endpoint and its negotiated cipher suites; every certificate in use (user, device, service, code signing) and its key algorithm and expiry; every VPN gateway and its IKEv2 key exchange configuration; every key management system, HSM, and cryptographic token; every firmware signing pipeline and its signing key type; and every data archive where long-term confidentiality is required and the encryption key algorithm.

Automated tools help – TLS scanners (SSLyze, testssl.sh), SBOM analysis for cryptographic library dependencies, and certificate management platforms with algorithm reporting. But automated tools miss custom protocol implementations, embedded firmware crypto, and application-layer cryptography outside standard libraries. Manual review of architecture documentation and source code is required for completeness.

Phase 2 – Risk-Based Prioritization. Not all cryptographic dependencies carry equal HNDL risk. Prioritization should reflect two dimensions: the longevity and sensitivity of protected data, and the feasibility of near-term migration. High-priority targets are systems protecting long-lived classified data where HNDL exposure is highest: PKI root and issuing CAs (whose keys protect the trust anchor for the entire organization), key management infrastructure (HSMs holding master keys for encrypted archives), strategic communications links, and any system encrypting data with a secrecy requirement exceeding five years.

Lower priority – but still required before 2030 – are systems with frequent hardware refresh cycles (tactical platforms, end-user devices) where PQC capability can be incorporated at the next natural refresh, and internal systems protecting non-classified data where quantum risk is lower.

Phase 3 – Hybrid Operation. During migration, systems will interoperate with both CNSA 1.0 (classical) and CNSA 2.0 (post-quantum) counterparts. Hybrid cryptography – combining classical and post-quantum algorithms in the same protocol exchange – provides quantum resistance on current traffic without requiring all endpoints to simultaneously support post-quantum algorithms.

In a hybrid TLS 1.3 connection, the client includes both an ECDHE key share and an ML-KEM key share in the ClientHello; the server responds with both. The final session key is derived from both shared secrets using a key derivation function. An adversary must break both the classical and post-quantum algorithms to compromise the session. This "belt and suspenders" approach is explicitly endorsed by NSA for the transition period.

Key insight: Hybrid operation is not just a transitional convenience – it is a risk management discipline. Until post-quantum algorithms accumulate years of cryptanalytic scrutiny comparable to RSA and ECC, running them alongside classical algorithms ensures that an unforeseen cryptanalytic advance against lattice-based mathematics does not immediately compromise all protected communications.

Phase 4 – Full Transition. Once all systems support post-quantum algorithms and hybrid operation has been proven stable in production, classical-only cipher suites and certificate types are retired. Deprecation must be coordinated with all interoperating organizations, vendors, and partner nations. Establish monitoring to detect any residual classical-algorithm negotiation (which would indicate a system that was missed in inventory or that a vendor has not yet delivered CNSA 2.0-capable software), and track deprecation milestones against the 2030 deadline.

High-priority systems and migration sequencing

Within the prioritized migration backlog, certain system types appear consistently as high-priority across virtually all defense organizations and should be sequenced early regardless of organizational specifics.

Key management infrastructure. HSMs and key management services (KMSes) are dependencies for the migration of almost every other system – post-quantum keys must be generated, stored, and managed somewhere. Upgrading HSM firmware to support ML-KEM and ML-DSA operations, and verifying that key management APIs expose post-quantum key types to consuming applications, is Phase 1–2 work in every migration programme. This is also where vendor engagement is most critical: HSM vendors vary significantly in their PQC roadmaps, and some hardware generations cannot be upgraded in place.

PKI root and issuing CAs. The PKI trust hierarchy underpins certificate-based authentication throughout the organization. Establishing post-quantum root CAs – and distributing their trust anchors to all relying parties (browsers, operating systems, TLS clients, OCSP validators) – is a prerequisite for issuing post-quantum certificates to any system. This must happen before post-quantum certificates can be deployed elsewhere. A dual-issuance model, where the same CA issues both classical and post-quantum certificates for each subject, allows gradual relying-party migration without breaking existing trust relationships.

VPN gateways and encrypted communications platforms. VPN gateways protecting classified network perimeters are primary HNDL targets. IKEv2, the key exchange protocol used in most enterprise VPN solutions, must be updated to negotiate ML-KEM for key establishment and ML-DSA for authentication. Most enterprise VPN vendors (Cisco, Palo Alto, Juniper, Check Point) have PQC roadmap items, but feature availability and CNSA 2.0 parameter compliance vary significantly – this is a critical vendor-qualification question in procurement.

Encrypted communications and messaging platforms. Systems used for strategic command communications, intelligence dissemination, and mission-critical coordination are high-priority targets because the sensitivity and longevity of traffic is high. Corvus.Quantum, Corvus Intelligence's streaming platform for defense, is designed for CNSA 2.0 alignment – incorporating ML-KEM for key establishment and ML-DSA for message signing in its streaming and messaging architecture, supporting hybrid operation during the transition period.

Firmware signing pipelines. Weapons systems and military hardware platforms use digital signatures to verify firmware integrity. These signatures are long-lived – the signing key may cover the entire production life of a platform, spanning a decade or more – and are therefore directly exposed to HNDL risk. New platforms entering production should ship with ML-DSA or SLH-DSA firmware signing from first delivery. In-service platforms require a re-signing campaign for firmware images where the boot architecture supports key rotation; platforms where signing keys are fused at manufacture require explicit risk documentation.

Key insight: Firmware signing key rotation is often architecturally impossible for fielded platforms without hardware replacement. The appropriate response is not to defer the problem but to document it explicitly in the platform's risk register, assign a residual risk owner, and build a hardware refresh schedule that closes the gap. Undocumented cryptographic technical debt is the most dangerous kind.

How to inventory cryptographic dependencies

Cryptographic inventory is consistently the most underestimated phase of PQC migration programs. Organizations that begin migration assuming inventory will take weeks typically discover it requires months, because cryptography is deployed across more system layers and more code paths than any single team has full visibility into.

A comprehensive inventory strategy combines four approaches. First, network-layer discovery: passive TLS traffic analysis and active scanning of all reachable endpoints using tools that fingerprint negotiated cipher suites and certificate key algorithms. This captures web servers, API endpoints, load balancers, and service-mesh communications that use standard TLS. Second, certificate management platform enumeration: querying the organization's CA hierarchy and any public CT (Certificate Transparency) logs for certificates bearing the organization's names, extracting key algorithm and expiry for each. Third, SBOM analysis: extracting Software Bill of Materials from deployed applications and scanning for cryptographic library dependencies (OpenSSL, BoringSSL, libgcrypt, NSS, Java crypto providers) and their versions. Cryptographic library versions determine which algorithms are available and which are the defaults. Fourth, architecture documentation review: identifying custom protocol implementations, in-process key derivation, encrypted database columns, and application-layer cryptography that network scanning cannot observe.

The output of inventory should be a structured register with at minimum: system name, cryptographic dependency type (TLS, certificate, KEM, signature, symmetric), algorithm and key size, library or implementation, data classification of protected data, and estimated migration complexity. This register drives Phase 2 prioritization and provides the baseline for tracking compliance progress.

Vendor questions during procurement

Defense organizations procuring commercial-off-the-shelf software and hardware must evaluate CNSA 2.0 readiness as part of procurement. The following questions distinguish vendors with genuine PQC capability from those with roadmap promises:

Algorithm support specifics. "Does your product support ML-KEM-1024, ML-DSA-87, and SLH-DSA-SHA2-256s as defined in FIPS 203, 204, and 205?" Vendors who respond with generic "post-quantum support" claims without specific FIPS designations and parameter levels are unlikely to meet CNSA 2.0's specific requirements. Algorithm support at lower parameter levels (ML-KEM-512, ML-DSA-44) does not satisfy CNSA 2.0's mandated security levels for NSS.

Hybrid cipher suite availability. "Does your TLS implementation support hybrid ML-KEM + ECDHE key exchange in a single handshake?" Hybrid support enables the organization to start benefiting from quantum resistance on existing traffic without requiring all interoperating parties to complete PQC migration simultaneously.

Key size accommodation. "How does your system handle the larger key and signature sizes of post-quantum algorithms?" ML-DSA-87 signatures are approximately 4.6 KB versus ECDSA P-256's 64 bytes. Systems with fixed-size certificate or signature buffers, database schemas with fixed cryptographic field lengths, or network protocols with strict MTU assumptions may require architectural changes to accommodate PQC key material.

Cryptographic library provenance. "Which cryptographic library underlies your PQC implementation, and what is the version update cadence?" Post-quantum implementations in OpenSSL, BoringSSL, and Bouncy Castle are still maturing; the vendor's update cadence determines how quickly security patches reach deployed products.

Post-2030 roadmap. "What is your plan for pure-PQC operation after 2030 when hybrid mode and classical algorithms are deprecated?" Vendors without a concrete post-2030 roadmap represent a compliance risk that will require managed transitions at the worst possible time – when the deadline is imminent.

Six-step CNSA 2.0 migration planning process

The following steps distill the migration phases above into an actionable planning sequence for defense IT and security teams starting a CNSA 2.0 compliance programme.

Step 1 – Conduct a cryptographic inventory. Deploy TLS scanning, certificate management reporting, SBOM analysis, and architecture documentation review across all systems. Produce a structured register of every cryptographic dependency: type, algorithm, key size, library, data classification, and estimated migration complexity. Expect this step to take 2–6 months for a medium-to-large defense organization. Do not proceed to planning without a reasonably complete inventory – migration plans built on partial inventory will miss high-priority systems.

Step 2 – Assess risk and prioritize systems. Score each inventory item on two axes: HNDL risk (sensitivity and longevity of protected data) and migration feasibility (team capability, vendor readiness, architectural complexity). Produce a prioritized migration backlog with estimated effort, dependencies between items, and owner assignment. Items protecting long-lived classified data with low migration complexity should be at the top regardless of organizational politics.

Step 3 – Upgrade key management and PKI infrastructure first. Migrate HSMs to CNSA 2.0-capable firmware. Issue post-quantum root CA certificates. Establish dual-issuance capability. Distribute updated trust anchors to relying parties. This phase is a dependency for all subsequent certificate-based migrations and should be resourced and started immediately after inventory completion.

Step 4 – Deploy hybrid cipher suites on high-priority network paths. Enable ML-KEM hybrid cipher suites on VPN gateways, classified network perimeters, and communications platforms. This step provides immediate HNDL risk reduction on current traffic without requiring full PQC readiness across all endpoints. Monitor negotiation rates to track adoption.

Step 5 – Migrate firmware signing and software supply chain. Transition firmware signing pipelines to ML-DSA or SLH-DSA keys for all platforms entering production. Conduct re-signing campaigns for in-service platforms where architecturally feasible. Update CI/CD code-signing pipelines. Document constrained platforms as managed cryptographic technical debt with explicit risk acceptance.

Step 6 – Execute full transition and deprecate classical algorithms. Once all high-priority systems support post-quantum algorithms and hybrid operation is stable, begin retiring classical cipher suites and certificate types on a coordinated schedule with interoperating organizations. Establish a compliance dashboard. Target full classical algorithm deprecation by 2030 in line with NSA guidance.

For deeper coverage of the underlying post-quantum algorithms and their defence implications, see Post-Quantum Cryptography for Defense: CNSA 2.0 Guide. For the key management and secrets infrastructure that underpins PQC migration, see Secrets Management in Defense CI/CD Pipelines: Vault, HSM, and Key Rotation. For zero-trust architecture as a complementary security layer, see Zero-Trust Architecture for Military Networks: Principles and Implementation.