Most organizations treat PQC migration as an all-or-nothing infrastructure overhaul. A waterfall project-managed all-or-nothing: inventory everything, plan everything, migrate everything, validate everything. The scope is paralyzing, and the result is predictable: most organizations are still in the planning phase while their encrypted traffic is being harvested.
Recent formal research from Cisco proved mathematically what many practitioners suspected: for data confidentiality, one post-quantum layer anywhere in the network stack protects the entire payload against quantum decryption. An adversary who breaks every other layer with a cryptographically relevant quantum computer (CRQC) still hits a wall at the quantum-safe layer. The data stays encrypted. For some this might seem obvious, but it is the first time that we have a mathematical proof, and that matters.
This transforms the migration question. Instead of “how do we migrate everything,” the first question becomes “which single layer gives us the most protection for the least effort?” That is an answerable question, and the answer differs by architecture. The goal of this article is to walk through six common enterprise scenarios and show how to identify the best first move in each one.
Two important caveats before we proceed. First, one-layer approach handles confidentiality only. Authentication follows the opposite rule: every layer with public-key authentication must migrate for quantum-safe authentication. I will address the authentication challenge separately in each scenario. Second, “pick one layer” is a starting strategy, not an end state. Complete PQC migration remains the destination. But getting one layer migrated today is categorically better than having zero layers migrated while you plan a comprehensive program. The PQC Migration Framework is designed for exactly this kind of phased approach.
Before examining specific architectures, it helps to understand what factors determine which layer is the best first candidate.
Centralization of control matters most. A layer where one configuration change protects traffic for thousands of users delivers more value per unit of effort than a layer that requires changes on every endpoint. A reverse proxy, a VPN concentrator, or a service mesh control plane can apply PQC to all traffic flowing through it.
Scope of protection determines what you actually defend. Migrating the outermost layer (the network tunnel or WiFi encryption) protects both payload and metadata, including connection patterns, destination addresses, and traffic volumes. Migrating an inner layer (application-layer encryption or TLS) protects the payload but leaves metadata exposed. Both are valid, depending on your threat model.
Operational feasibility is the constraint that separates theory from practice. Some layers are controlled by your team and can be updated in weeks. Others depend on vendor software, protocol standards, hardware refresh cycles, or ecosystem coordination that could take years. The best first layer is often the one you can actually change.
Persistence of existing protection affects urgency. If a layer already uses purely symmetric cryptography (pre-shared keys, AES with no public-key key exchange), that layer has no Shor-class vulnerability. You can defer it. Layers using RSA, ECDH, ECDSA, or other public-key operations are the ones bleeding quantum exposure right now.
With these factors in mind, let’s walk through six enterprise architectures.
The stack: User device → TLS 1.3 to SASE edge → SASE tunnel (IPsec or proprietary) to SASE POP → TLS 1.3 to destination web server.
Active cryptographic layers: TLS on the client side, the SASE overlay tunnel, and TLS on the server side. All three typically use ECDH or X25519 for key exchange, making all three Q-Unsafe.
The best first layer: SASE edge TLS termination.
Most SASE architectures terminate and re-originate TLS at the edge. This is a centralized point under IT control where one configuration change protects all corporate web traffic flowing through the platform. If your SASE provider supports hybrid PQC TLS (and Cloudflare has committed to full PQC by 2029, with others following), enabling it may be a vendor configuration rather than an internal engineering project.
The protection this buys: all HTTP content flowing between the SASE edge and destination servers becomes quantum-safe for confidentiality. An HNDL adversary who intercepts traffic on the WAN segment between your SASE POP and the internet gets ciphertext they cannot break with a CRQC.
What it does not protect: the segment between the user device and the SASE edge still uses classical TLS. If an adversary captures traffic on the local network (WiFi, campus LAN), they can recover metadata and potentially content from that first hop. For most enterprise threat models, the WAN segment is the higher-risk capture point, but organizations with nation-state adversary concerns should evaluate the local segment separately.
Authentication gap: The TLS certificates on both sides of the SASE edge remain ECDSA or RSA. A quantum adversary could forge server certificates and mount an active man-in-the-middle attack. This requires a CRQC operating in real time (not an HNDL scenario), which makes it a later-phase risk, but it must be addressed before CRQC arrival. Certificate infrastructure migration is the harder, longer project. Start with a cryptographic inventory of your certificate chain now so you understand the scope.
The stack: External client → TLS to API gateway/load balancer → mTLS between services via service mesh (Istio, Linkerd, Consul Connect) → database connections (TLS or application-level encryption).
Active cryptographic layers: Ingress TLS, east-west mTLS (often dozens or hundreds of service-to-service connections), and database encryption.
The best first layer: The service mesh control plane.
Service meshes manage mTLS for all east-west traffic through a centralized control plane (Istio’s istiod, Linkerd’s control plane). The mesh’s sidecar proxies (typically Envoy) handle certificate rotation and cipher suite negotiation. Updating the mesh configuration to use hybrid PQC TLS for all service-to-service communication can protect hundreds of internal connections through a single policy change.
This is a high-leverage move because microservices architectures generate enormous volumes of internal API traffic. Financial calculations, patient records, customer data, proprietary algorithms, all flowing between services with mTLS that currently uses ECDH key exchange. An HNDL adversary who captures east-west traffic (through a compromised node, a container escape, or a misconfigured network policy) can store it all for quantum decryption. Migrating the mesh to PQC closes that exposure for every service simultaneously.
What it does not protect: ingress traffic from external clients depends on the API gateway’s TLS configuration, which is a separate migration. Database connections are typically separate from the mesh. Both should follow as next steps.
The authentication problem is acute here. Service meshes issue short-lived certificates (often rotating every 24 hours) using ECDSA or RSA. Under a “min” composition rule, every mTLS connection becomes an independent authentication attack surface. The good news: because certificate issuance is centralized in the mesh CA, migrating to ML-DSA (formerly CRYSTALS-Dilithium) certificates is a single CA configuration change rather than a per-service project. Service meshes may be the easiest place in the enterprise to achieve full PQC authentication, precisely because they already centralize certificate management.
The stack: User device → VPN client → encrypted tunnel (IPsec IKEv2 or WireGuard) to VPN concentrator → corporate network → application servers (TLS or unencrypted).
Active cryptographic layers: VPN tunnel (IKEv2 with ECDH or WireGuard with Curve25519), and optionally TLS to internal applications.
The best first layer: The VPN tunnel itself.
The Cisco research showed that a standard WireGuard VPN provides zero quantum protection because Curve25519 key exchange is Shor-vulnerable. The same applies to IKEv2 with ECDH. An adversary capturing encrypted VPN traffic today can decrypt everything once a CRQC arrives: browsing destinations, application data, authentication tokens, internal network topology.
Migrating the VPN to PQC transforms it from a quantum liability into a quantum shield. Every application, every protocol, every byte of traffic flowing through the tunnel gains confidentiality protection from a single infrastructure change at the VPN concentrator.
For WireGuard specifically, there is an intermediate option: enabling PSK (pre-shared key) mode. WireGuard’s Noise protocol can mix a 256-bit pre-shared key into the handshake, making the derived symmetric keys independent of Curve25519. Even if the EC discrete log is solved, the PSK contribution keeps the keys secret. This makes the tunnel Q-Safe for confidentiality without waiting for a full protocol replacement. The operational cost is distributing and managing PSKs out of band, which is non-trivial at scale but achievable for a defined set of VPN concentrators.
For IPsec IKEv2, the IETF has published drafts for hybrid PQC key exchange, and several vendors (Cisco, Palo Alto, Fortinet) have implemented or announced support. Check your vendor’s current PQC roadmap; this may already be available as a configuration option in your existing deployment.
Authentication gap: IKEv2 uses RSA or ECDSA certificates for peer authentication. WireGuard uses Curve25519 static keys. Both are Q-Unsafe. Complete VPN quantum safety requires migrating both key exchange (confidentiality) and peer authentication (integrity). Certificate-based VPN authentication shares the same CA infrastructure migration challenge as TLS.
The stack: HMI/SCADA server → industrial protocol (Modbus/TCP, DNP3, OPC UA) → PLC/RTU. Typically wrapped in an IPsec VPN or a dedicated OT network segmented from IT.
Active cryptographic layers: Often just IPsec on the network boundary. Many industrial protocols run unencrypted or with fixed symmetric authentication (DNP3 Secure Authentication uses HMAC-SHA-256). Some deployments have no cryptographic layers at all.
The best first layer: The OT network boundary IPsec gateway.
OT environments present a different category of challenge. Industrial protocols like Modbus/TCP were designed without cryptography. DNP3 Secure Authentication added HMAC-SHA-256, which is symmetric and therefore not Shor-vulnerable (though Grover-weakened). OPC UA defines security profiles with fixed algorithm combinations that cannot be renegotiated.
You cannot add PQC to the industrial protocol layer. The protocols do not support it, the PLCs cannot run it, and the firmware cannot be updated. As I have written in the context of crypto-agility architecture, any protocol with fixed algorithm identifiers is structurally incompatible with agility until the protocol specification itself is revised. For industrial protocols, that is a multi-year standards body effort.
What you can do is migrate the network boundary. If OT traffic crosses an IPsec tunnel between sites (which is common in distributed utility, manufacturing, and pipeline environments), migrating that tunnel to hybrid PQC key exchange protects all encapsulated industrial protocol traffic. The PLCs do not need to change. The SCADA software does not need to change. The IPsec gateway handles the quantum protection at the perimeter.
This is precisely the single-layer confidentiality principle in action. One Q-Safe layer at the boundary protects everything inside it, including protocol traffic that could never be upgraded directly.
Authentication gap: OT environments face the worst authentication migration timeline in any sector. Industrial device certificates (if they exist at all) are often embedded in firmware that cannot be updated. Many OT authentication mechanisms use symmetric keys that are not Shor-vulnerable, which provides some protection but not complete authentication integrity. The CRQC Quantum Capability Framework timeline suggests that organizations have years, not months, before active authentication attacks become feasible, but the OT remediation timeline is also measured in years (or decades for embedded devices). Start the inventory now.
The stack: Email client → S/MIME or PGP encryption (application layer) → SMTP with STARTTLS between mail servers → recipient mail server → recipient client.
Active cryptographic layers: Application-layer end-to-end encryption (S/MIME or PGP) and transport-layer TLS between mail servers.
The best first layer: Application-layer encryption (S/MIME or PGP).
Email is the classic HNDL target. Diplomatic communications, M&A discussions, legal privileged correspondence, medical records. Encrypted email captured in transit today could be decrypted in a decade with a CRQC. The exposure window is as long as the data’s sensitivity lifetime.
If your organization uses S/MIME, the migration path depends on certificate authority support for PQC certificates. The CA/Browser Forum Baseline Requirements do not yet permit ML-DSA in publicly trusted certificates, but private enterprise CAs can issue PQC certificates for internal use now. Organizations running their own PKI for S/MIME are in a stronger position to deploy PQC email encryption early.
For PGP/GPG users, PQC support is in development but not yet in mainstream implementations. This is a case where the ecosystem constrains the migration timeline regardless of organizational readiness.
The interim strategy: even without PQC at the email application layer, migrating SMTP TLS between mail servers to hybrid PQC key exchange protects email in transit on the server-to-server segment. This does not protect against HNDL adversaries who capture mail at rest on either server, but it does protect the transport channel. It is a partial measure, and for high-sensitivity communications, it is insufficient. But it is achievable now for organizations that control their mail infrastructure.
Authentication gap: S/MIME signing certificates use RSA or ECDSA. A quantum adversary could forge signed emails, attributing fabricated content to legitimate senders. For legal, financial, and regulatory communications where email signatures carry evidentiary weight, this is a material risk that organizations should factor into their authentication migration planning.
The stack: Mobile app or partner system → TLS to API gateway → API gateway → mTLS to backend microservices → encrypted database connections → HSM for signing and key management.
Active cryptographic layers: External TLS, internal mTLS, database TLS, HSM-based signing.
The best first layer: The API gateway’s external TLS termination.
Financial services process some of the highest-value data subject to HNDL risk: transaction records, account credentials, customer PII, trading algorithms, regulatory filings. API gateways are natural choke points. Every external API call flows through them, and most organizations operate a small number of gateway instances (or use a managed service like AWS API Gateway, Azure API Management, or Kong).
Migrating the API gateway to hybrid PQC TLS protects all inbound API traffic at a single point. Every mobile app session, every partner integration, every webhook callback gains confidentiality protection against quantum decryption. If the API gateway is a managed cloud service, the migration may be a configuration toggle once the provider ships PQC support (AWS has already deployed ML-KEM across major service endpoints).
For organizations running their own API gateways (Kong, Nginx, Envoy-based), the upgrade path depends on the underlying TLS library. OpenSSL 3.5 with OQS provider support, or BoringSSL with Google’s PQC patches, are the current options. The engineering effort is real but bounded, and it is concentrated in a small number of well-understood systems.
What about the HSM? Hardware security modules present a harder problem. HSMs used for transaction signing, key wrapping, and certificate issuance may not support PQC algorithms yet. HSM vendor PQC roadmaps vary widely, and hardware refresh cycles are long. HSMs are a critical authentication dependency that cannot be addressed by single-layer confidentiality migration. Plan for this as a separate workstream with its own timeline, and pressure your HSM vendor for a concrete PQC delivery date.
Across all six scenarios, a pattern repeats: one layer handles confidentiality; authentication resists shortcuts. Every public-key authentication point is an independent attack surface.
But the urgency profile differs. HNDL is a passive attack happening today. An adversary captures your encrypted traffic now, stores it, and decrypts it when a CRQC arrives. Authentication attacks require a CRQC operating in real time. The adversary must forge credentials during the connection, not after the fact. This means confidentiality migration is more urgent for most organizations, because the damage from HNDL is being accumulated right now.
Authentication migration, however, has a longer lead time. Certificate infrastructure, PKI hierarchies, HSM firmware, protocol updates, vendor dependencies. The crypto-agility architecture article covers why these dependencies compound, and why starting the authentication inventory now (even if deployment is years away) avoids a compressed migration window later.
For practitioners weighing these trade-offs, the Trust Now, Forge Later analysis explains why authentication migration, while less urgent in the HNDL sense, carries higher consequences when it becomes exploitable. A forged signing key can cause active harm; a decrypted historical message is a confidentiality breach. Both matter, but they demand different response timelines.
For security architects planning their first PQC migration, the process reduces to four steps:
Step 1: Map your protocol stack for each major data flow. What cryptographic layers exist between the data source and its destination? Which layers use public-key key exchange (Shor-vulnerable) and which use symmetric operations (Grover-reduced at worst)? The CBOM (Cryptographic Bill of Materials) approach provides a structured methodology for this inventory.
Step 2: Identify the most centralized migration point. Which layer can you update once and protect the most traffic? Look for proxies, gateways, VPN concentrators, service mesh control planes. Avoid layers that require per-device or per-endpoint changes for your first move.
Step 3: Check vendor PQC readiness. Can your SASE provider, cloud platform, VPN vendor, or service mesh enable hybrid PQC today? Some already can. If your most centralized layer depends on a vendor that is not PQC-ready, move to the next-best candidate rather than waiting.
Step 4: Deploy hybrid PQC and move on to the next layer. Hybrid mode (classical plus post-quantum key exchange running in parallel) is the recommended deployment approach. It maintains backward compatibility while adding quantum protection. Once the first layer is live, begin planning the authentication migration and the next confidentiality layer.
This is the practical application of the PQC Migration Framework‘s phased approach. The framework was designed for exactly this kind of iterative, priority-driven migration. Organizations that wait for a perfect, comprehensive plan will find themselves perpetually planning while their exposure grows.
The reason to act now is not a prediction about when a CRQC will arrive. As I have argued repeatedly, the deadlines are already set by forces that do not depend on quantum hardware timelines. NIST’s IR 8547 sets deprecation at 2030 and disallowance at 2035. NSA’s CNSA 2.0 requires PQC in new National Security System acquisitions from January 2027. Google has committed to completing its migration by 2029. Regulators, insurers, and clients are building quantum readiness into their procurement requirements and risk assessments.
Every day of delay is another day of encrypted traffic accumulating in adversary storage. One PQC layer stops that accumulation for payload confidentiality. Identify your best first layer, deploy it, and then continue the broader migration from a position of meaningful protection rather than total exposure.
My company - Applied Quantum - helps governments, enterprises, and investors prepare for both the upside and the risk of quantum technologies. We deliver concise board and investor briefings; demystify quantum computing, sensing, and communications; craft national and corporate strategies to capture advantage; and turn plans into delivery. We help you mitigate the quantum risk by executing crypto‑inventory, crypto‑agility implementation, PQC migration, and broader defenses against the quantum threat. We run vendor due diligence, proof‑of‑value pilots, standards and policy alignment, workforce training, and procurement support, then oversee implementation across your organization. Contact me if you want help.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。