The Coming Shift in Zero Trust vs. Post-Quantum Cryptography
Zero trust and post-quantum cryptography (PQC) are complementary security programs, not competing alternatives. Zero trust reduces unauthorized access and lateral movement today; post-quantum cryptography protects confidentiality and authenticity against future quantum-capable adversaries.
Organizations that treat either as a complete answer will leave material exposure: zero trust cannot repair quantum-vulnerable cryptography, and post-quantum cryptography cannot compensate for weak identity, excessive privilege, or unmonitored access.
For CTOs, the strategic difference is very simple: zero trust is about who and what can access a resource; PQC is about whether intercepted or forged crypto material remains trustworthy in the face of quantum.
Zero trust vs post-quantum cryptography: The core distinction
Zero trust is an access control and architecture model. It operates on the principle that no user, device, workload, or network segment should be implicitly trusted, and every access request requires continuous, least-privilege authorization.
Post-quantum crypto is a crypto modernization program. It’s about replacing public-key algorithms susceptible to future quantum attacks (particularly for key exchange and digital signatures) with algorithms designed to resist them.
| Dimension | Zero Trust | Post-quantum Cryptography |
|---|---|---|
| Primary objective | Prevent unauthorized access and lateral movement | Preserve confidentiality and authenticity against quantum attacks |
| Core mechanism | Continuous identity, device, and context-based authorization | Quantum-resistant key establishment and signatures |
| Primary threat addressed | Credential abuse, compromised endpoints, excessive privilege, lateral movement | “Harvest now, decrypt later” and future forgery of signatures |
| Protection horizon | Current and ongoing attacks | Data with long confidentiality lifetimes; future quantum capability |
| Can it stop quantum attacks? | No | Yes, for appropriately migrated cryptographic primitives |
| Can it replace the other? | No | No |
NIST defines Zero Trust as protection of the resource rather than the network segment, with authentication and authorization taking place prior to the session being established. NIST defines PQC as cryptographic standards designed to be resistant to future quantum attacks that will undermine the current standards.
What does zero trust security protect against?
Zero trust security is all about protecting against the threat of an adversary who has already gained a foothold inside the network and is looking to move laterally towards the more valuable assets. It’s all about removing the implicit trust that we have in network location, ownership, or previous authentication.
A mature Zero Trust architecture protects against:
- Stolen credentials being reused across vast areas of the environment.
- Compromised laptops, servers, containers or IoT devices accessing other systems.
- Excessive standing and broad network reachability.
- Insider or supply-chain access that spreads laterally after the initial compromise.
- Unmonitored access between users, workloads, APIs, and data stores.
- Perimeter-only security models in hybrid, multi-cloud, and remote-work environments.
CISA defines zero trust as minimizing uncertainty in per-request access decisions in an environment assumed to be compromised. The aim is to prevent unauthorized access to data and services and to do so as granularly as possible.
What zero trust does not protect against?
Zero trust doesn’t make crypto quantum safe. You can have strong authentication as part of your zero trust model prior to access, but that doesn’t change the fundamental mathematical assumption that underpins RSA, elliptic curve crypto and all the other algorithms that are vulnerable to a sufficiently capable quantum computer.
It also does not eliminate:
- Quantum-vulnerable key exchange embedded in TLS, VPNs, messaging systems, and proprietary protocols.
- Long-lived encrypted archives that could be harvested today and decrypted later.
- Forged software updates, code signing certificates or document signatures post quantum advance.
- Cryptographic dependencies hidden in third-party software, HSMs, operating systems, and libraries.
- Poor key management, weak randomness, expired certificates, or unmanaged cryptographic assets.
Zero trust can limit who reaches a system; it cannot make a quantum-vulnerable signature or key-establishment algorithm quantum-resistant.
What does post-quantum crypto protect against?
Post-quantum cryptography protects against two distinct future-facing threats: harvest now, decrypt later (HNDL) and trust now, forge later (TNFL).
In an HNDL attack, an adversary captures encrypted traffic or data today, stores it, and decrypts it later once quantum computing can break the underlying public-key protection. This is why post-quantum cryptography migration is urgent for data whose confidentiality must survive years or decades: intellectual property, health records, financial records, state secrets, strategic plans, and long-lived backups.
In a TNFL attack, an adversary could later forge digital signatures or compromise the authenticity of systems that rely on quantum-vulnerable algorithms (e.g., RSA, ECC). This would be a threat to software updates, code signing, certificates, secure boot, document authenticity, and machine identity.
NIST’s first post-quantum cryptography standards address both needs:
- FIPS 203 / ML-KEM: Quantum-resistant key establishment (derived from CRYSTALS-Kyber).
- FIPS 204 / ML-DSA: Quantum resistant digital signatures based on CRYSTALS-Dilithium.
- FIPS 205 / SLH-DSA: Stateless hash-based signatures, derived from SPHINCS+
What post-quantum cryptography does not protect against?
Post-quantum cryptography is not a replacement for Zero Trust, endpoint security, identity governance, or secure SDLC. It protects specific cryptographic primitives, not the entire attack surface.
PQC does not prevent:
- Phishing, credential theft, malware, insider misuse, and social engineering.
- Misconfigured cloud permissions, exposed APIs and privileged service accounts.
- Vulnerable apps, unpatched software or a compromised supply chain.
- Weak session management, poor secrets management or insecure key storage.
- Data exposure caused by excessive access rights or a lack of monitoring.
A quantum resistant TLS handshake is of no use if the attacker has valid credentials, a compromised device or excessive privileges. That’s why PQC and Zero Trust need to work in tandem.
Can zero trust protect against the threats posed by quantum computing?
No, not by itself. Zero trust can reduce the probability that an adversary will get at data or systems, but it cannot protect data that’s already been encrypted with quantum-vulnerable algorithms from future decryption.
Zero trust can, however, improve quantum readiness in three ways:
- It can restrict access to crypto material, key management systems, and sensitive data stores.
- It can enforce least privilege for service identities that perform encryption, signing or certificate operations.
- It can improve visibility into where cryptographic functions run across users, devices, workloads, and networks.
The correct framing is: Zero trust limits access; post-quantum cryptography preserves cryptographic assurance. Neither substitutes for the other.
How do zero trust and post-quantum cryptography work together?
The best security architecture is one that combines both.
Zero trust determines whether an identity, device, workload, or service is permitted to access a resource. Post-quantum cryptography decides whether the crypto (the crypto that’s protecting that access) is still trustworthy in a post-quantum world.
A practical combined model looks like this:
| Layer | Zero trust contribution | PQC contribution |
|---|---|---|
| Identity | Strong authentication, least privilege, continuous evaluation | Quantum-resistant signatures for identity and machine credentials |
| Device | Device posture and trust evaluation | PQC-capable firmware, secure boot, and update signing |
| Network | Granular access policy and segmentation | Quantum-resistant key establishment in supported protocols |
| Application | Service identity and workload authorization | PQC libraries, APIs, and cryptographic agility |
| Data | Classification, access control, and monitoring | Long-term confidentiality through quantum-safe encryption |
CISA’s zero trust Maturity Model covers identity, devices, networks, applications and workloads and data with visibility, automation and governance as the cross cutting capabilities. PQC should be embedded into all of those domains rather than be a separate ‘encryption’ project
What are the risks of not moving to post-quantum cryptography?
The real risk isn’t that a quantum computer will appear tomorrow. The risk is that data we intercept today could be read by an adversary decades from now. The risks include:
- Loss of confidentiality for long-lived sensitive data that was captured prior to migration.
- Inability to trust software updates, firmware, certificates, or code signatures following a quantum breakthrough.
- Regulatory, contractual, and cyber insurance exposure as post-quantum cryptography expectations continue to harden.
- Costly emergency migration across applications, vendors, protocols, and embedded systems.
- Inability to demonstrate quantum readiness to customers, regulators, or strategic partners.
NIST’s final transition guidance identifies the quantum-vulnerable algorithms and sets out the transition timelines for replacing them with quantum-resistant alternatives.
The transition timeline set out in NIST IR 8547 sees NIST deprecate and eventually remove the quantum vulnerable algorithms from its standards by 2035, with high-risk systems transitioning earlier
What should a CTO include in a post-quantum cryptography migration plan?
A legitimate post-quantum cryptography migration plan must start with discovery rather than with algorithm selection. You can’t migrate what you haven’t discovered.
Build a cryptographic inventory
Create a living inventory of crypto assets across code, infrastructure, SaaS, third-party software, certs, protocols, hardware, backups, and vendor dependencies. Include algorithms, key lengths, cert lifetimes, data sensitivity, retention periods, owners, and upgradeability.
Classify data by exposure horizon
Prioritize the data that needs to remain confidential well beyond the expected arrival of cryptographically relevant quantum computers. NIST specifically names long-lived sensitive data as a priority for early migration to PQC key establishment.
Prioritize high-risk paths
Start with the externally exposed stuff: TLS termination, VPNs, API gateways, identity providers, code signing infrastructure, secure boot chains, and high-value data stores. Those are the ones with the most exposure to HNDL and TNFL risk.
Establish cryptographic agility
Don’t hard code the algorithms into the applications. Build abstraction layers, configuration driven algorithm selection and test harnesses so that you can swap out the algorithms without having to re-write the whole product.
Use hybrid approaches where appropriate
Hybrid key establishment can be used to blend the classical and the post-quantum approaches during the transition period. That maintains interoperability and reduces the reliance on a single new algorithm.
Test performance and operations
post-quantum cryptography algorithms can vary enormously in terms of key size, signature size, handshake behavior, CPU usage, and network overhead. Test them under real production conditions (mobile networks, embedded devices, high throughput APIs, constrained hardware etc.)
How to assess quantum cybersecurity risks?
A quantum-readiness assessment should answer five questions:
- Where is crypto used? Applications, libraries, protocols, certificates, HSMs, databases, backups and third-party services.
- Which algorithms are quantum vulnerable? RSA, ECC, Diffie-Hellman and the like public key algorithms.
- Which data has a very long confidentiality horizon? Prioritize the data that needs to be kept confidential well beyond the likely point of quantum transition.
- Which systems can’t be upgraded quickly? Embedded devices, industrial systems, legacy apps, and vendor locked in components.
- Who owns remediation? Assign accountable owners for application teams, infrastructure, identity, cryptography, procurement, and vendor management.
The output should not be some generic ‘quantum readiness’ score. It should be a ranked remediation backlog with business impact, data sensitivity, technical feasibility, and vendor dependency all factored in.
How to migrate to quantum-resistant encryption
Migration should be incremental, observable, and where possible reversible.
- Establish a cryptographic center of excellence with Security, Platform, Application, Identity, and Procurement representation.
- Inventory and classify crypto dependencies.
- Define the target algorithms and interoperability requirements.
- Pilot the post-quantum cryptography in non-production and low risk environments.
- Upgrade TLS, VPN, API and identity provider capabilities where available.
- Rotate the keys and certs as vendor and protocol support permits.
- Validate the performance, compatibility, logging and incident response procedures.
- Extend the migration requirements into the procurement and vendor contracts.
- Track progress through measurable KPIs, not broad maturity labels.
NIST’s October 2026 guidance treats post-quantum cryptography migration to as a broad cryptographic modernization program. It is with timelines that will vary from organization to organization. But it will be applicable across all products, services and infrastructure.
How to prepare for a post-quantum world
Preparation should focus on reducing future migration costs, not on predicting the exact date when a quantum computer becomes capable of breaking RSA or ECC.
The highest-value actions are:
- Start the cryptographic inventory now.
- Identify long-lived sensitive data.
- Demand post-quantum cryptography roadmaps from critical vendors.
- Prioritize externally exposed key-establishment paths.
- Build cryptographic agility into new systems.
- Establish PQC test environments.
- Align zero trust and PQC programs under one security architecture.
- Treat post-quantum cryptography as a multi-year modernization program, not a one-time upgrade.
What are the principal challenges in quantum readiness?
The real difficulties are organizational rather than mathematical.
- Discovery: crypto is baked into the code, the vendors, the hardware and the protocols.
- Dependency management: Many systems cannot be upgraded independently.
- Performance: post-quantum cryptography algorithms may affect latency, bandwidth, and device constraints.
- Interoperability: Partners, customers, and legacy systems may not support PQC simultaneously.
- Governance: Cryptographic ownership is often fragmented across security, platform, application, and infrastructure teams.
- Prioritization: Organizations must distinguish near-term HNDL exposure from longer-term signature-forgery risk.
The CTO’s operating model
Treat post-quantum cryptography as a data protection and trust integrity program and zero trust as an access control and containment program. They’re solving different failure modes and need to be funded, governed, and measured separately.
The most defensible posture is:
- Zero trust now to reduce unauthorized access, privilege abuse, and lateral movement.
- PQC now for long-lived data, critical key establishment, and high-value signature infrastructure.
- Cryptographic agility always so algorithms can evolve without a full platform rebuild.
- Vendor accountability immediately so third-party dependencies do not become the migration bottleneck.
Zero trust answers: can this identity access this resource at this very moment? Post-quantum cryptography answers: will this data and these signatures still be trustworthy when quantum capability does mature? The organizations need to have credible answers to both.
In brief
A post-quantum cryptography migration should be run as a multi-year cryptographic modernization program, not a single TLS upgrade.
The objective is to reduce future migration costs, preserve interoperability, and protect data whose confidentiality must remain secure beyond the expected arrival of cryptographically relevant quantum computers. Zero Trust answers: Can this identity access this resource right now? Post-quantum cryptography answers: Will this data and these signatures remain trustworthy once quantum capabilities mature?
Organizations need credible answers for both. The most resilient 2027 security architecture is therefore not “Zero Trust versus post-quantum cryptography.” It is Zero Trust for access, post-quantum cryptography for cryptographic assurance, and cryptographic agility for the decade ahead.
