Zero Trust and Post-Quantum Cryptography: Why One Without the Other Is Not Enough

Zero Trust Architecture removes implicit network trust. Post-quantum cryptography migration removes algorithm vulnerability to a future quantum adversary. These are different security properties, and organisations can have one without the other. Both gaps are costly. But the gap that is less discussed is the one that creates the countdown clock: a ZTA deployed without PQC migration has cryptographic guarantees that expire in the 2033 to 2035 window, simultaneously across every pillar of the architecture.

This article maps the technical intersection. It assumes the reader has deployed or is deploying ZTA and is beginning to engage with PQC migration as a separate programme. The argument here is that they should not be separate programmes.

What Zero Trust Architecture Actually Depends on Cryptographically

NIST SP 800-207 (August 2020) defines ZTA around five principles: all data sources and computing services are treated as resources; all communication is secured regardless of network location; access to resources is granted per-session; access decisions are determined by dynamic policy; the enterprise monitors asset integrity and security posture continuously. Every one of these principles requires cryptography to function.

The cryptographic dependencies concentrate in four pillars. Identity: authentication tokens, X.509 certificate-based identity assertions, signed JWTs with RS256 or ES256, OIDC and SAML for federated identity. Device: device certificates from internal or cloud PKI, TPM 2.0 attestation using ECDSA or RSA keys, platform integrity measurements signed by the TPM. Network: mutual TLS establishing authenticated encrypted sessions between every communicating service pair, east-west traffic encrypted throughout. Data: at-rest and in-transit encryption using keys derived through asymmetric mechanisms, key management infrastructure (KMS) protecting symmetric keys with asymmetric key wrapping.

All four pillars rely on asymmetric cryptography. RSA, ECDH, and ECDSA (the algorithms underpinning key exchange and digital signatures across the ZTA cryptographic stack) are fully vulnerable to Shor's algorithm running on a cryptographically relevant quantum computer (CRQC). Q-Day is assessed at 2033 to 2035 (Mosca, IEEE Security and Privacy, 2018). On that timeline, a ZTA deployed today without PQC migration planning has a defined expiry on its cryptographic foundations.

The harvest-now-decrypt-later threat adds a present-tense dimension. ZTA requires continuous verification and rich telemetry: high volumes of encrypted traffic including mTLS session data, identity token exchanges, and policy decision point queries. An adversary collecting that traffic today is not just collecting content; they are collecting a detailed behavioural record of the enterprise's access patterns. Even sessions carrying low-sensitivity content may reveal organisational structure, privilege relationships, and operational patterns that have long-term intelligence value.

PQC in the Identity Pillar: ML-DSA for Certificates and JWTs

Current ZTA identity schemes use RSA or ECDSA for X.509 certificate signatures and JWT signing (RS256, ES256). NIST FIPS 204 standardises ML-DSA (Module-Lattice-Based Digital Signature Algorithm) as the post-quantum replacement. FIPS 205 standardises SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) as a hash-based alternative with different performance characteristics.

ML-DSA provides three parameter sets. ML-DSA-44 (NIST security level 2): public key 1,312 bytes, signature 2,420 bytes. ML-DSA-65 (Level 3): public key 1,952 bytes, signature 3,293 bytes. ML-DSA-87 (Level 5): public key 2,592 bytes, signature 4,595 bytes. The ML-DSA-87 parameter set is required for CNSA 2.0 compliance; ML-DSA-65 is the general enterprise recommendation from NIST IR 8547. Compare that with ECDSA P-256: 91-byte public key, 64-byte signature. In high-volume ZTA identity assertion workflows (where thousands of JWT validations and certificate checks occur per second), that size increase has measurable latency and bandwidth implications that must be planned for in infrastructure capacity sizing.

The transition mechanism for X.509 certificates is the composite certificate format defined in IETF draft-ounsworth-pq-composite-sigs. [ASSUMED, verify current draft or RFC status before publication.] A composite certificate carries both a classical algorithm and an ML-DSA key simultaneously, allowing identity infrastructure to verify against both keys during the migration period. Relying parties that have not yet updated can verify the classical component; post-quantum-capable relying parties verify the ML-DSA component. IETF LAMPS WG is developing PQC algorithm identifiers for X.509 certificates, including ML-DSA certificate profiles under draft-ietf-lamps-dilithium-certificates. [ASSUMED, verify final RFC or draft number at publication time.]

PQC in the Device Pillar: ML-DSA for Device Certificates and TPM Attestation

Device identity in ZTA runs through device certificates issued by an internal or cloud PKI (currently ECDSA or RSA), TPM 2.0 attestation keys (ECDSA or RSA), and platform integrity measurements signed by the TPM. The device certificate PKI is the primary migration target: it is where ML-DSA deployment flows to all device certificate chains.

TPM 2.0 (TCG specification) supports ECC and RSA natively. PQC algorithm support in TPM firmware is vendor-dependent and not yet universally available as of 2025. [ASSUMED, verify current TPM vendor firmware PQC status before publication. This is an active development area and may have changed.] The migration sequence for TPM-attested device identity will depend on whether endpoint TPM firmware can be updated to support ML-DSA, or whether attestation workflows must be redesigned around software-based identity until hardware support catches up.

PKI capacity planning at ML-DSA scale is not optional. An enterprise with 100,000 managed devices renewing certificates annually needs to account for the increased certificate sizes in CRL generation, OCSP response signing, and certificate distribution infrastructure. ML-DSA certificates are larger than ECDSA certificates by a factor of roughly 15 to 20 in public key size. Certificate revocation infrastructure that is sized for ECDSA will not handle ML-DSA at scale without planning. Find this constraint early. Discovering it at migration time adds months to the programme.

PQC in the Network Pillar: ML-KEM in mTLS and Service Meshes

Mutual TLS is the primary network-layer security mechanism in ZTA. In a microservices deployment, a single user request may traverse dozens of service-to-service mTLS sessions. Each TLS handshake performs asymmetric key exchange (currently ECDH or RSA key encapsulation) and certificate authentication (currently ECDSA or RSA). Both operations require PQC migration.

NIST FIPS 203 standardises ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) to replace ECDH in TLS 1.3 key establishment. ML-KEM-768 (NIST security level 3) is the general enterprise choice per NIST IR 8547 guidance. ML-KEM-1024 (Level 5) is required for CNSA 2.0 compliance in national security system contexts. For the algorithm requirements and deadlines that apply to defence contractors, see /insights/cnsa-2-vs-1-defence-suppliers/. The IETF has defined hybrid key exchange combining X25519 with ML-KEM in a single TLS 1.3 handshake. Chrome and Cloudflare deployed the pre-standardisation X25519Kyber768 hybrid in production from late 2023; the standardised form is X25519MLKEM768 using NIST FIPS 203. The engineering is proven at scale.

Service meshes (Istio, Linkerd) that manage mTLS automatically are the network-layer migration target. PQC migration in a service mesh requires three coordinated changes: updating the certificate authority root to issue ML-DSA certificates; updating the mTLS proxy (Envoy for Istio) to support ML-KEM key exchange; and updating SPIFFE/SPIRE SVID signatures to ML-DSA or composite format. As of 2025, Envoy and cert-manager had experimental ML-KEM and ML-DSA support; production readiness timelines vary by vendor. [ASSUMED, verify current Envoy/cert-manager PQC support status before publication. "Experimental" may have become production-ready by June 2026.]

PQC in the Data Pillar: KMS Migration and Key Wrapping

Data encryption in ZTA uses AES-256 for at-rest data and TLS 1.3 for in-transit data. AES-256 is quantum-resistant against Grover's algorithm: Grover gives a quadratic speedup for symmetric key search, reducing AES-256 effective security from 256 bits to 128 bits against a quantum adversary. 128-bit post-quantum security is considered adequate. NIST IR 8547 recommends retaining AES-256 rather than doubling key size, and does not recommend AES-128 for post-quantum use (AES-128 provides only 64-bit post-quantum security, which falls below the NIST threshold). The symmetric cipher is not the data pillar problem.

The problem is asymmetric key wrapping. Key management systems (AWS KMS, Azure Key Vault, GCP Cloud KMS, HashiCorp Vault) protect symmetric data keys by wrapping them with asymmetric keys. That asymmetric wrapping layer is fully vulnerable to Shor's algorithm. ML-KEM (FIPS 203) replaces ECDH for key transport in KMS workflows. OASIS KMIP v2.1 (Key Management Interoperability Protocol) supports PQC algorithm identifiers. Organisations using KMIP-compliant KMS systems should check vendor PQC roadmaps for ML-KEM support under KMIP v2.1, this is the contractual commitment to look for when assessing third-party KMS providers.

The Convergence Argument: Why One Without the Other Is Not Enough

Zero Trust without PQC migration is an architecture with time-limited cryptographic guarantees. If a CRQC arrives in 2033 to 2035, the failure is not isolated to one component. Identity certificates become forgeable. Device attestation is undermined. mTLS sessions can be decrypted retrospectively for any traffic collected between now and Q-Day. Key management infrastructure is compromised. The architecture fails as a system. The dependencies are horizontal across all four pillars, not confined to a single attack surface.

PQC migration without Zero Trust creates a different gap. An organisation that migrates its perimeter cryptography to ML-KEM and ML-DSA but retains implicit trust within the network boundary has secured the cryptographic layer without addressing the architectural assumption of implicit trust. A credential compromise inside the perimeter still propagates laterally. PQC migration addresses algorithm vulnerability. ZTA addresses the trust model. Both are necessary properties; neither is sufficient on its own.

The practical convergence argument is about programme efficiency. Upgrading the certificate authority to issue ML-DSA certificates, updating service mesh mTLS to use ML-KEM key exchange, and migrating KMS key wrapping to ML-KEM are the same engineering efforts required for both ZTA maturation and PQC migration. The PKI, service mesh, and KMS are the shared workstream. Organisations that treat these as separate programmes will scope, plan, and execute the same infrastructure changes twice. Treating PQC migration as a ZTA maturity workstream reduces total migration cost and creates a single coherent cryptographic architecture target.

Sequencing a ZTA and PQC Convergence Programme

The migration has five steps, ordered by leverage and dependency.

Step 1: PKI root CA migration to ML-DSA. This has the highest leverage of any single action because it flows to all downstream certificate chains, identity certificates, device certificates, TLS server certificates, code signing. A root CA replacement programme takes twelve to eighteen months minimum. Start here, not at the leaf certificates. Working backwards from root to leaf is the mistake that makes all subsequent milestones unachievable. For a detailed migration planning guide, see /insights/pqc-in-pki-migration-planning/.

Step 2: mTLS key exchange migration to X25519+ML-KEM hybrid at service mesh layer. Hybrid TLS deployment provides immediate protection against HNDL for traffic generated from the point of deployment onwards. Data already collected by an adversary remains at risk; new traffic is protected. This is deployable at the Envoy/Istio control plane level once vendor support is confirmed.

Step 3: KMS key wrapping migration to ML-KEM. Protects the symmetric data keys that underpin at-rest encryption across the ZTA data pillar. This is the point at which the data pillar's residual asymmetric exposure is closed.

Step 4: JWT and OIDC signing key migration to ML-DSA. Protects the identity assertions that authorise access decisions across the ZTA policy engine. This step depends on identity provider support, check vendor roadmaps for ML-DSA JWT signing before scheduling.

Step 5: Device certificate migration. The longest-lead item because it depends on endpoint agent updates and TPM firmware support. Identify which devices can be migrated via firmware update and which require hardware replacement. This inventory drives the Phase 2 and Phase 3 timeline for the device pillar.

Hybrid schemes should be used throughout the transition period for key exchange. The rationale is structural: a hybrid TLS scheme using X25519+ML-KEM requires an adversary to break both components simultaneously. A classical adversary who breaks X25519 cannot derive the session key if ML-KEM is sound. A CRQC-equipped adversary who breaks ML-KEM (hypothetical) cannot derive the session key if X25519 is sound. This belt-and-suspenders property is the reason the IETF hybrid design is recommended during migration rather than immediate pure-PQC deployment.

This is a multi-year programme. The sequencing above is a framework for ordering the work, not a claim that all five steps can be completed in a single sprint. For the data layer of this programme, deciding which data flows to migrate first, the HNDL risk assessment framework at /insights/hndl-risk-assessment-framework/ provides the prioritisation methodology.

Sources