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.

Evaluation Dimension	Passing Vendor Answer	Red Flag / Marketing Evasion
1. Concrete Algorithm & Parameter Set	✅ Explicitly names ML-KEM-768 or ML-KEM-1024 from FIPS 203.	❌ Vague terms (“military-grade quantum safe”, “proprietary lattice”).
2. Hybrid vs. Pure Post-Quantum	✅ Dual-key hybrid (X25519 + ML-KEM) preserving classical forward secrecy.	❌ Pure PQ only without classical defense or proprietary combiners.
3. Ephemeral Rekeying Cadence	✅ Rekeying derives fresh ephemeral PQ keys periodically (e.g. every 2–10 min).	❌ Static PSK configured once at provision time and never rotated.
4. Telemetry & Protocol Visibility	✅ CLI and audit logs show the negotiated cipher suite per active session.	❌ Opaque client with no user or SIEM visibility into active crypto groups.
5. Default-On vs. Lab Flag	✅ Enabled by default in production client builds without hidden flags.	❌ Requires special beta builds or contact-sales feature toggles.
6. Open Implementation & Audited Code	✅ Standard open cryptographic libraries (e.g., Go crypto/mlkem, Circl, OpenSSL 3.5).	❌ Closed-source unverified custom crypto implementations.

Figure 1.1: Multi-Stage Policy Decision Flowchart & Gating Logic — Post-Quantum VPN Vendor Procurement Decision Tree.

Multi-Stage Gating Logic & Policy Evaluation Flow

The decision flowchart above illustrates the sequential verification pipeline enforced by Post-Quantum VPN Vendor Procurement Decision Tree:

• Q1: ALGORITHM — FIPS 203 Compliance: Does the vendor explicitly name standardized ML-KEM-768 / 1024?
  • Verification Rules: Names FIPS 203 parameters; Rejects vague ‘quantum-safe’ claims
  • Branch Outcome: Passes to Proceed to Hybrid Check; non-compliant requests trigger 🚩 Red Flag: Proprietary Crypto.
• Q2: HYBRID COMBINER — Classical Fallback: Does protocol combine ECDH (X25519) with lattice mathematics?
  • Verification Rules: Dual-key hybrid design; Preserves classical forward secrecy
  • Branch Outcome: Passes to Proceed to Rekey Cadence; non-compliant requests trigger 🚩 Red Flag: Unverified Pure PQC.
• Q3: DEFAULT-ON — Production Deployment: Is PQC enabled by default in GA client builds without hidden beta flags?
  • Verification Rules: Enabled in production client; Active cipher visible in CLI logs
  • Branch Outcome: Passes to ✅ Approved for Procurement; non-compliant requests trigger 🚩 Red Flag: Lab Flag Only.

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.

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+). Reviewed by the Go security team. (QuickZTNA does not use it — we implement no ML-KEM.)
• 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	None — not implemented	❌ No	❌ No	N/A (classical WireGuard)
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

Apply the same six questions to us and you get a short answer: QuickZTNA does not implement post-quantum key exchange. The data plane is classical WireGuard (X25519 + ChaCha20-Poly1305), and you can confirm it yourself in five minutes — sign up for Free, connect two devices, and run ztna status -v to see the key exchange actually in use. We would rather you check than take a badge on trust. Start free.

---

Related Technical Architecture & Deep Dives

• The 2026 Post-Quantum Migration Timeline: Every Major Deadline on One Page: In-depth technical architecture, protocol specifications, and implementation best practices.
• Hybrid Key Exchange X25519 + ML-KEM-768: The Complete Guide: In-depth technical architecture, protocol specifications, and implementation best practices.
• ML-KEM-768 Explained: The NIST Quantum-Safe KEM (FIPS 203): In-depth technical architecture, protocol specifications, and implementation best practices.
• QuickZTNA Architecture & Deployment: Enterprise WireGuard mesh networking, automated identity-based microsegmentation, and zero trust access control.

---

Recommended Reading & Related Architectural Guides

To continue exploring enterprise zero trust networking, identity orchestration, and WireGuard deployment patterns, explore our related technical teardowns:

• Post-Quantum Cryptography Migration Timeline (NIST & CNSA 2.0)
• Hybrid Key Exchange X25519 Mlkem
• ML-KEM-768 (FIPS 203) Explained: Post-Quantum Key Encapsulation
• Cnsa 2 0 Deadlines
• Harvest Now Decrypt Later
• QuickZTNA Zero Trust Mesh Architecture & Platform Overview
• QuickZTNA Cloud Mesh Deployment & Technical Documentation