Post-quantum cryptography is coming, but most organizations are stuck rebuilding their infrastructure to get there.
At A Glance
- NIST plans to deprecate classical public-key algorithms like RSA and ECC by 2030, and EO 14412 is accelerating federal timelines further.
- Most PQC programs stall because they’re scoped as an estate-wide infrastructure replacement — every firewall, VPN, and TLS-terminating device on a spreadsheet.
- PQC is really three separate problems (session secrecy, identity/PKI, and protocol-path compatibility), each with its own timeline and owner. Treating them as one problem is how a PQC program turns into a multi-year, tens-of-millions retrofit.
- Identity-First Reachability™ moves the migration from the network path to the authorized service connection, so PQC can roll out service-by-service without touching the underlying network.
Post-quantum cryptography (PQC) is now near the top of the risk register. The drivers are familiar: regulatory clocks, and “harvest now, decrypt later” adversaries recording today’s encrypted traffic to decrypt it once quantum computers mature. NIST points to classical public-key crypto being deprecated by 2030, with government and defense timelines needing to run well ahead of that. Recent Executive Order EO 14412 is entirely focused on PQC, something we could’ve never predicted in the early 2020s. We must now shift our thinking from, “PQC will always be 10 years away” to, “what do I do now?”
Unfortunately, most PQC programs are stuck because they require an infrastructure upgrade. Every firewall, proxy, load balancer, VPN concentrator, WAF, and TLS-terminating appliance gets added to a spreadsheet, and the program becomes a multi-year, estate-wide refresh of the connectivity model that made the problem hard in the first place.
NetFoundry takes infrastructure out of the way of PQC business objectives. Our solution, built on the OpenZiti software we open sourced and maintain, moves authorized service connections to PQC without any dependencies on networking, firewalls, and infrastructure. The unit of migration stops being the network path and becomes the service connection itself. That’s the same pattern we apply to microsegmentation and Zero Trust: business priorities determine which workloads need to be secured, from legacy apps to crown jewels to AI agents, and we secure them without touching everything else.
PQC Is Three Problems, Not One
Most PQC conversations blur three engineering problems that have different owners, different urgency, and different timelines. Confusing them leads to the wrong architecture and the wrong rollout plan.
1. Session secrecy
Protecting data in transit with quantum-resistant key exchange, so traffic recorded today can’t be decrypted later. “Harvest now, decrypt later” means the exposure has already started, and it’s also the most mature. Hybrid post-quantum key establishment is standardized and shipping in modern TLS stacks today.
2. Identity and PKI
Certificates, signatures, enrollment, trust chains, and key lifecycle all have to evolve too, and evolution takes time. Every system that issues, validates, or depends on a certificate is a migration dependency, and in a typical enterprise those systems are owned by a dozen teams and a hundred vendors. Unless your PKI is centralized and automated, identity migration becomes a distributed, multi-year program.
3. Protocol-path compatibility.
Post-quantum handshake key material can be 30–40x larger than today’s. Larger handshakes, certificates, and headers break assumptions baked into middleboxes (side note: just had a nasty flashback to MTU 1500 issues with encryption. Ok, I’m back). Every device that terminates, inspects, or makes decisions on TLS becomes something you must evaluate, test, upgrade, or replace due to the size.
These three problems are related, but they don’t migrate on the same timeline. A plan that treats all three of these as one problem (“make the network quantum-safe”) inherits the union of all three problems’ dependencies at once. That’s how PQC becomes an unrealistic, estate-wide retrofit.
Why Brownfield Networks Make PQC Migration So Hard
Heads of infrastructure already know how this movie goes (flashbacks, again). In a traditional, topology-defined network, reachability exists before identity is enforced. An app that wants to talk to a service traverses DNS, routing, NAT, firewalls, proxies, WAFs, load balancers, security groups, and gateways. Every one of those hops is a place where crypto is terminated, inspected, or depended upon.
That means PQC inherits every middlebox and every path dependency. The unit of work becomes “configure and maintain the path” for every path. Multiply the three problems above across every device in every path in the estate, coordinate the change windows across every team that owns a box, and you have the real reason PQC migration estimates come back measured in years and tens of millions. This pain isn’t caused by post-quantum; it’s caused by the connectivity model. NetFoundry changes it.
How Identity-First Reachability Changes the PQC Migration Unit
Post-quantum migration is usually treated as a network problem: replace or upgrade every device that touches encrypted traffic until the whole estate is quantum-safe. At NetFoundry, we treat it as a service problem instead: quantum-resistant protection applied to individual authorized service connections, one workload and one flow at a time, through an identity-first overlay that sits above the existing network.
Our approach of Identity-First Reachability™, built on the open source OpenZiti platform we developed and maintain, inverts the model, authorizing before connecting. No trusted identity plus matching policy means no route, no session, and no reachable service. Services are dark by default, with no public listening interface. When an identity is authorized, the overlay fabric creates exactly one thing: an encrypted path from that identity to that named service. No standing privilege, just a session-specific overlay. The reframing addresses all three PQC problems at once:
| PQC Problem | How Identity-First Reachability Solves It |
|---|---|
| Session Secrecy | The cryptographic boundary is a NetFoundry connector (gateway, host agent, or SDK), positioned outside the legacy application and above the network infrastructure. Hybrid-PQC key establishment is introduced at that boundary, so applications and underlay networks don’t need to speak PQC on day one. The boundary can move inward over time (gateway → host → SDK) as end-to-end protection is required. |
| Identity and PKI | Every endpoint is enrolled with a strong X.509 identity (NetFoundry or third-party) in a PKI-native fabric, with certificates, trust anchors, rotation, and renewal managed centrally and automatically. Identity migration becomes an upgrade to one hierarchy you control, not a distributed program across every app, appliance, and relying party. |
| Protocol Path | The overlay keeps standard TLS/mTLS on the outside while post-quantum protection rides inside the fabric. Routers, firewalls, WANs, and load balancers forward overlay traffic instead of terminating or parsing the inner crypto. |
Identity-First Reachability is the only pattern designed to reduce all three problems together, because it changes what’s being migrated.
How to Roll Out PQC-Ready Zero Trust Without a Network Overhaul
Because the migration unit is a service flow, the program is staged, scoped, and testable rather than big-bang:
- NetFoundry and partners help you inventory your sensitive flows and crypto dependencies, using the same discovery process we use for microsegmentation onboarding — mapping actual traffic before any policy changes.
- You pick high-value service flows according to business priority.
- You place the boundary (NetFoundry connector — virtualized gateway, host binary, or SDK) according to the operational needs of that workflow. This enables identity-first policy over secure transport (a Zero Trust native overlay) without touching infra and firewalls.
- Add hybrid-PQC protection to that flow; validate latency, interoperability, and operations, then widen scope. Pilot first, prove value, move the boundary inward over time.
Each step is reversible, measurable, and doesn’t require the standards, hardware acceleration, and assurance ecosystem to be fully mature before you start. You move fast on architecture while the ecosystem matures around you. Compare that to the alternatives most infrastructure teams are evaluating:
| Approach | Trade-off |
|---|---|
| Application-Native PQC | Strongest end state, but the largest brownfield blast radius (NetFoundry SDKs can simplify this). |
| VPN Hardening | Makes individual tunnels quantum-safe but leaves topology, PKI, and most of the service path untouched — and adds to the VPN problem. |
| PQC-Enabled SD-WAN / SASE | Can make the network fabric quantum-ready, but is a complex, risky, forklift approach. We need scalpels, not sledgehammers — the topology still extends to network borders when the real goal is moving the service boundary inward. |
Each of these solutions still treats the network as the unit of migration. NetFoundry treats the service connection as the unit of migration.
Make PQC Migration Realistic
Avoid turning PQC into an enterprise-wide retrofit of the old connectivity model by keeping the three problems separate. Change the migration unit from the network path to the authorized service connection, and the payoff compounds beyond compliance:
- Stronger security: no reachable service, not even visible to unauthorized identities, for a dramatically smaller attack surface.
- Lower operational cost: central policy replaces path-by-path engineering, with fewer VPNs, firewall changes, and ACL sprawl to maintain.
- Room to move: new applications, clouds, OT sites, partners, and AI workloads get added by policy, not by redesigning topology.
That’s the bet NetFoundry has made since we open sourced OpenZiti: security shouldn’t require rebuilding the network underneath it. PQC is just the latest proof of why that bet matters. If you’re staring down a PQC mandate and a stack of middleboxes that all need to change at once, talk to us about how an identity-first approach would work in your environment.
Frequently Asked Questions
What is post-quantum cryptography (PQC) migration?
PQC migration is the process of replacing cryptographic algorithms vulnerable to quantum computers, like RSA and ECC, with quantum-resistant alternatives. At NetFoundry, we think of it less as a network-wide swap and more as an upgrade to how individual service connections establish trust and encrypt traffic.
Why is PQC migration so difficult for most organizations?
Because most enterprise networks are topology-defined: traffic passes through firewalls, proxies, load balancers, and VPN concentrators before it reaches an application, and every one of those devices terminates or inspects encryption. We’ve found that inventorying and upgrading all of them at once is what turns PQC into a multi-year, estate-wide project instead of a scoped one.
What does “harvest now, decrypt later” mean?
It’s a threat model where adversaries capture encrypted traffic today with the intent of decrypting it once quantum computers are powerful enough to break current encryption. It’s the reason PQC urgency exists now, even though large-scale quantum computers don’t yet exist.
Does moving to PQC require replacing my firewalls and VPNs?
Not necessarily. We built NetFoundry’s approach specifically so that hybrid-PQC protection can be introduced at the application or connector level, above the existing network, so the underlying firewalls, routers, and VPNs don’t need to be replaced or reconfigured to carry PQC traffic.
What is Identity-First Reachability™?
Identity-First Reachability is NetFoundry’s model for making services reachable only to specifically authorized identities, with no visible or listening network surface for anyone else. We use it as the foundation for Zero Trust, microsegmentation, and — in this case — a PQC migration path that operates at the service level instead of the network level.
How long does a PQC migration take with NetFoundry’s approach?
It depends on scope, but because the migration unit is a single service flow rather than the whole network, organizations can pilot hybrid-PQC protection on one high-value flow, validate it, and expand from there — rather than waiting for an estate-wide cutover before seeing any results.
