CNSA 2.0 VPN timeline: when must VPNs go quantum-safe?

The CNSA 2.0 VPN timeline is the schedule the National Security Agency (NSA) set for VPNs, routers and other traditional networking equipment in US National Security Systems. That equipment must support and prefer quantum-resistant algorithms by 2026 and use them exclusively by 2030. Both dates sit inside a wider migration that is meant to finish by 2035.

Many OT and critical infrastructure operators are not formally bound by CNSA 2.0. For them, the schedule still works as a practical benchmark: it shows how quickly site-to-site tunnels, edge-to-cloud links and remote access gateways are expected to move away from RSA and elliptic curve key exchange. This article covers the dates, what the wording means, the required algorithms and how it all lines up with NIST IR 8547.

When must VPNs and network equipment support CNSA 2.0 algorithms?

Traditional networking equipment, which the NSA describes as VPNs and routers, must support and prefer CNSA 2.0 algorithms by 2026. It must use them exclusively by 2030. NSA CNSA 2.0 was announced in September 2022, and each category of equipment has its own two-stage deadline.

Independent analysts summarise the staging the same way: by 2025, NSS use of software/firmware signing and TLS for web, cloud services must employ quantum-resistant algorithms, and by 2026 the mandate extends to traditional network equipment. The categories in the original NSA advisory look like this:

Networking equipment has one of the shortest windows between “prefer” and “exclusive”, only four years. The reason is that tunnels carry bulk traffic that can be recorded today and decrypted once a cryptographically relevant quantum computer exists. The ceiling over all of these dates is National Security Memorandum 10, which sets a goal of mitigating as much of the quantum risk as is feasible by 2035. NSA expects the transition to QR algorithms for NSS to be complete by 2035 in line with NSM-10.

What does “support and prefer” by 2026 mean for networking equipment?

“Support and prefer” means the device can negotiate CNSA 2.0 algorithms and chooses them whenever the peer can too. Quantum-vulnerable algorithms are still allowed as a fallback until the “exclusively use” date.

The NSA-authored protocol profiles show what “prefer” means in practice. The CNSA 2.0 profile for TLS 1.3 states that CNSA-compliant implementations MUST present CNSA compliant algorithms first in the appropriate extensions, and CNSA-compliant algorithms MUST be used when supported by the peer. It also says that compliant clients and servers MUST be configured such that CNSA compliance is preferred even if it is not intended or expected.

For a VPN gateway, this leads to three concrete checks:

• Negotiation order: the post-quantum key exchange is proposed first, not just available.
• Default configuration: preference is on by default and does not depend on an administrator remembering to change a setting.
• Visibility of fallback: any session that drops to classical-only key exchange can be seen and logged, so the 2030 cutover can be planned against real data.

Which algorithms and parameter sets does CNSA 2.0 require for key establishment?

CNSA 2.0 requires ML-KEM-1024, specified in FIPS 203, for key establishment. It pairs that with ML-DSA-87 for signatures, AES-256 for encryption and SHA-384 or SHA-512 for hashing.

According to the NSA-authored IETF profiles, ML-DSA-87 and ML-KEM-1024 together with SHA384, SHA512, AES-256, LMS, and XMSS comprise the CNSA Suite 2.0. LMS and XMSS are limited to software and firmware signing.

• FIPS 203 publication: On August 13, 2024, NIST approved three PQC standards-FIPS 203, FIPS 204, and FIPS 205 (source: CISA, 2024).
• Security level: ML-KEM-1024 sits at NIST post-quantum security level 5, comparable to exhaustive key recovery on AES-256 (source: IETF RFC 9958, 2025).

The parameter set matters. FIPS 203 defines ML-KEM-512, ML-KEM-768 and ML-KEM-1024, and only the largest one meets CNSA 2.0. Many commercial hybrid deployments default to ML-KEM-768. That is a reasonable choice for general use, but it does not meet the NSS requirement.

How CNSA 2.0 maps onto IPsec

The NSA’s draft IPsec profile, draft-guthrie-cnsa2-ipsec-profile, applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It requires IKEv2 and ESP. ML-KEM-1024 keys are large, so the profile uses RFC 9370 multiple key exchanges, and a subsequent key establishment algorithm can be performed in the IKE_INTERMEDIATE exchange [RFC9242], which precedes IKE_AUTH. This avoids IP fragmentation problems. Such problems are common on OT links with small MTUs, such as cellular backhaul or legacy WAN circuits.

Gateways that are not built on IPsec, for example Layer 3 encryption gateways with their own handshake, follow the same pattern: a classical key exchange combined with ML-KEM into one session key. Quantum Network’s QPN gateway is one example of this hybrid design. It combines a classical exchange with ML-KEM from FIPS 203 and renews both handshakes every two minutes. If you are subject to CNSA 2.0, check the exact ML-KEM parameter set, the symmetric cipher and the signature algorithm against the NSA profile for every product, whatever the architecture.

Does CNSA 2.0 apply to critical infrastructure suppliers and contractors?

CNSA 2.0 is binding on National Security Systems, and that includes systems run by contractors on behalf of the government. Most privately operated critical infrastructure is not an NSS, so for those operators CNSA 2.0 is guidance rather than a legal requirement.

The authority comes from CNSSP 15, the Committee on National Security Systems policy on public standards for secure information sharing. The Director of NSA serves as the National Manager for US National Security Systems, giving NSA the authority to set requirements for cryptography across this area. The NSA’s own conference material notes that the NSS category covers more than classified office networks and includes Industrial control systems owned by Department of Defense.

For suppliers, the updated NSA FAQ is the key document: it clarifies Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requirements for National Security Systems (NSS) and recommended guidance for the Department of War (DoW) and the Defense Industrial Base (DIB). In practice, an energy, water or telecom operator that hosts or connects to defence systems under contract can inherit CNSA 2.0 obligations for those specific connections.

Outside NSS, the direction from government is still clear. NSA and CISA have long told OT owners to encrypt network traffic preferably using NIAP-validated VPN products and/or CNSSP- or NIST-approved algorithms when supported by OT system components. CISA also works with Sector Risk Management Agencies (SRMA) to assist critical infrastructure owners and operators in developing PQC migration planning.

How do CNSA 2.0 deadlines line up with NIST IR 8547 deprecating RSA and ECC?

NIST IR 8547 proposes deprecating 112-bit RSA and ECC after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035. CNSA 2.0 sets 2030 as the date for exclusive post-quantum use in networking equipment, so for VPNs the two schedules point to the same year.

On November 12, 2024, NIST published NIST IR 8547 (Initial Public Draft). Its proposal, as summarised by NIST: 112-bit security strength - deprecated after 2030, disallowed after 2035; 128-bit and higher security strength - disallowed after 2035 (source: NIST, 2024).

NIST is more lenient during the transition. As NIST’s Dustin Moody put it, “Organizations may continue using public key algorithms at the 112 bit security level as they migrate to post-quantum cryptography.” Hybrid designs get some relief too. According to an IETF analysis of the draft, the NIST IR 8547 note on hybrid modes says the disallowment of quantum-vulnerable algorithms after 2035 was not intended to apply to hybrid modes that incorporate an approved PQC algorithm alongside a quantum-vulnerable algorithm.

What should OT and critical infrastructure operators plan for now?

Start with the connections whose data will still be sensitive after 2030, and design changes so they don’t touch OT endpoints that can’t be upgraded. The cryptographic cutover for VPNs falls inside the service life of equipment being bought today.

Cost is one reason to start early. The US government estimates a $7.1 billion transition cost for non-National Security Systems alone (source: LaMacchia, Campagna and Gropp, CRA Quadrennial Paper, 2025). Industrial operators with long asset lifecycles face the same pressure in proportion. NSA’s Rob Joyce described post-quantum cryptography as proactively developing and building capabilities to secure critical information and systems, and for OT networks that means separating cryptographic upgrades from controller upgrades.

Practical sequencing

• Inventory by link, not by device. List every site-to-site tunnel, edge-to-cloud path and remote access entry point, with its key exchange, parameter set and data lifetime. PLCs and RTUs often cannot run new cryptography, but the link they sit behind can be protected.
• Classify by retention horizon. Engineering files, grid topology and process recipes that stay sensitive for a decade should move first. Short-lived telemetry can follow.
• Write parameter sets into procurement. For any contract that touches NSS, name ML-KEM-1024, AES-256 and ML-DSA-87 explicitly. For other links, require crypto agility so a parameter set can change without replacing hardware.
• Test MTU and latency on real OT paths. Post-quantum handshakes are larger, so validate fragmentation behaviour on cellular, satellite and serial-over-IP links before 2030.
• Use gateways to protect legacy endpoints. Putting a quantum-safe gateway at each end of a link protects traffic from equipment that will never get a firmware update. Quantum Network’s QPN, for example, encrypts at Layer 3 without installing software on the equipment behind it, and it supports air-gapped and public-internet site connections. Check whatever gateway you choose against the algorithm requirements that apply to your contracts.