Overview

Post‑quantum cryptography (PQC) continues to move from selective pilots into constrained production at the perimeter and identity plane. For zero‑trust networks—where identity, short‑lived credentials and cryptographic bootstrapping are foundational—PQC is now an operational planning item, not a distant research problem. This update (September 2026) summarizes what has changed since mid‑2026, presents current evidence on performance and vendor readiness, and gives a prioritized set of actions zero‑trust teams should take now.

Background: why this still matters

In 2022 NIST selected PQC algorithms (CRYSTALS‑Kyber for KEM, CRYSTALS‑Dilithium and others for signatures); that technical consensus started practical work. Between 2023–2025 we saw broad experimentation (liboqs, OpenSSL+OQS builds, cloud pilots) and by 2026 vendors began limited production rollouts. Zero‑trust networks are particularly sensitive because they depend on short‑lived credentials, high connection churn (east‑west microservices), and identity brokers that validate tokens and certificates at scale. Any increase in handshake size, CPU cost, or certificate complexity ripples across enforcement, telemetry and key‑management systems.

Data and evidence (what changed since July 2026)

  • Vendor movement to limited GA: Since mid‑2026 several cloud and CDN providers publicly moved from pilot to limited general availability for hybrid PQC TLS on managed endpoints and load balancers. That transition has meant customers can enable hybrid KEM/TLS on specific hostnames or edge routes rather than in blanket experimental mode.
  • Browser and client support: Browser vendors continue conservative rollouts. By September 2026, stable builds in major browser engines generally support hybrid KEMs for TLS when servers advertise them, but many enterprises still rely on feature flags or staged rollout policies to manage compatibility with corporate devices and legacy proxies.
  • Benchmarks and observed impacts: Independent and vendor benchmarks published during 2026 consistently show two measurable effects: (a) hybrid KEM handshakes add payload and round‑trip cost (typical handshake size increases on the wire range from several hundred bytes to roughly 1–2 KB depending on the algorithm and certificate size), and (b) PQC public‑key operations raise CPU use during full handshakes. For long‑lived sessions the cost is amortized; for short, high‑churn flows the impact can be material unless resumption or session caching is used.
  • FIPS and compliance traction: Work to validate PQC implementations with FIPS/CAVP test suites is underway; a small set of module vendors announced initial validations for PQC primitives during 2026. However, broad FIPS‑validated PQC stacks suitable for regulated production remain limited and are an important procurement constraint for some organizations.
  • Identity/token ecosystem: The IETF and JOSE communities have published updated guidance drafts for representing PQC signatures and hybrid verification in token formats. Several identity platforms now accept layered signature verification (classical + PQC), and identity brokers in production have begun adding multiplexed verification pipelines that support progressive key rotations.

Multiple perspectives: vendors, cryptographers, and operators

  • Cloud/CDN vendors: View PQC as a perimeter upgrade with measurable customer demand. Their priorities are interoperability, predictable latencies, and offering opt‑in hybrid TLS that customers can enable per endpoint.
  • Browser vendors: Prioritize compatibility. They emphasize gradual enablement, telemetry collection, and interoperability tests with major CDNs before enabling PQC by default.
  • Cryptography researchers: Urge hybrid deployments for "harvest now, decrypt later" protection, while cautioning about supply‑chain and implementation bugs. They continue to recommend algorithm agility and layered defenses over a single migration event.
  • Operations and SRE teams: Face the practical tradeoffs. Teams managing serverless and high‑churn microservices report measurable latency regressions when hybrid PQC is applied to every short‑lived connection; they prefer perimeter or brokered models with session resumption and connection pooling to mitigate load.

Where PQC affects zero‑trust most — updated specifics

TLS/mTLS and session establishment

  • Hybrid TLS remains the de facto interim strategy: combine classical (ECDHE) and PQC KEMs (e.g., Kyber‑style) in the same handshake to retain current security guarantees while preventing future harvest‑and‑decrypt attacks.
  • Operational note: enable session resumption (TLS 1.3 resumption or 0‑RTT cautiously) and connection pooling aggressively for east‑west traffic to avoid repeating costly full handshakes.

PKI, certificate lifecycle, and revocation

  • Certificate sizes have grown when PQC signatures are embedded; this affects MTU behavior on constrained networks and can increase latency for CRL/OCSP‑heavy validation paths.
  • Short‑lived certs (days to weeks) and automated orchestration (ACME extensions, automated CA workflows) reduce exposure and are now standard advice for teams starting PQC pilots.

Token systems (OIDC/JWT) and code signing

  • Token sizes increase when PQC signatures are used; identity brokers need to support multiplexed verification and cache layered verification results to avoid latency spikes in token validation hot paths.
  • Code signing: because signed artifacts are stored long term, prioritized migration planning is necessary. Some vendors now support dual signatures (classical + PQC) on release artifacts to maintain archival verifiability.

VPNs, WireGuard, and ZTNA

  • WireGuard‑style static keys complicate PQC migration for constrained devices. Many ZTNA providers now offer brokered tunnels where cloud termination handles PQC, reducing device‑side resource requirements.

Implications for zero‑trust teams

Three immediate implications stand out:

  1. Perimeter first, then identity plane: Implementing hybrid PQC at cloud/CDN ingress and ZTNA brokers gives early protection for external exposure without imposing PQC costs on every endpoint immediately.
  2. Crypto‑agility is now an operational requirement: Identity platforms, token validators, and PKI systems must support multiple algorithms concurrently and automated key rotation. This is not a future nice‑to‑have — it reduces migration friction and costly emergency rollouts.
  3. Measure and mitigate: Quantify handshake size, CPU, and latency impact for representative workloads (mobile, edge, east‑west). Use session resumption, connection pooling, and broker termination to reduce repeated PQC overheads.

Practical, prioritized checklist (September 2026)

  • Inventory cryptography comprehensively: TLS/mTLS endpoints, JWT issuers/validators, code signing keys, VPNs, and archived signatures. Flag artifacts that must remain verifiable for decades (IP, regulated records).
  • Classify risk by data retention and confidentiality lifespan; prioritize assets that require quantum‑resistant preservation.
  • Start hybrid PQC at the perimeter and control plane (API gateways, CDNs, ZTNA brokers) where vendor support is most mature; enable per‑endpoint and per‑route staging.
  • Adopt short‑lived certs and automated rotation now—this reduces future exposure irrespective of PQC adoption.
  • Ensure identity brokers support multiplexed signature verification and caching; benchmark token validation latency under PQC signature verification load.
  • Plan for procurement: require PQC roadmaps, interoperability test results, and timelines for FIPS/CAVP validation where necessary.
  • Run canary and chaos experiments: test failure modes, certificate rollover, and mixed‑algorithm verification under load.
  • Update incident response runbooks to include PQC‑specific scenarios (key rollover mistakes, mixed‑algorithm verification failures).

Outlook — what to watch for next

  • Wider FIPS‑validated PQC stacks: as validation suites complete, expect broader availability of compliance‑ready PQC implementations in 2026–2027. That will unlock regulated production use in finance, healthcare and government.
  • Standardization work in IETF and JOSE: expect finalized identifiers and clearer token formats for PQC signatures in late‑2026 to 2027, reducing interoperability friction for JWT and OIDC ecosystems.
  • Improved PQC algorithms and optimized libraries: performance will continue to improve as implementers and CPU vendors optimize implementations and as COTS hardware adds acceleration for certain primitives.
  • Supply‑chain and signing practices: dual‑signing workflows for releases and archived artifacts will become a best practice for organizations with long retention requirements.

Recommendations — concise and practical

  • Begin with hybrid PQC at chokepoints (perimeter, ZTNA brokers, gateways) and measure real workloads before wider rollout.
  • Invest engineering effort in crypto‑agile identity systems now: multiplexed verification, key rotation automation, and token caching are high‑value items.
  • Shorten certificate lifetimes and automate rotation immediately—this reduces quantum‑capture exposure regardless of PQC timelines.
  • Require vendor PQC roadmaps and interoperability results in procurement, and verify FIPS/CAVP status if regulation demands it.
  • Prioritize testing on high‑churn services and constrained devices; use offload/broker models where device CPU or battery is limited.

Multiple viewpoints — balanced closing

PQC adoption in zero‑trust networking is a tradeoff between immediate operational cost (latency, CPU, storage) and long‑term confidentiality assurance. Cryptographers argue for hybrid adoption now to prevent future harvest‑and‑decrypt risks; operators emphasize staged, measurable rollouts with strong telemetry. The pragmatic middle path is clear: protect high‑value, long‑retention assets early, enable hybrid PQC at chokepoints, and make identity systems crypto‑agile so that the next algorithm change—quantum or otherwise—becomes frictionless.

FAQ

Should I enable PQC everywhere right now?

No. Prioritize where it matters: external endpoints, ingress/egress chokepoints, and assets with long confidentiality lifetimes. For high‑churn internal traffic, rely on session resumption, connection pooling, or brokered termination until devices and stacks are optimized.

How much performance impact will my services see?

It depends on workload. Benchmarks during 2026 show hybrid handshakes add on‑the‑wire bytes and increase CPU on full handshakes; the cost is typically amortized for long‑lived sessions. Measure with your real traffic and use resumption/connection reuse to mitigate repeated full handshakes.

Do I need FIPS‑validated PQC now?

If you operate in regulated sectors that mandate FIPS‑validated cryptography, verify vendor timelines—some vendors began initial validations in 2026, but broadly available, production‑ready FIPS PQC stacks are still limited. For non‑regulated environments, pragmatic hybrid deployment at chokepoints is an effective interim step.

How should token and code‑signing systems change?

Implement multiplexed verification (support both classical and PQC signatures), cache verification results, and consider dual signatures for artifacts needing long‑term verifiability. Update token size limits and transport handlers to accommodate larger signatures.

What should procurement teams ask vendors now?

Request PQC feature roadmaps, interoperability test results, performance benchmarks on representative workloads, and timelines for any compliance validations (e.g., FIPS/CAVP). Include contractual obligations for algorithm agility and migration support where feasible.