Cyber Strategy
Cyber Secure
Cyber Operations
Cyber Response
Cyber ResilienceThe Blind Spot: A TLS Roadmap Is Not a VPN Roadmap
Post-quantum cryptography has become visible through the browser. TLS was one of the first places where post-quantum key exchange became real enough for security teams to observe, test, and discuss. Browsers, content delivery networks, and large cloud providers made hybrid post-quantum TLS visible to the market, and as a result many early post-quantum roadmaps begin with websites, APIs, load balancers, and public-facing TLS endpoints.
A TLS post-quantum roadmap does not automatically cover VPN and IPsec readiness. VPN infrastructure has its own protocol behavior, owners, vendors, firmware cycles, negotiation rules, fallback decisions, operational failure modes, and migration constraints. And most of all, it is less visible.
- A site-to-site tunnel may sit quietly between a branch and a data center for years.
- A partner VPN may be owned by a network team but relied on by a business unit.
- A remote access gateway may be managed separately from the application stack it protects.
TLS and VPN/IPsec do not share the same operational model. TLS usually lives closer to application, platform, CDN, and web infrastructure teams, while IPsec lives closer to network, firewall, infrastructure, SD-WAN, SASE, and managed service teams. If the post-quantum roadmap stops at the browser, it may leave a major confidentiality path unassessed.
Why VPN/IPsec Is a Separate Problem
First, the traffic is different. Public TLS often protects user-to-application or application-to-API traffic. VPNs often protect internal, privileged, replicated, operational, or partner traffic. In many organizations those flows include regulated records, financial data, intellectual property, M&A material, backups, industrial data, identity infrastructure, and administrative access.
Second, the ownership is different. TLS migration may be driven by application security, platform engineering, cloud, or DevOps teams. VPN migration is often owned by network engineering, firewall teams, infrastructure operations, SASE administrators, or managed service providers. Those teams have different processes, tools, maintenance windows, and risk tolerances.
Third, the capability is firmware-gated. VPN post-quantum support is not something you enable in a software library. It depends on the exact firewall, router, gateway, client, operating system, firmware version, license model, and tunnel mode.
Fourth, the peer matters. A VPN is negotiated between two sides. Your side may be ready, but the peer—a partner, a branch device, a managed firewall, a cloud gateway, a SASE provider, a third-party router—may not be.
What Actually Changes Inside IPsec/IKEv2
For most VPN deployments, the immediate post-quantum concern is the public-key key establishment used during tunnel setup.
In a traditional IKEv2/IPsec tunnel, the peers negotiate key material during IKEv2 establishment. Historically that process has relied on classical mechanisms such as Diffie-Hellman or elliptic-curve Diffie-Hellman. Those are exactly the public-key mechanisms that a future cryptographically relevant quantum computer is expected to threaten.
The IPsec data plane may still use strong symmetric encryption such as AES. Symmetric cryptography has a different quantum risk profile from classical public-key key exchange. That does not mean the data plane should be ignored, VPN hygiene still matters, with pillars such as strong encryption, integrity protection, and Perfect Forward Secrecy, but the post-quantum migration issue begins with how the tunnel establishes its keys.
The emerging fix is hybrid key exchange. In simple terms, hybrid key exchange combines a strong classical exchange with a post-quantum key encapsulation mechanism such as ML-KEM. The goal is not to throw away the classical side immediately, but to mix classical and post-quantum contributions into the session key material so the session does not depend on a single cryptographic assumption. It is worth being precise here: a strong classical group such as DH Group 20 is still a classical mechanism, and remains quantum-vulnerable. It is the baseline that a post-quantum exchange is added to, not a substitute for one.
The IETF has developed the protocol rails for this:
- RFC 9370 extends IKEv2 to support multiple key exchanges during Security Association setup.
- RFC 9242 defines the IKEv2 Intermediate Exchange, which helps carry the larger material exchanged during establishment.
- RFC 8784 provides another approach by mixing post-quantum pre-shared keys into IKEv2. The newer IKEv2 ML-KEM work builds on this direction by defining how ML-KEM is used in the IKEv2/IPsec context.
A Common Pattern Is Emerging
Vendor implementations are not identical, and they should not be treated as interchangeable. Even so, a common pattern is emerging across the market:
- Move away from legacy IKE where possible.
- Standardize on IKEv2 for relevant tunnels.
- Baseline strong classical cryptography first.
- Add post-quantum key exchange, or post-quantum pre-shared key mechanisms.
- Treat firmware and product version as a hard dependency.
- Validate interoperability on exact peer combinations.
- Decide whether classical fallback is acceptable.
- Ensure negotiated behavior is logged and monitorable.
- Pilot before broad rollout.
The vendor-specific details still matter, but they should serve the framework rather than dominate it. The commonality is not a single button labeled “PQC.” It is a migration pattern: modernize the tunnel baseline, add hybrid or post-quantum key establishment, validate the peer, test the operational behavior, and document what remains classical-only.
Vendor Support Is Not the Same as Deployment Readiness
Vendor support is an important starting point, but production readiness requires validating a set of deployment-specific conditions in the actual environment.
Post-quantum key material is larger than traditional key exchange material. IKEv2 runs over UDP, and UDP paths may involve NAT, firewalls, middleboxes, fragmentation, MTU limits, and rate-limiting behavior. A configuration that works in a clean lab may not behave the same way across a real WAN, branch network, or partner path.
There is also an interoperability issue. Two vendors can both reference the same general standards family and still fail to negotiate if they implemented different draft revisions, algorithm identifiers, parameter sets, proposal orders, firmware behaviors, or fallback logic. Standards alignment must be validated at the exact implementation level.
The right posture is to validate the exact tunnel pair, proposal set, firmware version, and production-like network path before treating a configuration as ready. The questions that separate ?supported? from ?deployable? fall into four areas:
The Vendor-Neutral VPN PQC Workstream
A VPN/IPsec post-quantum workstream should be portable across environments. The following sequence holds regardless of which vendor sits at either end of the tunnel. The concept applies anywhere; the execution still lives in your vendor’s documentation.
- Inventory every VPN and tunnel type: For each tunnel, capture the owner, business purpose, connected systems, peer organization, vendor, device model, firmware, authentication method, IKE version, proposal set, DH group, encryption algorithm, integrity settings, logging status, and operational criticality. A VPN tunnel is a business path with cryptographic dependencies, not just a network object.
- Prioritize by harvest-now-decrypt-later relevance: HNDL risk is not evenly distributed. A short-lived session carrying low-value data is not the same as a tunnel carrying data that must stay confidential for years. Drive priority by confidentiality lifetime, exposure, business sensitivity, and migration feasibility. We covered this prioritization logic in detail in the previous article in this series. If long-lived sensitive data crosses a tunnel, that tunnel belongs in the PQC roadmap.
- Baseline classical VPN hygiene first: A broken VPN baseline does not become mature simply because a post-quantum option appears in a newer firmware release.
- move away from IKEv1 where possible
- standardize on IKEv2
- remove weak or legacy proposals
- use strong classical DH groups and symmetric encryption
- use SHA-2 family integrity
- keep firmware current
- confirm logging is enabled
- decommission unused tunnels.
4. Validate vendor support precisely: Replace “Are you quantum-safe?” with the specific questions. The answers determine whether the organization is ready to test, or only ready to track the roadmap.
5. Test before production: Validate the exact devices, software versions, proposal sets, and network paths that will run in production, and test the operational failure modes that distinguish VPN migration from TLS migration.
6. Define a fallback policy: Decide, per tunnel class, whether classical fallback is acceptable during transition, or whether high-risk tunnels should fail closed.
7. Pilot in stages: Validate in the lab first, then lower-risk tunnels, then high-value production connections. Where migration is not yet possible because of partner, hardware, firmware, or vendor constraints, document the exception and review it periodically.
Asking Vendors the Right Questions
Vendor validation should be specific. Do not ask, “Are you quantum-safe?” Ask:
- Which products support post-quantum IKEv2/IPsec, and which hardware models?
- Which firmware or operating system versions?
- Which tunnel types?
- Which ML-KEM parameter sets?
- Which RFCs or drafts are implemented (RFC 8784, RFC 9242, RFC 9370, draft-ietf-ipsecme-ikev2-mlkem)?
- Which peer vendors have been validated for interoperability?
- Is support generally available, beta, preview, or roadmap?
- Does it require a license or hardware acceleration?
- Can it be configured in both GUI and CLI?
- How is the negotiated key exchange logged?
- Can fallback be controlled, and can PQC-only or fail-closed behavior be enforced for high-risk tunnels?
- How is rekey handled, and what are the known limitations?
What to Test Before Production
Two kinds of testing matter here, and the second is what separates VPN migration from TLS migration.
First, confirm the negotiated behavior on the exact peer pair:
- Did the tunnel negotiate classical-only exchange, hybrid exchange, or post-quantum pre-shared key behavior?
- Was fallback used, and was it expected?
- Can the team see the negotiated key exchange in logs?
- Can monitoring detect a downgrade?
- Does rekey work, and does failover preserve the expected posture?
Second, test the operational failure modes. Post-quantum key exchange introduces larger payloads and different negotiation behavior, which makes network behavior part of the migration:
- UDP 500 and UDP 4500 reachability
- NAT traversal behavior
- IKE fragmentation
- Path MTU
- Packet loss
- HA failover
- Route convergence
- Gateway restart scenarios
- Mass tunnel re-establishment
- Logging behavior
The Blind Spot: A TLS Roadmap Is Not a VPN Roadmap
Post-quantum cryptography has become visible through the browser. TLS was one of the first places where post-quantum key exchange became real enough for security teams to observe, test, and discuss. Browsers, content delivery networks, and large cloud providers made hybrid post-quantum TLS visible to the market, and as a result many early post-quantum roadmaps begin with websites, APIs, load balancers, and public-facing TLS endpoints.
A TLS post-quantum roadmap does not automatically cover VPN and IPsec readiness. VPN infrastructure has its own protocol behavior, owners, vendors, firmware cycles, negotiation rules, fallback decisions, operational failure modes, and migration constraints. And most of all, it is less visible.
- A site-to-site tunnel may sit quietly between a branch and a data center for years.
- A partner VPN may be owned by a network team but relied on by a business unit.
- A remote access gateway may be managed separately from the application stack it protects.
TLS and VPN/IPsec do not share the same operational model. TLS usually lives closer to application, platform, CDN, and web infrastructure teams, while IPsec lives closer to network, firewall, infrastructure, SD-WAN, SASE, and managed service teams. If the post-quantum roadmap stops at the browser, it may leave a major confidentiality path unassessed.
Why VPN/IPsec Is a Separate Problem
First, the traffic is different. Public TLS often protects user-to-application or application-to-API traffic. VPNs often protect internal, privileged, replicated, operational, or partner traffic. In many organizations those flows include regulated records, financial data, intellectual property, M&A material, backups, industrial data, identity infrastructure, and administrative access.
Second, the ownership is different. TLS migration may be driven by application security, platform engineering, cloud, or DevOps teams. VPN migration is often owned by network engineering, firewall teams, infrastructure operations, SASE administrators, or managed service providers. Those teams have different processes, tools, maintenance windows, and risk tolerances.
Third, the capability is firmware-gated. VPN post-quantum support is not something you enable in a software library. It depends on the exact firewall, router, gateway, client, operating system, firmware version, license model, and tunnel mode.
Fourth, the peer matters. A VPN is negotiated between two sides. Your side may be ready, but the peer—a partner, a branch device, a managed firewall, a cloud gateway, a SASE provider, a third-party router—may not be.
What Actually Changes Inside IPsec/IKEv2
For most VPN deployments, the immediate post-quantum concern is the public-key key establishment used during tunnel setup.
In a traditional IKEv2/IPsec tunnel, the peers negotiate key material during IKEv2 establishment. Historically that process has relied on classical mechanisms such as Diffie-Hellman or elliptic-curve Diffie-Hellman. Those are exactly the public-key mechanisms that a future cryptographically relevant quantum computer is expected to threaten.
The IPsec data plane may still use strong symmetric encryption such as AES. Symmetric cryptography has a different quantum risk profile from classical public-key key exchange. That does not mean the data plane should be ignored, VPN hygiene still matters, with pillars such as strong encryption, integrity protection, and Perfect Forward Secrecy, but the post-quantum migration issue begins with how the tunnel establishes its keys.
The emerging fix is hybrid key exchange. In simple terms, hybrid key exchange combines a strong classical exchange with a post-quantum key encapsulation mechanism such as ML-KEM. The goal is not to throw away the classical side immediately, but to mix classical and post-quantum contributions into the session key material so the session does not depend on a single cryptographic assumption. It is worth being precise here: a strong classical group such as DH Group 20 is still a classical mechanism, and remains quantum-vulnerable. It is the baseline that a post-quantum exchange is added to, not a substitute for one.
The IETF has developed the protocol rails for this:
- RFC 9370 extends IKEv2 to support multiple key exchanges during Security Association setup.
- RFC 9242 defines the IKEv2 Intermediate Exchange, which helps carry the larger material exchanged during establishment.
- RFC 8784 provides another approach by mixing post-quantum pre-shared keys into IKEv2. The newer IKEv2 ML-KEM work builds on this direction by defining how ML-KEM is used in the IKEv2/IPsec context.
A Common Pattern Is Emerging
Vendor implementations are not identical, and they should not be treated as interchangeable. Even so, a common pattern is emerging across the market:
- Move away from legacy IKE where possible.
- Standardize on IKEv2 for relevant tunnels.
- Baseline strong classical cryptography first.
- Add post-quantum key exchange, or post-quantum pre-shared key mechanisms.
- Treat firmware and product version as a hard dependency.
- Validate interoperability on exact peer combinations.
- Decide whether classical fallback is acceptable.
- Ensure negotiated behavior is logged and monitorable.
- Pilot before broad rollout.
The vendor-specific details still matter, but they should serve the framework rather than dominate it. The commonality is not a single button labeled “PQC.” It is a migration pattern: modernize the tunnel baseline, add hybrid or post-quantum key establishment, validate the peer, test the operational behavior, and document what remains classical-only.
Vendor Support Is Not the Same as Deployment Readiness
Vendor support is an important starting point, but production readiness requires validating a set of deployment-specific conditions in the actual environment.
Post-quantum key material is larger than traditional key exchange material. IKEv2 runs over UDP, and UDP paths may involve NAT, firewalls, middleboxes, fragmentation, MTU limits, and rate-limiting behavior. A configuration that works in a clean lab may not behave the same way across a real WAN, branch network, or partner path.
There is also an interoperability issue. Two vendors can both reference the same general standards family and still fail to negotiate if they implemented different draft revisions, algorithm identifiers, parameter sets, proposal orders, firmware behaviors, or fallback logic. Standards alignment must be validated at the exact implementation level.
The right posture is to validate the exact tunnel pair, proposal set, firmware version, and production-like network path before treating a configuration as ready. The questions that separate ?supported? from ?deployable? fall into four areas:
The Vendor-Neutral VPN PQC Workstream
A VPN/IPsec post-quantum workstream should be portable across environments. The following sequence holds regardless of which vendor sits at either end of the tunnel. The concept applies anywhere; the execution still lives in your vendor’s documentation.
- Inventory every VPN and tunnel type: For each tunnel, capture the owner, business purpose, connected systems, peer organization, vendor, device model, firmware, authentication method, IKE version, proposal set, DH group, encryption algorithm, integrity settings, logging status, and operational criticality. A VPN tunnel is a business path with cryptographic dependencies, not just a network object.
- Prioritize by harvest-now-decrypt-later relevance: HNDL risk is not evenly distributed. A short-lived session carrying low-value data is not the same as a tunnel carrying data that must stay confidential for years. Drive priority by confidentiality lifetime, exposure, business sensitivity, and migration feasibility. We covered this prioritization logic in detail in the previous article in this series. If long-lived sensitive data crosses a tunnel, that tunnel belongs in the PQC roadmap.
- Baseline classical VPN hygiene first: A broken VPN baseline does not become mature simply because a post-quantum option appears in a newer firmware release.
- move away from IKEv1 where possible
- standardize on IKEv2
- remove weak or legacy proposals
- use strong classical DH groups and symmetric encryption
- use SHA-2 family integrity
- keep firmware current
- confirm logging is enabled
- decommission unused tunnels.
- Validate vendor support precisely: Replace “Are you quantum-safe?” with the specific questions. The answers determine whether the organization is ready to test, or only ready to track the roadmap.
- Test before production: Validate the exact devices, software versions, proposal sets, and network paths that will run in production, and test the operational failure modes that distinguish VPN migration from TLS migration.
- Define a fallback policy: Decide, per tunnel class, whether classical fallback is acceptable during transition, or whether high-risk tunnels should fail closed.
- Pilot in stages: Validate in the lab first, then lower-risk tunnels, then high-value production connections. Where migration is not yet possible because of partner, hardware, firmware, or vendor constraints, document the exception and review it periodically.
Asking Vendors the Right Questions
Vendor validation should be specific. Do not ask, “Are you quantum-safe?” Ask:
- Which products support post-quantum IKEv2/IPsec, and which hardware models?
- Which firmware or operating system versions?
- Which tunnel types?
- Which ML-KEM parameter sets?
- Which RFCs or drafts are implemented (RFC 8784, RFC 9242, RFC 9370, draft-ietf-ipsecme-ikev2-mlkem)?
- Which peer vendors have been validated for interoperability?
- Is support generally available, beta, preview, or roadmap?
- Does it require a license or hardware acceleration?
- Can it be configured in both GUI and CLI?
- How is the negotiated key exchange logged?
- Can fallback be controlled, and can PQC-only or fail-closed behavior be enforced for high-risk tunnels?
- How is rekey handled, and what are the known limitations?
What to Test Before Production
Two kinds of testing matter here, and the second is what separates VPN migration from TLS migration.
First, confirm the negotiated behavior on the exact peer pair:
- Did the tunnel negotiate classical-only exchange, hybrid exchange, or post-quantum pre-shared key behavior?
- Was fallback used, and was it expected?
- Can the team see the negotiated key exchange in logs?
- Can monitoring detect a downgrade?
- Does rekey work, and does failover preserve the expected posture?
Second, test the operational failure modes. Post-quantum key exchange introduces larger payloads and different negotiation behavior, which makes network behavior part of the migration:
- UDP 500 and UDP 4500 reachability
- NAT traversal behavior
- IKE fragmentation
- Path MTU
- Packet loss
- HA failover
- Route convergence
- Gateway restart scenarios
- Mass tunnel re-establishment
- Logging behavior
The Decision Every Organization Must Make
Regardless of vendor, every organization will eventually face the same decision: how should the tunnel behave when post-quantum negotiation is not available or does not succeed?
Hybrid key exchange is the preferred transition model because it combines a strong classical exchange with a post-quantum mechanism instead of forcing the organization to bet entirely on one side. That matters because classical public-key cryptography is the known quantum target, while post-quantum algorithms are newer and still gaining long-term operational confidence. In that sense, hybrid is a practical hedge during migration, not a reason to treat the transition as finished.
However, hybrid should not be confused with silent classical fallback. During early migration, fallback may be necessary because not every peer will support the same post-quantum method, not every partner will be ready, and not every branch device or managed service provider will expose the required controls. But if a high-risk tunnel quietly falls back to classical-only key exchange, the organization may believe it has reduced harvest-now-decrypt-later risk when it has not.
The minimum requirement is visibility. If fallback is allowed, it must be logged, monitored, and risk-accepted.
The long-term goal should not be permanent complexity. Hybrid is useful while the ecosystem matures, but organizations should still track when and how the classical dependency can eventually be reduced or retired based on standards maturity, vendor support, and risk appetite.
The Roadmap Does Not Stop at the Browser
Regardless of vendor, every organization will eventually face the same decision: how should the tunnel behave when post-quantum negotiation is not available or does not succeed?
Hybrid key exchange is the preferred transition model because it combines a strong classical exchange with a post-quantum mechanism instead of forcing the organization to bet entirely on one side. That matters because classical public-key cryptography is the known quantum target, while post-quantum algorithms are newer and still gaining long-term operational confidence. In that sense, hybrid is a practical hedge during migration, not a reason to treat the transition as finished.
However, hybrid should not be confused with silent classical fallback. During early migration, fallback may be necessary because not every peer will support the same post-quantum method, not every partner will be ready, and not every branch device or managed service provider will expose the required controls. But if a high-risk tunnel quietly falls back to classical-only key exchange, the organization may believe it has reduced harvest-now-decrypt-later risk when it has not.
The minimum requirement is visibility. If fallback is allowed, it must be logged, monitored, and risk-accepted.
The long-term goal should not be permanent complexity. Hybrid is useful while the ecosystem matures, but organizations should still track when and how the classical dependency can eventually be reduced or retired based on standards maturity, vendor support, and risk appetite.
The Decision Every Organization Must Make
Regardless of vendor, every organization will eventually face the same decision: how should the tunnel behave when post-quantum negotiation is not available or does not succeed?
Hybrid key exchange is the preferred transition model because it combines a strong classical exchange with a post-quantum mechanism instead of forcing the organization to bet entirely on one side. That matters because classical public-key cryptography is the known quantum target, while post-quantum algorithms are newer and still gaining long-term operational confidence. In that sense, hybrid is a practical hedge during migration, not a reason to treat the transition as finished.
However, hybrid should not be confused with silent classical fallback. During early migration, fallback may be necessary because not every peer will support the same post-quantum method, not every partner will be ready, and not every branch device or managed service provider will expose the required controls. But if a high-risk tunnel quietly falls back to classical-only key exchange, the organization may believe it has reduced harvest-now-decrypt-later risk when it has not.
The minimum requirement is visibility. If fallback is allowed, it must be logged, monitored, and risk-accepted.
The long-term goal should not be permanent complexity. Hybrid is useful while the ecosystem matures, but organizations should still track when and how the classical dependency can eventually be reduced or retired based on standards maturity, vendor support, and risk appetite.
The encouraging news is that almost every weakness above has a corresponding control, and Microsoft provides a genuine, layered security model. The problem is rarely that the controls do not exist. It is that they are off by default, spread across several admin centres, or quietly relaxed by a business user who simply wanted their agent to work. In priority order, this is where organisations should start.
- Remediate oversharing first
Before scaling agents, fix the data estate they will read. Identify over-broad permissions, open sharing links, and broken inheritance, and bring access back to what is actually needed. An agent only amplifies the oversharing that already exists, so this step pays for itself.
- Govern the platform
Use Power Platform environments as security boundaries, apply data loss prevention and connector policies to control what agents can touch, and pay particular attention to the default environment, where every user is a maker. Managed environments add sharing limits and policy enforcement at scale.
- Set a deliberate authentication posture
Treat anonymous, unauthenticated agents as a conscious decision rather than an accident. Keep tools running on the end user’s own credentials wherever possible, and treat any agent that uses the maker’s credentials, or that runs automatically on a trigger, as privileged and subject to extra scrutiny.
- Turn on Microsoft Purview
Use Data Security Posture Management for AI to gain visibility into how agents are used, data loss prevention to keep labelled content out of agent grounding, sensitivity labels to enforce protection on the underlying data, and auditing to keep an accountable record of agent activity.
- Constrain the tools
Apply least privilege to every connector, require human approval for high-impact actions, and lock down general-purpose web-request capabilities that can be abused for exfiltration or for reaching internal systems.
- Red team continuously
Finally, test agents the way an attacker would, both before they go live and on a recurring basis. The attacks evolve, the agents change, and a point-in-time review ages quickly. Continuous adversarial testing is the only way to know what an agent will actually do under pressure, rather than what it was designed to do.
The Roadmap Does Not Stop at the Browser
Post-quantum migration started at the browser because that is where it first became visible. But visibility is not the same as coverage. The traffic that most needs to stay confidential for years frequently travels over VPN tunnels, not public web sessions.
A TLS-only post-quantum roadmap leaves that path unassessed. Treating VPN and IPsec readiness as its own workstream—inventory, harvest-now-decrypt-later prioritization, classical hygiene, precise vendor validation, and disciplined testing—is how an organization closes the gap between a roadmap that looks complete and one that actually is.
See also:
Dubai