Post-Quantum VPN: 6 Questions to Ask Your Current Vendor

TL;DR

Every major VPN and ZTNA vendor has at least a “post-quantum” press release in 2026. Fewer than half ship a production-ready implementation. Six questions — specific algorithm and parameter set, hybrid or pure, rotation cadence, visible mode, default-on status, and audited source — separate working implementations from marketing. This post walks through each question, shows what a good answer looks like, and includes the honest current status of QuickZTNA plus publicly verifiable snapshots of four other vendors. Run this checklist before your next procurement decision, or before your next compliance audit.

Who this is for

Security leads evaluating a VPN or Zero Trust Network Access product. Architects renewing a contract. Auditors testing the claims of a deployed product. If you already know what to ask, skip to the table in section 9.

Table of contents

1. Why these six questions
2. Question 1 — Which algorithm, at what parameter set
3. Question 2 — Hybrid or PQ-only
4. Question 3 — How often does the PQ key rotate
5. Question 4 — Can you see the mode on the wire
6. Question 5 — Is it on by default or opt-in
7. Question 6 — What is the implementation source, and has it been audited
8. Bonus questions that separate tiers
9. Vendor snapshot table
10. How to validate answers

1. Why these six questions

In a year of talking to security teams, the failure mode we see is consistent: vendors say “we are quantum-safe” and customers say “great, sign here”. The answer to “how” does not get asked. Six months later, an audit finds that the production configuration is still classical-only because “quantum-safe” in the vendor’s marketing was a capability in a lab build, not a default in the shipped product.

The six questions below are designed to surface that gap. They are procurement-ready. Copy them into your RFI. A vendor that answers all six with specifics is serious. A vendor that deflects two or more is not ready.

The questions are ordered from most to least binary — the first few have right answers and wrong answers; the last few require judgement.

2. Question 1 — Which algorithm, at what parameter set

The canonical answer in 2026 names ML-KEM-768 (NIST security category 3) or ML-KEM-1024 (NIST category 5), both from FIPS 203. Some defensible variations:

• ML-KEM-768 is the common commercial default. Matches the TLS 1.3 hybrid codepoint X25519MLKEM768.
• ML-KEM-1024 is what the NSA CNSA 2.0 specifies for US National Security Systems.
• ML-KEM-512 is rarer but defensible for bandwidth-constrained links.

Red-flag answers:

• “Kyber” without a version year. Pre-standard Kyber is not interoperable with ML-KEM. If the vendor has not updated their language since 2024, their library is probably equally out of date.
• “NIST-approved post-quantum” without naming one. Marketing, not engineering.
• “Lattice-based” with no specifics. Lattices are a family; implementation details matter.
• “Proprietary” or “customised”. Homegrown crypto is an anti-pattern.
• Hash-based KEMs, isogeny-based KEMs, code-based KEMs other than Classic McEliece. The isogeny-based SIKE candidate was broken in 2022. Code-based schemes other than Classic McEliece have substantial key sizes and are rarely deployed as the primary KEM.

Ask specifically: “Is this a NIST FIPS 203 conformant ML-KEM implementation, or an earlier Kyber draft?” A vendor that cannot answer this question in under 10 seconds has not done the work.

3. Question 2 — Hybrid or PQ-only

The right answer in 2026 is hybrid: the vendor runs both a classical and a post-quantum key agreement in parallel, and combines the results through a KDF.

Reasons:

• Post-quantum algorithms are young. The body of cryptanalysis is a few years old. A future unexpected break is possible.
• Pure post-quantum deployments cannot fall back gracefully if the primitive is weakened.
• All three major Western cybersecurity agencies — NSA (CNSA 2.0), German BSI, French ANSSI — recommend hybrid deployments during the transition.

Defensible deviations:

• Pure PQ after 2030. Some vendors may switch defaults once cryptanalysis has matured and mandated deadlines bite. Reasonable.
• Classical-only on legacy peers. If the vendor’s product has to interoperate with stock WireGuard or legacy concentrators, a configurable per-peer classical fallback is reasonable. The behaviour should be logged.

Red flags:

• PQ-only with no hybrid option in 2026. Premature.
• Classical with PQ “coming soon” on a tier you are not buying.
• Hybrid only in a “premium” tier. Harvest-now-decrypt-later is not a premium threat. The attack equally affects free-tier and paid-tier sessions.

We describe the hybrid construction in detail in our hybrid key exchange post.

4. Question 3 — How often does the PQ key rotate

The right answer is per handshake, with ephemeral key pairs on both sides, and the hybrid derivation re-run on every WireGuard (or IKE) rekey.

• WireGuard rekeys every 120 seconds by default. A PQ layer that re-derives on every rekey gives you a 2-minute post-quantum forward-secrecy window.
• TLS 1.3 sessions are longer-lived. A PQ hybrid TLS 1.3 session has forward secrecy per handshake, but handshakes are much rarer than with WireGuard.
• IKEv2 supports hourly or per-session rekey. Configure aggressively.

Red flags:

• “We rotate the PQ key weekly” means six days of forward-secrecy exposure to a captured key compromise.
• “The PQ key is long-lived” means no forward secrecy at all from the PQ leg. An attacker who compromises the long-lived PQ secret at any future point gets every past session’s key.
• “We mix a static PQ PSK into the handshake” is a common pattern from first-generation implementations. Better than nothing but not forward-secret.

5. Question 4 — Can you see the mode on the wire

A mature implementation exposes the key exchange mode as visible state. Operators should be able to tell, per tunnel, whether the session used hybrid, classical-only, or PQ-only key exchange.

What good looks like:

• Per-tunnel status page showing kex=hybrid-x25519-mlkem768 or equivalent.
• CLI command that reports the mode, like ztna status -v in QuickZTNA.
• Audit log entry on every session establishment and re-establishment, recording the mode.

Red flags:

• No status visibility. You cannot prove in an audit which sessions were protected by which crypto. You cannot detect a silent regression.
• Marketing claims post-quantum but the CLI does not expose mode. Classic gap — the capability exists, but nobody can verify it in production.
• Mode is reported only in the premium UI. Should be universal.

6. Question 5 — Is it on by default or opt-in

The right answer is on by default. Harvest-now-decrypt-later works on every session — premium, standard, and free. Opt-in post-quantum is security theatre unless nearly everyone opts in.

A further test: is it on by default on the free tier too? This is a good proxy for whether the vendor’s pricing is aligned with security or with premium extraction. Our harvest now, decrypt later post makes the case that PQ is table-stakes, not a premium feature.

Red flags:

• “Available on Enterprise tier only.” The attack is tier-agnostic.
• “Beta flag on individual accounts.” Experimental posture for a production-ready standard.
• “Opt-in per tunnel.” Operators forget to opt in. Mass regressions.

The deliberate exception: an admin-controlled policy to forbid PQ fallback is reasonable. A high-security org might prefer hard-fail rather than silent downgrade. But the default state for new tunnels should be “hybrid PQ enabled”.

7. Question 6 — What is the implementation source, and has it been audited

Homegrown cryptography is an anti-pattern. The right answer names a well-known implementation:

• Go standard library crypto/mlkem (Go 1.24+). Used by QuickZTNA. Reviewed by the Go security team.
• OpenSSL 3.5 or newer. Widely reviewed.
• BoringSSL main branch.
• AWS-LC. Amazon’s fork of BoringSSL.
• Microsoft SymCrypt. Used in Windows and Azure.
• libOQS (with caveats — it is an experimental reference library, production use requires careful validation).

What to ask for:

• Audit report from an independent firm. Public report is better than “audit happened privately”. Published date matters — an audit from 2022 does not cover ML-KEM.
• FIPS 140-3 validation status of the module. Check the CMVP list.
• Fuzz coverage. A serious implementation includes fuzz harnesses; the vendor should have no trouble sharing coverage data.
• Patch cadence. When the Go stdlib, OpenSSL, or other upstream ships a security fix, how quickly does the vendor pick it up?

Red flags:

• Custom assembly routines for polynomial multiplication written in-house.
• Source code not available for audit by enterprise customers.
• “We use a hardened fork” with no explanation of what was hardened and why.
• Stale dependency. A vendor still pinned to a Kyber pre-standard library in 2026.

8. Bonus questions that separate tiers

Four more questions that distinguish serious vendors from marketing-driven ones.

8.1 How does the migration to ML-KEM-1024 happen?

Once you are running ML-KEM-768 today, the move to 1024 (for CNSA 2.0 alignment) should be a config change, not a protocol fork. Ask for the concrete steps: what config, what downtime, how the mixed fleet negotiates during the rollout. “We do not have a plan for that” is a warning.

8.2 What happens during the CMVP validation process?

If the vendor is seeking FIPS 140-3 validation of their post-quantum module, ask the current status: pre-submission, under review, approved, rejected. Timing matters for regulated customers.

8.3 Do you publish test vectors and conformance results?

A vendor who can hand you NIST test-vector outputs from their ML-KEM implementation is confident in the implementation. A vendor who cannot is not.

8.4 What is the end-to-end handshake latency in your deployment today?

Real production numbers with specifics — not “sub-5ms”, but “median 2.3ms at the p95 in our BLR-to-NYC path, measured over the past 30 days”.

9. Vendor snapshot table

This table reflects what is publicly documented as of April 2026. Always verify with the vendor’s current release notes before acting on it — all of these vendors are shipping fast. Our promise on factual integrity, from the writing guidelines, applies: where we are unsure we say “check vendor docs”, not invent an answer.

Vendor	PQ key exchange	Hybrid	On by default	Visible mode
QuickZTNA	ML-KEM-768	Yes (X25519)	Yes, all tiers	Yes, per-tunnel
Cloudflare Access	TLS 1.3 hybrid with ML-KEM-768 on edge	Yes	Yes on edge	Partial (HTTP headers)
AWS site-to-site VPN	Post-quantum IKE modes on several services	Check current docs	Check current docs	Check current docs
Tailscale	Check current docs	Check current docs	Check current docs	Check current docs
Twingate	Check current docs	Check current docs	Check current docs	Check current docs
Perimeter 81 / Check Point Harmony SASE	Check current docs	Check current docs	Check current docs	Check current docs
Zscaler Private Access	Check current docs	Check current docs	Check current docs	Check current docs

We deliberately leave “check current docs” in place for several vendors rather than quote an answer that could be stale by publish date. This table is updated quarterly; the live version lives at /blog/post-quantum-vpn-vendor-questions. If a vendor has published a clearer post-quantum statement that we missed, email us and we will update — same-day.

10. How to validate answers

Four concrete validation techniques once the vendor has answered.

10.1 Packet capture

Capture a handshake in a lab. For TLS 1.3, look at the supported_groups extension in the ClientHello and the key_share in the ServerHello. A 0x11EC codepoint indicates X25519MLKEM768. For WireGuard-derived tunnels, capture the pre-shared key material arriving from the vendor’s control plane and check that it matches a hybrid derivation against independently captured keys.

10.2 Ask for a test endpoint

A serious vendor will happily point you at a test endpoint you can interrogate with openssl s_client or a WireGuard peer. If they say “we cannot expose a test endpoint for security reasons”, that is a non-answer — test endpoints are routine.

10.3 Read the audit report

Get the actual PDF. Check the date. Check the scope. Check whether the auditor’s remarks include any “unresolved findings”.

10.4 Run in a staging environment with logging on

Deploy the vendor’s product in staging, turn on verbose logging, and read the logs. Every established session should show the kex mode. If it does not, you now have evidence.

Further reading

Primary sources verified on the publish date.

• FIPS 203 — ML-KEM
• NSA CNSA 2.0 Advisory (2022)
• IETF draft-ietf-tls-hybrid-design
• RFC 8784 — Mixing Preshared Keys in IKEv2 for Post-quantum Resistance
• NIST Cryptographic Module Validation Program
• UK NCSC Post-Quantum guidance

Related reading on this blog

• ML-KEM-768 Explained
• Harvest Now, Decrypt Later
• Hybrid Key Exchange X25519 + ML-KEM-768
• NSA CNSA 2.0 Deadlines

Try QuickZTNA

You can answer all six questions for QuickZTNA yourself in five minutes: sign up for Free, connect two devices, run ztna status -v, and you will see kex=hybrid-x25519-mlkem768 on every established tunnel. No premium tier required. Start free.