Every security leader I talk to has the same mental model of post-quantum cryptography: it's a far-off problem, a research problem, something the standards bodies are still arguing about, and we'll get to it when there's an actual quantum computer that can break RSA. That model was right for about a decade. It is now wrong, and the gap between that outdated instinct and where the tooling actually sits is exactly where the risk lives.
Here's the reframe. PQC is no longer a research project. It's a configuration task. The math got standardized, the libraries shipped it, the browsers and load balancers and TLS stacks turned it on, and somewhere along the way the hard part quietly moved from "invent quantum-resistant crypto" to "know what crypto you're actually running and flip the right flags." Most organizations skipped that transition because the headline never changed — we're still all waiting on the same hypothetical quantum computer. But the work in front of you changed completely.
The real deadline isn't the quantum computer
The reason 2030 is the wrong target date is harvest now, decrypt later. An adversary doesn't need a quantum computer that works in 2030 to hurt you with one. They need to capture your encrypted traffic in 2026 and sit on it. Anything you transmit today that's still sensitive in ten years — account data, identity documents, anything covered by a long-tail regulatory obligation — is already exposed to a threat that hasn't technically arrived yet. In financial services, where the data has a long shelf life and the regulators have long memories, that's not a hypothetical. The confidentiality clock started the moment the packet left your edge.
So the question isn't "when will quantum break this." It's "how much of what I send today do I need to stay secret long enough for quantum to matter." For most of us serving regulated industries, the honest answer is: a lot of it. That moves the work into the present tense.
What the work actually is
Strip away the cryptography mystique and the migration is three things, and only the first one is hard.
Inventory your crypto. You cannot migrate what you can't see. Most teams have no real map of where RSA and ECDSA live — which TLS endpoints, which internal service mesh links, which signing keys, which embedded library three dependencies deep is doing key exchange you never think about. This is the part everyone skips and the part that determines whether the rest goes smoothly or becomes a two-year archaeology dig. Treat it like asset management, because that's what it is. You want a cryptographic bill of materials the same way you already (should) have a software bill of materials. Where you can generate it from your build pipeline and dependency graph, do that — a CBOM you regenerate on every build beats a spreadsheet someone updates once a quarter and then never again.
Flip on post-quantum TLS where it already exists. This is the part that surprises people. Hybrid key exchange — pairing a classical algorithm with ML-KEM so you're protected even if one side has a flaw — is already live in mainstream TLS stacks and major cloud load balancers and CDNs. For a large share of your externally-facing traffic, turning on post-quantum protection is a matter of enabling a setting on the termination point, not rewriting an application. If you terminate TLS at a managed load balancer or a CDN, you may be one configuration change away from closing the harvest-now-decrypt-later window on your highest-volume traffic. That is an absurdly good return on effort, and it's sitting there unclaimed at most shops.
Track readiness with automation. The signing side — certificates, code signing, the PKI you depend on — is the slower, messier migration, and it's where you'll spend real engineering time over the next few years. You don't manage a multi-year migration with a wiki page. You manage it the way you manage patch coverage or vulnerability remediation: an automated, continuously-refreshed view of what percentage of your estate is quantum-ready, what's still on legacy algorithms, and which systems are blocking progress. Build the dashboard before you need to report from it.
Build the evidence before the regulator asks
And someone will ask. The standards are finalized, the federal guidance has put migration timelines in writing, and in regulated industries the regulatory expectation always trickles down to the vendors. If you serve financial institutions — we serve more than 1,500 of them — your customers' examiners are going to start asking your customers about quantum readiness, and that question is going to land on your security questionnaire shortly after. The organizations that get caught flat are the ones who hear that question for the first time when a deal is on the line and have no inventory, no dashboard, and no answer beyond "we're aware of it."
This is the same dynamic I keep coming back to: the value isn't in being secure, it's in being provably ready, on demand, under questioning. PQC readiness is about to become a line item in due diligence. The teams that started early won't be scrambling to invent an answer — they'll be exporting one from a dashboard they already run.
So here's the challenge. Don't budget post-quantum as a 2030 program. Budget it as three near-term moves: a cryptographic inventory you can actually trust, post-quantum TLS turned on everywhere your stack already supports it, and an automated readiness view you can show someone without preparing for a week. None of that requires a breakthrough. It requires deciding the deadline is now, because for the data you're sending tonight, it already is.
