Mar. 17, 2026
20 minutes read
Share this article
Last Updated July 2026
Every organization running today’s internet is trusting two pieces of math: that factoring large numbers is hard, and that solving elliptic-curve discrete logarithms is hard. RSA, ECDSA, and Diffie-Hellman all rest on those assumptions. A sufficiently large quantum computer running Shor’s algorithm dissolves both of them, and with them the confidentiality and integrity guarantees behind TLS, code signing, VPNs, email, and most of the public-key infrastructure that businesses depend on.
Post-quantum cryptography (PQC) is the field building encryption that stays secure even against a large-scale quantum attacker. It is no longer a research curiosity. In August 2024, the U.S. National Institute of Standards and Technology (NIST) finalized its first three post-quantum standards, turning a decade of competition into concrete, implementable algorithms. Governments have set deprecation deadlines. Google, Cloudflare, Apple, and Signal have already shipped it to billions of users. The question for engineering leaders is no longer whether to migrate, but how fast, in what order, and at what cost.
This guide explains what the quantum threat really is, how the new NIST standards work, the timelines that now carry regulatory weight, who has already crossed over, and a seven-step roadmap your team can start this quarter. It is written for CTOs, VPs of Engineering, and security leaders who need to plan a multi-year cryptographic transition without stalling the rest of the roadmap.
Quantum computers are not just faster than classical computers. They exploit superposition and entanglement to evaluate certain mathematical structures in ways classical machines cannot. Most computation sees no benefit. But a narrow, consequential class of problems, including the ones underpinning public-key cryptography, collapses from practically impossible to merely expensive.
Two quantum algorithms matter for security. Shor’s algorithm, published in 1994, factors integers and computes discrete logarithms in polynomial time. That is fatal for asymmetric cryptography: RSA, ECDSA, ECDH, and finite-field Diffie-Hellman all fall to a large enough quantum machine. These are the algorithms that establish keys and prove identity, so their failure compromises confidentiality and authentication together.
Grover’s algorithm is the quieter threat. It gives a quadratic speedup on brute-force search, which effectively halves the security of symmetric ciphers and hash functions. The practical consequence is manageable: AES-128 drops to roughly 64 bits of quantum security and should be retired, while AES-256 retains about 128 bits and remains safe. Symmetric cryptography survives the quantum era by doubling key length; asymmetric cryptography needs entirely new mathematics.
The reason there is still time to act is that building a machine capable of running Shor’s algorithm at scale is extraordinarily hard. Breaking RSA-2048 is estimated to require several thousand logical qubits, and each logical qubit demands hundreds to thousands of physical qubits wrapped in error correction to stay stable long enough to compute. Today’s largest devices operate at a fraction of that scale with error rates far above the threshold. The engineering gap is real, which is precisely why the window to migrate deliberately still exists, and why closing that window is a planning decision rather than a technical inevitability.
The most misunderstood part of the timeline is that the attack has already begun. Adversaries do not need a working quantum computer today to benefit from one tomorrow. They can record encrypted traffic and stored ciphertext now, archive it, and decrypt it once a cryptographically relevant quantum computer (CRQC) exists. Security researchers call this harvest now, decrypt later, and it means any data with a long confidentiality shelf life, medical records, financial contracts, intellectual property, state secrets is effectively exposed the moment it crosses the wire in RSA- or ECC-protected form.
This reframes the deadline. You are not racing the arrival of quantum computers. You are racing the point at which data you transmit today is still sensitive when those computers arrive. It also changes how you triage. The first assets to protect are not the ones that would be most embarrassing to lose next week, but the ones whose secrecy must survive the longest: long-term contracts, health and genomic data, source code and trade secrets, cryptographic root keys, and anything protected by regulation for a decade or more. A one-week session token is close to irrelevant to a harvest-now attacker; a signing key with a fifteen-year validity is a prime target.
Cryptographer Michele Mosca captured the planning problem in a simple inequality. Let X be how long your data must stay confidential, Y be how long your migration to quantum-safe cryptography will take, and Z be how long until a CRQC exists. If X plus Y is greater than Z, you already have a problem. For an organization protecting data with a ten-year secrecy requirement and a realistic five-year migration, the math demands action well before any quantum computer is publicly demonstrated. That is why the standards, and the deadlines, exist now rather than later.
Post-quantum cryptography refers to classical algorithms, ones that run on ordinary computers, whose security rests on mathematical problems that neither classical nor quantum computers are known to solve efficiently. Instead of factoring or discrete logarithms, these schemes draw hardness from structured lattices, error-correcting codes, hash functions, and multivariate equations. You deploy them on the servers and devices you already own; no quantum hardware is required.
Lattice-based cryptography anchors most of the finalized standards because it offers a strong balance of security confidence and practical performance. The underlying problems, such as finding short vectors in high-dimensional lattices, have been studied for decades and resist both classical and quantum attack. Hash-based signatures take a more conservative route, deriving their security entirely from the properties of cryptographic hash functions, which makes them slower and larger but exceptionally well understood. The reason NIST standardized more than one mathematical family is deliberate: concentrating all trust in a single problem would recreate exactly the fragility the whole exercise is meant to eliminate.
The two terms are constantly confused and mean opposite things in practice. Quantum cryptography, most visibly quantum key distribution (QKD), uses the physics of quantum states to detect eavesdropping, and it requires specialized hardware and dedicated fiber or line-of-sight links. Post-quantum cryptography is pure software and mathematics: it swaps the algorithm, not the infrastructure. NIST, the NSA (whose guidance on QKD is deliberately cautious), and the UK’s National Cyber Security Centre all direct organizations toward post-quantum cryptography rather than QKD for general-purpose security, precisely because it drops into existing protocols and scales without new physical plant.
NIST ran an open, international competition from 2016 to 2024, evaluating 82 initial submissions through multiple public rounds of cryptanalysis. In August 2024, it published the first three finished standards, each renamed from its competition entry to signal that it is now a government standard rather than a candidate.
The length of the process is a feature, not a delay. Cryptographic standards live for decades, so NIST subjected every candidate to sustained public cryptanalysis, and the scrutiny mattered. Several promising submissions were broken during the competition, including SIKE, an isogeny-based scheme that was defeated by a classical attack in 2022 after reaching an advanced round. That failure is the strongest argument for algorithm diversity and hybrid deployment: a scheme can look secure for years and then fall to a single insight. The surviving standards earned their status by withstanding the most concentrated attack effort in the history of public-key cryptography, but no one treats them as beyond future revision.
FIPS 203 defines the Module-Lattice-Based Key-Encapsulation Mechanism, or ML-KEM, derived from the CRYSTALS-Kyber submission. It is the standard most systems will touch first, because it replaces the key exchange inside TLS and other transport protocols. It comes in three parameter sets, ML-KEM-512, 768, and 1024, mapping to increasing security levels. The trade-off is size: an ML-KEM-768 public key is roughly 1,184 bytes and its ciphertext roughly 1,088 bytes, far larger than the tens of bytes an elliptic-curve exchange needs. That size difference is the single biggest engineering consideration in most migrations, because it stresses packet sizes, handshake latency, and constrained devices.
In practice, ML-KEM is rarely deployed alone today. The dominant pattern is a hybrid key exchange that runs an established elliptic-curve exchange and ML-KEM together and combines both shared secrets, so the connection stays secure as long as either component holds. The widely deployed X25519MLKEM768 construction used in modern TLS is exactly this: classical security you already trust, plus post-quantum protection layered on top. For most teams, enabling a hybrid key exchange in the load balancer or TLS termination layer is the fastest, lowest-risk first deployment available.
FIPS 204 defines the Module-Lattice-Based Digital Signature Algorithm (ML-DSA, from CRYSTALS-Dilithium), the primary recommendation for signatures, used for authentication, code signing, and certificates. FIPS 205 defines the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA, from SPHINCS+), which is slower and produces larger signatures but rests only on the security of hash functions, giving a conservative backup whose assumptions are entirely different from the lattice-based schemes. Deploying both families is a hedge: if a future break is found in structured lattices, hash-based signatures are unaffected.
The standards are not finished. NIST selected FN-DSA (from the FALCON submission) for a future FIPS 206 aimed at use cases needing compact signatures, and it is running a fourth round plus an on-ramp competition to standardize additional key-encapsulation mechanisms based on different mathematics, so that a single mathematical breakthrough cannot compromise the whole portfolio. Planning teams should design for algorithm agility rather than betting on one primitive.
| Standard | Algorithm | Based on | Primary use | Mathematical basis |
|---|---|---|---|---|
| FIPS 203 | ML-KEM | CRYSTALS-Kyber | Key encapsulation / exchange | Structured lattices |
| FIPS 204 | ML-DSA | CRYSTALS-Dilithium | Digital signatures (primary) | Structured lattices |
| FIPS 205 | SLH-DSA | SPHINCS+ | Digital signatures (backup) | Hash functions |
| FIPS 206 (draft) | FN-DSA | FALCON | Compact signatures | Structured lattices (NTRU) |
What turned PQC from optional to mandatory for many organizations is a stack of government deadlines that now carry procurement and regulatory weight.
NIST’s draft transition report, IR 8547, lays out the clearest schedule. It signals that the classical algorithms providing 112 bits of security, RSA-2048 and 256-bit elliptic curves among them, will be deprecated after 2030 and disallowed after 2035. Read plainly: systems still relying on RSA or ECC for confidentiality past 2035 will be non-compliant with federal guidance.
The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets parallel expectations for national security systems, standardizing on ML-KEM and ML-DSA with AES-256 and SHA-384, and asking vendors to make quantum-resistant algorithms the default in new software and firmware signing well before a full 2035 transition. On the policy side, the White House Office of Management and Budget memorandum M-23-02 already directs U.S. federal agencies to inventory their cryptographic systems and prepare migration plans, and the UK’s NCSC has published its own migration timelines pointing at 2035 for completion.
Financial regulators are moving in the same direction. Central banks and payment infrastructure bodies have begun publishing quantum-readiness expectations, and standards organizations governing payment card security and PKI are working post-quantum requirements into their roadmaps. The pattern across sectors is consistent: inventory first, hybrid deployment next, full migration by the mid-2030s.
The practical takeaway for private-sector leaders is that these deadlines cascade. If you sell to government, to defense, to regulated finance, or to any customer who does, their compliance clock becomes your compliance clock through contractual and supply-chain requirements. A vendor questionnaire asking about your post-quantum roadmap is no longer hypothetical; it is already appearing in enterprise procurement.
Post-quantum cryptography is not a future deployment. The largest platforms on the internet have already shipped it, which both proves feasibility and quietly resets customer expectations.
Google enabled a hybrid post-quantum key exchange in Chrome and across its services, and has publicly documented why it now uses post-quantum cryptography on internal traffic. Cloudflare reports that a large and growing share of the human-initiated HTTPS traffic crossing its network is already protected by hybrid post-quantum key agreement, and it offers post-quantum connectivity to origin servers by default.
Apple introduced PQ3 for iMessage in 2024, a protocol combining post-quantum and classical key establishment with ongoing rekeying. Signal deployed its PQXDH handshake to add a post-quantum layer to its initial key agreement. Amazon Web Services offers post-quantum TLS across several services, and OpenSSH made a hybrid ML-KEM key exchange its default. The common pattern is hybrid: run a classical and a post-quantum algorithm together so that the connection stays secure as long as either one holds. That hedge is the safest migration posture available today, and it is the one your architecture should adopt first.
The significance for planning is that the ecosystem has already crossed the interoperability threshold. Browsers, servers, cloud providers, and open-source libraries such as OpenSSL now support post-quantum key exchange, which removes the classic chicken-and-egg problem where no one deploys because no one else has. When two endpoints that both support hybrid key agreement connect, the upgrade happens transparently, with no user action and, on modern hardware, no perceptible latency cost. For most organizations, the first post-quantum win is not a research project; it is enabling a configuration option in software you already run and confirming it negotiates correctly.
No sector feels the harvest-now-decrypt-later threat more acutely than financial services. Transaction records, account data, and contracts carry confidentiality requirements measured in decades, which pushes them to the front of any Mosca’s-inequality analysis. At the same time, banks run some of the oldest and most deeply layered technology estates in the economy, where cryptography is embedded in mainframe integrations, payment gateways, hardware security modules, and vendor systems that were never designed to have their algorithms swapped out.
That combination, long data shelf life plus dense legacy dependency, is exactly where a cryptographic inventory pays off and exactly where it hurts. Organizations pursuing banking modernization are discovering that quantum readiness cannot be bolted on late; it has to be folded into the modernization work already underway. The upside is that the two efforts reinforce each other. Rebuilding a payment service or a customer data platform is the natural moment to introduce crypto-agility, replace hardcoded algorithms with a centralized policy layer, and adopt security-by-design practices that make the next algorithm transition a configuration change rather than a re-architecture.
For regulated industries, the lesson is to treat post-quantum migration and modernization as one program rather than two competing line items. Teams that separate them end up paying for the same discovery work twice.
A cryptographic transition is not a patch; it is a multi-year program touching code, infrastructure, vendors, and governance. The following seven steps sequence the work so that the highest-risk data moves first and the organization builds the crypto-agility it will need for the next transition. Teams that treat modernization as an ongoing posture rather than a one-off project tend to absorb this far more smoothly.
The obstacles are real and worth naming so they can be planned around rather than discovered mid-project. The most concrete is size. Post-quantum keys and signatures are substantially larger than their classical counterparts, which inflates handshake sizes, can trigger packet fragmentation, and strains constrained devices and high-throughput systems. Performance is generally acceptable on modern servers but must be measured, not assumed.
The deeper challenge is organizational. Cryptography is embedded in vendor products, cloud services, and libraries you do not control, so migration depends on a supply chain moving in step. Hybrid schemes add implementation complexity and a modest performance cost. And there is genuine, if small, cryptanalytic uncertainty: these algorithms are new, and running a classical algorithm in parallel is the accepted insurance against an unforeseen break. For banks and other institutions carrying decades of legacy systems and modernization debt, the cryptographic inventory alone can surface architecture problems that were easy to ignore until now.
Cost is the question leadership will ask first, and the honest answer is that the largest line item is not licensing or hardware but engineering time spent on discovery and integration. The inventory phase dominates the budget because it is labor-intensive and touches every team. That is also why the cost curve rewards starting early: work spread across several planned years, and folded into modernization that was going to happen anyway, is far cheaper than the same work compressed into a compliance-driven scramble in the early 2030s. A digital transformation program that already includes crypto-agility absorbs the post-quantum transition at a fraction of the standalone cost.
None of this argues for delay. It argues for starting the inventory and the hybrid rollout early, while there is time to move deliberately rather than under a compliance deadline.
For most organizations, the correct first move is not choosing an algorithm. It is discovering where cryptography lives in your systems, because that inventory determines everything that follows and almost always takes longer than expected.
No one can name a date with certainty, and estimates from experts range from roughly a decade to significantly longer. The honest planning answer is that the date does not matter as much as the harvest-now-decrypt-later problem: data you encrypt today can be recorded now and decrypted later, so any information with a long confidentiality requirement is already at risk regardless of when a cryptographically relevant quantum computer actually arrives.
Quantum cryptography, such as quantum key distribution, uses the physics of quantum states and requires specialized hardware and dedicated links. Post-quantum cryptography is ordinary software: new mathematical algorithms that run on the computers you already own and resist attack by quantum machines. NIST and most national security agencies recommend post-quantum cryptography for general use because it drops into existing protocols and scales without new physical infrastructure.
AES-256 is considered quantum-safe. Grover’s algorithm gives only a quadratic speedup against symmetric ciphers, effectively halving the security level, so AES-256 retains roughly 128 bits of security. AES-128 is weakened enough to warrant retirement. The urgent quantum threat is to asymmetric algorithms such as RSA and ECC, which Shor’s algorithm breaks completely, not to properly sized symmetric encryption.
Most large organizations should plan for a multi-year program, commonly cited in the five-to-ten-year range, driven mainly by the size of their cryptographic inventory and their dependence on vendors and legacy systems. Government guidance points at 2035 as a completion target, with deprecation of classical algorithms beginning after 2030, which makes starting the inventory now a practical necessity rather than an early-adopter choice.
A cryptographic inventory is a complete catalog of everywhere your organization uses cryptography: protocols, certificates, keys, libraries, and the algorithms inside third-party products. It matters because you cannot migrate what you cannot see, and cryptography is typically scattered across far more systems than teams expect. The inventory is the foundation of every migration plan and, in practice, the step that consistently takes the longest.
For nearly all organizations, hybrid is the right first step. Running an established classical algorithm alongside a post-quantum one keeps the connection secure as long as either holds, which protects you against both the quantum threat and the small chance of an undiscovered weakness in the newer algorithms. It is the approach the largest platforms have chosen, and it matches how modern TLS is being deployed. Pure post-quantum deployment becomes appropriate later, as the standards accumulate more real-world exposure and as constrained environments make running two algorithms impractical.
The post-quantum transition has crossed from theory into standards, deadlines, and shipped production code. NIST has finalized FIPS 203, 204, and 205; governments have set 2030 and 2035 as the deprecation and disallowance milestones; and the largest platforms on the internet already run hybrid post-quantum key exchange for billions of users. The technology risk is largely retired. What remains is an execution problem, and execution problems reward the organizations that start early.
The right first move is unglamorous: inventory where cryptography lives in your systems, rank assets by data shelf life, and begin a hybrid rollout on the highest-risk paths. Everything else follows from that map. Handled as a deliberate, multi-year modernization effort rather than a last-minute compliance scramble, the migration is entirely manageable, and it builds the crypto-agility your organization will need for the transitions after this one.
Coderio’s Digital Security Studio and legacy migration teams help engineering organizations run cryptographic inventories, design hybrid transition architectures, and modernize the systems where quantum-vulnerable cryptography is buried deepest. If a quantum-readiness assessment is on your roadmap, let’s talk.
Diego Ceballos is CISO at Coderio, with more than 20 years of experience in cybersecurity, auditing, and data protection. Throughout his career, he has specialized in aligning the technical robustness of IT architecture with business objectives; going beyond implementing controls to designing governance strategies, ensuring compliance with complex regulatory frameworks, and optimizing internal audit processes. His focus is on protecting a company's most valuable asset — its information — while keeping operations efficient and secure in a constantly evolving digital ecosystem. As CISO, he oversees Coderio's security posture across its own operations and its client engagements, and writes about emerging security challenges including compliance architecture for regulated industries, post-quantum cryptography, and enterprise risk mitigation.
Diego Ceballos is CISO at Coderio, with more than 20 years of experience in cybersecurity, auditing, and data protection. Throughout his career, he has specialized in aligning the technical robustness of IT architecture with business objectives; going beyond implementing controls to designing governance strategies, ensuring compliance with complex regulatory frameworks, and optimizing internal audit processes. His focus is on protecting a company's most valuable asset — its information — while keeping operations efficient and secure in a constantly evolving digital ecosystem. As CISO, he oversees Coderio's security posture across its own operations and its client engagements, and writes about emerging security challenges including compliance architecture for regulated industries, post-quantum cryptography, and enterprise risk mitigation.
Accelerate your software development with our on-demand nearshore engineering teams.
