Enforce Post-Quantum Key Exchange Policy Configuration Drift

Enforcing a post-quantum key exchange policy means making sure every VPN and TLS endpoint refuses any key exchange that lacks a post-quantum part such as ML-KEM, and checking all the time that this stays true. Configuration drift is the slow gap between that policy and what endpoints really negotiate. It is caused by defaults, updates, restored backups and one-off exceptions.

For organizations running OT and critical infrastructure, this gap is hard to see. A gateway can show ML-KEM as “enabled” in its management interface while it still completes classical-only handshakes with any peer that never offers anything better. This article explains how to close that gap for site-to-site, edge-to-cloud and remote-access connections.

How do I make sure every gateway refuses classical-only key exchange once ML-KEM is enabled?

Enabling ML-KEM only adds an option. To enforce it, you have to remove every classical-only option from the set the gateway will accept, and then prove that a classical-only peer gets rejected.

The algorithm is mature enough to make this a policy decision rather than an experiment. FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard, has been final since 08/13/2024. What usually breaks enforcement is how negotiation works, not the algorithm.

TLS 1.3 endpoints

In TLS 1.3 the client sends key shares for one or more groups, and the server picks a group from its own allowed list. If that list contains both a hybrid group (for example X25519MLKEM768) and a plain classical group (for example X25519), the server will accept a classical-only client. That is correct behaviour, not a bug. Putting the hybrid group first only sets a preference. For enforcement, the allowed list on policy-bound listeners must contain hybrid groups only.

IKEv2 VPN gateways

IPsec gateways that add ML-KEM through the additional key exchange mechanism of RFC 9370 have their own trap. An additional key exchange transform can be proposed together with “NONE” as an acceptable value, which makes the post-quantum exchange optional. A responder whose proposal accepts NONE will set up a tunnel without ML-KEM if the initiator asks for it. Your policy should say that the post-quantum transform is mandatory, with no NONE alternative, on every proposal that applies to a protected path.

Prove it with negative tests

Only a failed handshake confirms the policy. For each endpoint, run a probe that offers classical groups or transforms only and expect the connection to be rejected. Then run a probe that offers a hybrid group without a matching key share, and confirm that the server asks for a retry and does not quietly settle for something weaker.

How can default group or proposal lists make a server negotiate a weaker key exchange than configured?

Default lists are maintained by the software vendor, not by you. They can include classical groups, change between releases, and behave differently from an explicit list even when they look the same on paper.

CVE-2026-2673 shows this clearly. It affects a widely used open-source TLS library: a TLS 1.3 server may fail to negotiate the expected preferred key exchange group when its key exchange group configuration includes the default by using the ‘DEFAULT’ keyword. In practical terms, the NIST National Vulnerability Database warns that “a less preferred key exchange may be used even when a more preferred group is supported” by both sides.

The mechanism matters for anyone writing policy. When administrators used the keyword to pull in the built-in list and then added or removed entries, the ‘DEFAULT’ list lost its ‘tuple’ structure, all server-supported groups were treated as a single sufficiently secure ‘tuple’, and the server did not send a Hello Retry Request. As a result, a hybrid group such as X25519MLKEM768 could be skipped if the client’s configuration results in only ‘classical’ groups being in the client’s initial keyshare prediction.

• CVE-2026-2673 scope (NVD, 2026-03-13): the 3.6 and 3.5 branches are vulnerable, while 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected.

How do I detect configuration drift in cryptographic settings across hundreds of VPN and TLS endpoints?

You detect drift by comparing three things: the policy as written, the configuration as deployed, and the key exchange actually negotiated on the wire. Most drift only shows up in the third.

Some practical points that make this work at scale:

• Normalise before hashing. Expand keywords and aliases into concrete group and transform identifiers, so two endpoints with the same effective policy produce the same hash.
• Log the negotiated group per session. One classical-only session on a policy-bound path is an incident to investigate, not a statistic.
• Re-check after every lifecycle event. Firmware updates, library upgrades and configuration restores are the most common points where drift comes back.
• Cover air-gapped sites. Where central collection is impossible, run the same probe set locally during maintenance visits and bring the results back for comparison.

NIST frames this as a governance task. Its crypto agility white paper defines agility in a protocol as “the ability to maintain interoperability when introducing new cryptographic algorithms and preventing the use of vulnerable algorithms”. CSWP 39 was withdrawn on June 29, 2026 and superseded by CSWP 39upd1, so cite the updated version in internal policy documents.

Should a classical fallback be allowed during the transition to hybrid ML-KEM, and for how long?

Only as a registered, time-limited exception for a named peer that cannot do ML-KEM yet, never as a general default. Every exception needs an owner, a reason, a compensating control and an expiry date earlier than the regulatory milestones below.

Hybrid key exchange already keeps a classical component, so classical security is preserved without a separate classical-only fallback. A fallback adds another negotiation path that has to be tested and monitored. NIST notes that “hybrid schemes increase protocol complexity”, and each extra path widens the area where drift can hide.

The deadlines that should limit any fallback window:

• NIST IR 8547 (final, 2026-10-27): NIST will deprecate all quantum-vulnerable cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.
• Executive Order 14412 (NIST, October 2026): requires federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures.

The last row reflects a pattern NIST describes for legacy systems: a “crypto gateway” or “bump-in-the-wire” architecture to address risks posed by vulnerable or disallowed cryptography.

How do I roll out an algorithm policy change in stages without cutting off OT sites?

Roll out in rings, from lab to IT-facing paths to OT sites. Run every ring in observe mode first, and only switch to enforcement when logs show zero classical-only sessions. Always keep a tested rollback that does not depend on the connection you are changing.

A ring model that respects OT constraints

1. Lab replica. Test the exact production configurations, including expanded default lists, against every peer type you run.
2. Observe mode in production. Add hybrid groups and transforms but keep the current set allowed. Log the negotiated group for every session for at least one full operational cycle, including month-end batches and backup jobs.
3. Enforce on IT and cloud paths. Remove classical-only options where logs show every peer already negotiates hybrid.
4. Enforce on OT sites, one at a time, inside agreed maintenance windows, with out-of-band access (local console or a separate management path) in case the tunnel does not come back.

OT changes often go through integrators. IEC 62443-2-4 covers security program requirements for IACS service providers, which makes it a useful reference when you write contract terms saying that integrators must not restore classical-only proposals during maintenance and must report crypto configuration changes.

Reduce the number of endpoints that need changing

Every PLC, historian or engineering workstation that negotiates its own key exchange is one more place for drift. Ending protected links on a small number of dedicated gateways shrinks the inventory you have to verify. Quantum Network’s QPN gateway follows this model: it encrypts at Layer 3 with a hybrid key agreement that combines a classical part and ML-KEM (FIPS 203) into one session key, both handshakes renew every two minutes, and no software is installed on the equipment behind it. Changing policy then means updating a few gateways instead of hundreds of devices.