NIST CSWP 39 cryptographic agility for VPNs and OT

NIST CSWP 39 cryptographic agility means being able to swap the cryptographic algorithms in your VPNs, encryption gateways and remote-access clients without rebuilding the network or stopping operations. If you run OT or critical infrastructure, that capability decides whether the move to post-quantum cryptography is a planned configuration change or a rushed hardware project.

This article explains what the NIST white paper recommends and how to turn it into a policy for site-to-site, edge-to-cloud and remote-access encryption. It also covers who should own algorithm changes, how to test a switch safely, and how all of this lines up with the NIST IR 8547 timeline.

What is NIST CSWP 39 and what does it recommend?

NIST CSWP 39, “Considerations for Achieving Crypto Agility: Strategies and Practices,” is a NIST Cybersecurity White Paper that defines crypto agility and sets out practical approaches for protocols, systems and organizations. It is guidance, not a mandate.

NIST defines crypto agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. The final version was released December 19, 2025, after two public drafts and a workshop. An updated edition, NIST CSWP 39-upd1, includes updates as of 06-29-2026, so check that you are citing the current version in internal documents.

Recommendations that matter for network encryption

• Use protocols with algorithm identifiers. Crypto agility is easier to achieve when security protocols include algorithm or cipher suite identifiers. A gateway that negotiates its key exchange explicitly can be reconfigured. One with a fixed, hard-coded scheme cannot.
• Plan for larger keys and ciphertexts. The white paper warns that designers need to plan, as part of their crypto agility efforts, for public keys, signatures, and key-encapsulation ciphertext to be much larger than those currently used. On OT links with small MTUs or legacy routers, this is where post-quantum handshakes tend to fail first.
• Expect hardware limits. It is easier to provide multiple cryptographic algorithms to facilitate agility in library and application software than in hardware. Once a chip leaves the factory, additional algorithms may not be easily added to the chip.
• Govern cryptography as a program. The paper recommends that organizations integrate crypto agility into the organization’s existing governance function to establish, communicate, and monitor the cybersecurity risk management strategy, expectations, and policies related to cryptography.

The NIST authors also name the core operational difficulty. According to Elaine Barker, Lily Chen and their co-authors, one of the hardest parts of crypto agility is “replacing vulnerable algorithms in a timely manner and at the same time keeping the system running without interruption.” In OT, where availability usually comes first, that sentence sums up the problem.

How do you build a crypto-agility policy for VPNs and encryption gateways?

A crypto-agility policy for network encryption is a short, enforceable document. It lists which algorithms are allowed on each type of connection, how they get changed, and what triggers a change. It should cover every tunnel between sites, every edge-to-cloud path and every remote-access client.

CSWP 39 ties this to enforcement: for security protocols, a cryptographic security policy can be enforced by specifying mandatory-to-implement algorithms and disallowing the use of weak algorithms in a timely fashion. For gateways, that means the policy has to map to settings you can actually push and check.

Elements of a workable gateway crypto policy

1. Connection inventory. List every encrypted path: site to site, site to cloud, remote users. For each, record the key exchange, the bulk cipher, the rekey interval, the software version and whether the path crosses the public internet. The NIST NCCoE Migration to Post-Quantum Cryptography project was set up for this kind of discovery work. In its initial phase, collaborators worked with the NCCoE to demonstrate automated discovery tools that identify instances of quantum-vulnerable public-key algorithm use.
2. Approved algorithm sets per tier. Define an “approved,” a “transitional” and a “disallowed” set, using the same vocabulary as NIST SP 800-131A. For key establishment, the transitional set will usually be a hybrid of a classical and a post-quantum algorithm such as ML-KEM (FIPS 203).
3. Change triggers. Write down what forces a change: a NIST deprecation date, a published cryptanalysis result, a vendor advisory or an internal audit finding. Set a target response time for each one.
4. Update path, including air-gapped sites. Say how algorithm and software updates reach every gateway, including sites that have no internet connection.
5. Fail-safe behavior. Require that a failed negotiation never drops to unencrypted traffic. Encrypted tunnels in OT should fail closed, then retry.
6. Compensating controls. Some endpoints cannot be upgraded. For those, CSWP 39 suggests organizations implement compensating security controls as part of a zero-trust approach if the assets are not agile enough to support the cryptographic policy. A common example is wrapping a legacy link inside a post-quantum tunnel between gateways.

Who should own algorithm changes in OT and IT network encryption?

Algorithm changes need one accountable owner and several consulted parties. In practice, a central cryptography governance role sets the policy, while the OT asset owner decides when and where changes happen on production links.

IEC 62443-2-1 is a good fit for this split. IEC 62443-2-1:2024 specifies asset owner security program policy and procedure requirements for an industrial automation and control system (IACS) in operation, and in the context of this document, asset owner also includes the operator of the IACS. It also states that the asset owner needs to have policies and procedures around these types of requirements. So cryptographic change control belongs inside the OT security program, not alongside it.

The usual failure is ownership that falls between teams. IT assumes OT will schedule the change, and OT assumes the change is “just a firmware update.” Put the gateway crypto policy in the same change-management process that already governs safety-relevant OT changes.

How can you test an algorithm switch without disrupting OT operations?

Test the switch in stages: a lab replica first, then one non-critical production link, then the rest. At each stage, measure against acceptance criteria that process engineers have agreed in advance. Every stage needs a documented rollback.

A staged test sequence

1. Lab replica. Reproduce the real path, including the MTU, any NAT, the firewall placement and the WAN type. Larger post-quantum handshake messages can fragment, so test with the same intermediate devices you have in production.
2. Define measurable acceptance criteria. Agree on maximum added latency, jitter, rekey success rate and tunnel recovery time after a simulated line failure. For polling protocols, confirm that no control-loop timeouts fire.
3. Exercise rekeying under load. Short rekey intervals are where interoperability bugs show up. Run sustained traffic across several rekey cycles, not just a single handshake.
4. Pilot on a low-criticality link. Start with something like a historian replication path or an engineering-workstation remote-access tunnel, not a safety-instrumented system.
5. Roll out by maintenance window. Move site by site and keep the previous configuration staged for a fast revert.
6. Verify afterwards. Confirm on each gateway which algorithm is actually negotiated and record it in the inventory. CSWP 39 notes that implementations should provide a way to tell when deployed systems have moved from the old algorithm to the new one.

The gateway design affects how much testing you need. In Quantum Network’s Quantum Gateway, for example, key agreement is hybrid (a classical part and ML-KEM combined into one session key), both handshakes renew every two minutes, and the connection never falls back to unencrypted traffic. Because it encrypts at Layer 3, nothing is installed on the OT equipment behind it, so testing stays at the network layer.

How does crypto-agility support the NIST IR 8547 transition timeline?

NIST IR 8547 sets dates after which quantum-vulnerable public-key algorithms are deprecated and then disallowed. Crypto agility is what lets you meet those dates through planned configuration changes instead of emergency replacements.

NIST IR 8547 identifies quantum-vulnerable algorithms (RSA, (EC) Diffie-Hellman, MQV, ECDSA, EdDSA) and post-quantum standards (ML-KEM, ML-DSA, SLH-DSA, LMS, XMSS). The proposed dates are:

As NIST summarized it, 112-bit security strength would be deprecated after 2030 and disallowed after 2035. National Security Memorandum 10 establishes the year 2035 as the primary target for completing the migration to PQC across Federal systems, with the White House stating the goal of “mitigating as much of the quantum risk as is feasible by 2035.” NIST SP 800-131A is being revised in parallel. The Rev. 3 draft discusses the transition from a security strength of 112 bits to a 128-bit security strength and to quantum-resistant algorithms for digital signatures and key establishment.

Why OT should start earlier than the dates suggest

Two factors push OT timelines forward. The first is asset lifespan: IEC 62443-2-1 recognizes that the lifespan of an IACS can exceed twenty years, and that many legacy systems contain hardware and software that are no longer supported. Network equipment bought today may still be running in 2035. The second is data exposure. Traffic recorded today could be decrypted later, so links carrying long-lived sensitive data need post-quantum key establishment well before the disallow date.

Crypto agility turns the IR 8547 dates into a sequence you can manage:

• Now: run hybrid key establishment on internet-facing site-to-site and remote-access links. NIST IR 8547 describes combining a classical algorithm and a PQC algorithm into a composite mechanism and states that such hybrid approaches may be used in the initial transition to PQC.
• Before 2030: move the classical-only algorithms on the remaining links to “transitional” in your policy, and make sure every gateway can negotiate post-quantum key exchange.
• Before 2035: remove disallowed algorithms from all configurations, using the same tested change process.

On subscription-based gateways, check that the update path stays active over the whole period. With QPN, for example, the post-quantum algorithm can be changed if necessary, but automatic algorithm and software updates require an active subscription. Physical gateways are leased together with the subscription and returned at the end of the contract. Whatever product you use, record the supplier’s update commitments as an explicit dependency in your crypto policy.