Post-quantum cryptography is no longer a research project. It is a configuration task.
Almost every security leader I talk to still carries the old model: a far-off problem, something the standards bodies are 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. Then the math got standardized, the libraries shipped it, the browsers and load balancers and TLS stacks turned it on, and 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 missed that transition because the headline never changed. We are all still waiting on the same hypothetical machine. The work in front of us changed completely.
The real deadline isn't the quantum computer
2030 is the wrong target date, and the reason 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 is 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. In financial services the data has a long shelf life and the regulators have long memories. 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 needs 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.
Three moves, and only the first one is hard
Inventory your crypto. You cannot migrate what you can't see, and 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 a key exchange nobody thinks about. This is the part everyone skips, and it decides whether the rest goes smoothly or becomes a two-year archaeology dig. Treat it like asset management, because that is what it is. You want a cryptographic bill of materials the same way you already (should) have a software bill of materials. Generate it from your build pipeline and dependency graph where you can. 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 means 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 is sitting there unclaimed at most shops.
Track readiness with automation. The signing side is the slower, messier migration: certificates, code signing, the PKI you depend on. That is where you'll spend real engineering time over the next few years, and you do not manage a multi-year migration with a wiki page. Manage it the way you manage patch coverage or vulnerability remediation, with 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, and we serve more than 1,500 of them, your customers' examiners are going to start asking your customers about quantum readiness. That question lands on your security questionnaire shortly after. The organizations that get caught flat are the ones who hear it for the first time with a deal on the line, holding 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 is 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 scramble to invent an answer. They'll export one from a dashboard they already run.
So 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.