Last year, I asked a room of infrastructure, identity and application leaders a simple question: “Where in our environment do we rely on RSA or elliptic curve cryptography?”
The first answers were the usual suspects: TLS on the edge, our VPN and the certificates on laptops. Then we pulled up a dependency map and the mood changed. Crypto wasn’t just in a few obvious places. It was buried in API gateways, service meshes, database drivers, firmware update pipelines and third-party SaaS. Some of it was configurable. A lot of it wasn’t.
That exercise is why I think the post-quantum conversation has to move from “interesting someday” to “start now.” Even if large, fault-tolerant quantum computers are not here yet, adversaries can harvest encrypted traffic and data today and attempt to decrypt it later. If you have information that must remain confidential for a decade or more — customer PII, health data, proprietary models, merger plans — waiting for a clean deadline is the riskiest option.
The good news is that we do not have to bet the enterprise on a single new algorithm overnight. A hybrid approach lets us add post-quantum protection while keeping classical algorithms that are widely deployed and interoperable. The trick is to start early enough that the migration is deliberate, measurable and boring by the time 2030 arrives.
The 2030 deadline is closer than it looks
In security programs, 2030 can feel like an eternity. In cryptography programs, it is frighteningly close. The reason is the long tail of enterprise change: inventories, procurement, platform upgrades, certificate lifecycles, embedded devices and the slowest vendor in your stack.
The standards foundation is already landing. NIST published its first three finalized post-quantum cryptography standards in August 2024, including FIPS 203 for ML-KEM and companion signature standards. That shifted the question I hear from “what should we wait for?” to “how do we operationalize this without breaking everything?”
From there, three forces compress the timeline:
“Harvest now, decrypt later” is not theoretical. If an attacker steals encrypted session captures or archived backups, the confidentiality loss happens the day quantum-capable decryption becomes practical. Your risk horizon is set by the shelf life of your data, not the arrival date of a quantum computer.
Government and critical infrastructure guidance are converging. The National Security Agency’s CNSA 2.0 suite sets expectations for quantum-resistant algorithms in national security systems with milestones that pull software and firmware signing toward a 2030 horizon. Even if you are not building for government, those supply chain requirements tend to flow downhill into commercial products.
Crypto migration is never a single project. Your public TLS endpoints might be modernized quickly. Your internal PKI, code signing pipeline and long-lived devices can take years. The last crypto refresh many enterprises remember — deprecating SHA-1 and older TLS — was manageable largely because teams started before the hard cutoff dates.
That is why I recommend a hybrid strategy before 2030. It buys down long-term confidentiality risk now, creates time for interoperability bugs to surface and avoids a last-minute scramble when customers, regulators or your own board ask, “Are we quantum ready?”
What hybrid post-quantum looks like in the real world
When I say “hybrid,” I mean using a classical algorithm and a post-quantum algorithm together so the connection stays secure even if one component is later broken. The most relevant enterprise example is hybrid key establishment for TLS and internal mTLS.
The IETF is standardizing approaches that combine classical ECDHE with ML-KEM so a TLS 1.3 session key depends on both mechanisms.
Hybrid signatures touch certificate chains, code signing systems and validation logic, so they usually come later. In most roadmaps I run, we begin by keeping classical certificates for compatibility while preparing PKI components, HSMs and signing services to support post-quantum signature algorithms as platforms mature.
In practice, hybrid almost always starts inside the enterprise first. External customer traffic has the most interoperability constraints and the highest blast radius. Internal service-to-service traffic, VPN tunnels between managed endpoints and software signing are better early candidates because we control both ends and can roll back quickly.
You also have to plan for real constraints:
Size and performance: post-quantum keys, ciphertexts and signatures can be larger than today’s elliptic curve equivalents, which can break assumptions in certificate stores, load balancers and MTU sizing.
Crypto agility: hybrid only works if you can change algorithms without rewriting half your environment, which means pushing cryptographic choices into configuration and deprecating bespoke crypto.
Operational observability: you need telemetry for handshake success rates, latency impact, error patterns and downgrade behavior so the rollout looks like any other reliability program.
The point is not to be “post-quantum only” tomorrow. The point is to make post-quantum a normal part of your cryptographic control plane so the eventual full transition becomes a series of routine upgrades, not a crisis.
A practical roadmap you can start this quarter
If you are looking for a pragmatic way to begin, here is the roadmap I have used with large US enterprises.
Build a cryptography inventory tied to data value
Start with an inventory of where cryptography is used: TLS termination, internal mTLS, VPN, SSH, S/MIME, code signing, disk and database encryption, backups, identity tokens, key management systems and embedded device firmware. Map those uses to data classes and retention horizons. The systems protecting 10+ year secrets are your “harvest now, decrypt later” priorities.
CISA’s post-quantum cryptography initiative is a useful checklist for the categories and dependencies you should capture and for how to think about critical functions.
Pick 3 early migration surfaces you control end-to-end
In most enterprises, the first three areas I target are:
Internal mTLS between services
VPN and remote access
Code signing for internal software distribution and update pipelines
These reduce long-term exposure without forcing you to negotiate compatibility with every customer browser, partner system or unmanaged device.
Stand up a “hybrid-ready” lab and instrument it
Before you touch production, stand up a lab that mirrors core traffic patterns: edge TLS, internal service mesh, API gateway and identity provider. Measure handshake sizes, latency and failure modes. Make sure you can roll back cleanly and explain what changed.
Upgrade for crypto agility
Standardize on modern TLS stacks, keep them patched and make algorithm selection a managed configuration. Consolidate certificate issuance flows. Push teams away from static crypto choices baked into application code. The more you centralize, the faster you can migrate.
Run a limited hybrid pilot with explicit success metrics
Pick one internal domain or one non-critical endpoint and pilot hybrid TLS. Define success as measurable outcomes: no increase in error rate, acceptable latency delta, stable CPU utilization and clean telemetry. When something breaks, document the dependency that caused it and feed that back into your inventory.
Put post-quantum requirements into procurement now
The fastest way to make 2030 painless is to make 2026 contracts future-friendly. Add language that requires crypto agility, support for NIST standardized post-quantum algorithms as they are adopted and a documented roadmap for hybrid support in TLS, VPN and signing.
If you start now, you buy time for standards, platforms and operational tooling to converge. Hybrid post-quantum migration rewards early, quiet work. The enterprises that begin before 2030 will not just be safer against future decryption. They will have a more agile, measurable cryptographic program that is easier to govern, audit and modernize for whatever comes next.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
No Responses