Merely a few years ago, when asking about the state of quantum computing or the need for Post-Quantum Cryptography (PQC), the response would usually revolve around the ongoing PQC competition that NIST had brought to life in an attempt to identify algorithms for standardization. In 2022, Cloudflare started experimenting1 with hybrid key agreement on its production edge, though most of the world outside a handful of research labs had barely registered that any of this mattered. The core argument of that work was that organizations needed to start preparing before the standards were finalized, because migrating cryptography in a large enterprise takes years and quantum computers don’t wait for anybody’s roadmap.
Today, those standards are no longer a draft. The algorithms are running in your browser. They are available in AWS, Azure, and Google Cloud. Yet, by most estimates, the vast majority of companies have still done nothing.
This is Part 1 of a 2-part series and focuses on the fundamentals of Post-Quantum Cryptography: the underlying risk, the core concepts, and the current state of standards and deployment.
If you are only looking for the practical enterprise migration playbook, you can start with Part 2. It is designed to be read independently.
This part covers:
If you are already comfortable with the mathematical background, you can skim the first section and jump ahead to Harvest Now, Decrypt Later or PQC Has Moved from Standards to Deployment.
Let us start by looking at quantum computers. These are machines that use qubits and quantum-mechanical effects such as superposition and entanglement to solve certain problems much more efficiently than classical machines. They are not better at everything, but they have the capability to solve some specific problems dramatically faster, and in some important cases exponentially faster, than our current “classical” computers.
To visualize this, we will have a very brief look at something called complexity theory. This is a field focused on classifying mathematical problems based on their difficulty and helps us distinguish between problems that can be solved efficiently and those that become infeasible at scale. This is at the heart of cryptography, because many cryptographic systems rely on problems that are believed to be computationally hard for adversaries, while still being efficient for legitimate users that have the right key.
In the pre-quantum computing era, when we only relied on classical computers, two important problem classes from complexity theory were:
A useful way to think about this is a puzzle: solving it may take a long time, but once someone gives you an answer, verifying whether it is correct can be done quickly.
For cryptography, the key takeaway is not that it relies on NP-problems in general, but that it relies on specific mathematical problems that appear computationally hard to reverse without secret information. In the classical world, this includes problems such as integer factorization and the discrete logarithm problem, which form the basis of much of today’s asymmetric cryptography.
The figure below illustrates this simplified classical view: efficiently solvable problems lie in P, while problems like factoring and discrete logarithms were long treated as computationally hard in practice for classical adversaries and were therefore relied on heavily for classical asymmetric cryptography, such as RSA (named after its creators Rivest, Shamir, and Adleman, and based on the factorization problem) and ECC (Elliptic Curve Cryptography, which is based on the discrete logarithm problem).

Quantum computing, with its quantum-mechanical characteristics, has changed this picture for some problem classes, which is why it has such a significant impact on modern cryptography: problems that were believed to be infeasible for classical computers, such as factoring and discrete logarithms, can become efficiently solvable with the right quantum algorithm.
The figure below shows this conceptual shift: quantum computers expand the set of problems that can be solved efficiently.

The reason factorization and discrete logarithm problems are within the range of quantum computers (inside BQP) is due to a quantum algorithm called “Shor’s algorithm.” This very special algorithm provides an efficient way of solving both of these problems and therefore has a profound impact on most asymmetric cryptography, such as RSA, Diffie-Hellman, and ECC, which all heavily rely on either factorization or discrete logarithm.
In short, today’s classical asymmetric cryptography, which is the basis of all our encryption, key exchanges, and digital signatures, and therefore the foundation of today’s communication security, relies on mathematical problems that a sufficiently large quantum computer could solve efficiently using Shor’s algorithm.
Research suggests that a Cryptographically Relevant Quantum Computer (CRQC) consisting of 20 million noisy qubits could factor RSA-2048 in about 8 hours2. By contrast, classical factoring remains infeasible: modern factorization algorithms, such as RSA-250 already required roughly 2,700 core-years3, and extrapolation to RSA-2048 places the cost in the millions of years. When such a Cryptographically Relevant Quantum Computer becomes available, the asymmetric cryptography that secures TLS, digital signatures, S/MIME, code signing, SSH, VPNs, certificates, and effectively much of today’s secure communication on the internet can no longer be relied on for confidentiality, key exchange, or signatures against a sufficiently capable quantum adversary.
Symmetric cryptography, such as AES and SHA-2/3, is also affected by quantum computers, specifically by Grover’s algorithm, but much less severely than asymmetric cryptography. Grover’s algorithm makes brute-force guessing of secret keys more efficient, but this can generally be mitigated by roughly doubling the key size; for example, using AES-256 instead of AES-128.

As Figure 3 shows, asymmetric cryptography is a much bigger problem: it is not just weakened, but can eventually be broken entirely, regardless of key size, which is why it must be replaced in its entirety by post-quantum cryptography.
That is where post-quantum cryptography comes in. Post-quantum cryptography does not use quantum computers, but is a new generation of cryptography that still runs on ordinary classical computers and is designed around mathematical problems that are believed to remain hard even for quantum adversaries. Instead of relying on factorization or discrete logarithms, these schemes typically rely on lattice-based problems, hash-based constructions, code-based problems, or other families that currently have no known efficient quantum attack comparable to Shor’s algorithm.
In other words, quantum computing changes which mathematical assumptions can still be trusted. Post-quantum cryptography is the effort to replace the vulnerable ones before adversaries gain the capability to break them.
The reason this matters right now, not in ten years, is the “harvest now, decrypt later” threat model. An adversary does not need a quantum computer today for the risk to be relevant. They can record encrypted traffic, exfiltrate encrypted databases, or siphon off certificate-protected backups, store all of it, and wait. When a CRQC becomes available, the contents become readable retroactively. For any data with a meaningful confidentiality lifetime, such as financial records, medical data, legal documents, trade secrets, government communications, intellectual property, or long-lived keys, the quantum threat is already here, even if the machine that exploits it is not.
If your data needs to remain confidential longer than it will take you to migrate, then the quantum threat is already part of your current risk model.
Estimates of when a CRQC will exist vary widely. IBM’s current public roadmap5 targets its first fault-tolerant system, Starling, for 2029 and a 2,000-qubit system, Blue Jay, for 2033+. Separately, Microsoft and Atom Computing reported6 creating and entangling 24 logical qubits, and performing computation on 28 logical qubits, in November 2024. Nobody knows the exact arrival date of a Cryptographically Relevant Quantum Computer, but that uncertainty does not remove the need to prepare. Organizations need to migrate now, because adversaries can already harvest encrypted data. By the time a quantum computer is available, the loss of confidentiality cannot be reversed for data harvested today.
This is the part of the story that has changed most during the past few years.
On 13 August 2024, NIST published the first three finalized post-quantum standards:
A fourth standard, FIPS 206 (FN-DSA, derived from Falcon), is in development, and in March 2025, NIST also selected HQC (Hamming Quasi-Cyclic) as a backup key-encapsulation mechanism on a completely different mathematical basis (code-based cryptography) in case lattice assumptions are ever weakened. NIST’s guidance in their announcement on the first 3 finalized post-quantum standards7 is unambiguous:
“There is no need to wait for future standards. Go ahead and start using these three.”
NIST (Aug 13, 2024)
The “we are waiting for the standards” argument stopped being valid in August 2024.
Governments have moved beyond general warnings and are now attaching concrete timelines to the transition to post-quantum cryptography. The table below summarizes the main timelines:
| Country | Institution/Document | What it is | Timeline |
|---|---|---|---|
| European Union | European Commission Recommendation (EU) 2024/1101 and NIS Cooperation Group roadmap | A non-binding EU recommendation, supported by an NIS Cooperation Group roadmap, that sets the main milestones for coordinated PQC transition across Member States. | End of 2026: begin national transition, establish initial PQC roadmaps, and start pilots for higher-risk use cases End of 2030: migrate high-risk use cases and critical infrastructure 2035: complete the transition as broadly as practicable |
| United States | NSA (CNSA 2.0) | NSA guidance for National Security Systems. It sets quantum-resistant algorithm requirements and concrete migration deadlines. | 2026: support and prefer quantum-safe software and firmware signing 2030: exclusive use for software and firmware signing 2033: migration target for web browsers and cloud services Similar timelines: traditional network equipment and operating systems |
| United States | White House (National Security Memorandum 10) | U.S. federal policy direction for post-quantum migration. It sets the broader federal target for reducing quantum risk. | 2035: goal for federal migration of quantum risk as far as feasible |
| United Kingdom | NCSC | The UK’s national technical authority for cybersecurity. It sets a phased migration path for organizations. | 2028: discovery and planning 2031: early migration 2035: full rollout |
ENISA and ETSI are important supporting institutions in the European transition. ENISA helps turn the policy push into technical guidance and implementation-focused analysis, while ETSI develops standards and migration-oriented technical work for deployment and interoperability. That matters because PQC is no longer just a standards debate or a future policy objective; it is increasingly being translated into practical engineering guidance across Europe. Similar roles are also played by bodies such as the IETF, ISO/IEC, and national cybersecurity agencies including BSI, ANSSI, and the UK NCSC.
Governments are no longer treating PQC as a research topic, but as a transition program with timelines.
On the deployment side, the major infrastructure providers moved first and fast, and the numbers speak for themselves. Cloudflare began offering hybrid post-quantum key agreement on all zones in October 2022, went to general availability in September 2023, and by May 2026 reported that over two-thirds8 of all human-generated HTTPS traffic reaching its network was protected by TLS 1.3 with hybrid ML-KEM key exchange (advertised in the TLS handshake as X25519MLKEM768). That is a remarkable statistic: a very substantial portion of the web is already post-quantum secure at the key-agreement layer, and most users have no idea.

That happened because the browsers moved with it. Chrome, Edge, and Firefox all ship hybrid post-quantum key agreement by default in current versions. If you are reading this in a modern browser, there is a very good chance the connection you used to load the page was negotiated using a hybrid ML-KEM key exchange.
You can verify this yourself by doing a right-click -> Inspect -> Security in your browser tab (steps vary depending on browser), and you should see something like Figure 4:

The cloud providers are on the same trajectory:
A significant part of internet-facing key agreement is already moving to post-quantum or hybrid protection.
A notable pattern across all of these deployments is the use of hybrid key agreement: the post-quantum algorithm is combined with an existing classical one (typically X25519), so that the connection remains at least as secure as it is today even if an unforeseen weakness in the post-quantum algorithm were discovered later. This precaution is recommended by several national authorities, including Germany’s BSI and France’s ANSSI, which recommend or support hybrid approaches during migration. The UK NCSC allows hybrid use too, but explicitly frames it as an interim measure on the way to PQC-only deployment.
The reason the identifier is called X25519MLKEM768 rather than a pure MLKEM768 (the name of the PQC Algorithm) is due to the combination with a classical algorithm (X25519) to achieve hybrid key agreement.

The practical takeaway is clear: the internet edge and commodity cloud services are moving, the algorithms are production-grade, and key agreement on the public web is no longer the main blocker. What is not solved, and where a great deal of work remains, is post-quantum authentication (signatures and certificates), which is harder to deploy because it touches the entire PKI and, more importantly for this discussion, the internal infrastructure and data storage of every organization that isn’t AWS, Microsoft, or Google.
A few years ago, the standard answer to questions about PQC was that the field was still waiting for NIST standardization. That was true, but it also understated the problem. The question was never whether the algorithms would arrive, which they have, or whether the infrastructure layer would deploy them, which it has. The question is whether the thousands of organizations whose entire business runs on top of that infrastructure will do the unglamorous, expensive, internal work of finding their own cryptography, understanding it, and building the architectural flexibility to replace it.
The standards are final. The algorithms run in every major browser and cloud. The guidance from governments is extensive and consistent. The tooling exists. The deadlines are on calendars. And yet, by the industry’s own numbers, most organizations have not started.
In August 2024, the window for “we’ll wait for the standards” closed. What is open now is the window for building the cryptographic visibility and agility that every organization is going to need eventually, and will definitely need by the middle of the next decade.
This organizational effort is the focus of Part 2, which will be released soon. If Part 1 establishes that the quantum risk is real, that HNDL already matters, and that deployment has already begun, then Part 2 addresses the practical question that follows: what should an organization actually do about it?
For convenience, the main acronyms used throughout this article are summarized below:
| Acronym | Meaning | Why it matters here |
|---|---|---|
| BQP | Bounded-Error Quantum Polynomial Time | A complexity class used to describe problems that quantum computers can solve efficiently with low error probability. |
| CRQC | Cryptographically Relevant Quantum Computer | A quantum computer large enough to break today’s public-key cryptography in practice. |
| ECC | Elliptic Curve Cryptography | Public-key cryptography based on discrete logarithm problems on elliptic curves. |
| FIPS | Federal Information Processing Standards | The formal NIST standard documents for algorithms such as ML-KEM, ML-DSA, and SLH-DSA. |
| HNDL | Harvest Now, Decrypt Later | The risk that encrypted data stolen today may be decrypted in the future. |
| KEM | Key Encapsulation Mechanism | A mechanism for securely establishing shared keys; ML-KEM is NIST’s main PQC KEM standard. |
| ML-DSA | Module-Lattice-Based Digital Signature Algorithm | NIST’s primary post-quantum signature standard, derived from Dilithium. |
| ML-KEM | Module-Lattice-Based Key-Encapsulation Mechanism | NIST’s primary post-quantum standard for key establishment, derived from Kyber. |
| PKI | Public Key Infrastructure | The certificates, keys, and trust relationships used for authentication and secure communication. |
| PQC | Post-Quantum Cryptography | Cryptography designed to resist quantum attacks while running on classical computers. |
| RSA | Rivest-Shamir-Adleman | A widely used public-key algorithm based on integer factorization. |
| S/MIME | Secure/Multipurpose Internet Mail Extensions | A protocol for sending digitally signed and encrypted messages. |
| SLH-DSA | Stateless Hash-Based Digital Signature Algorithm | A hash-based post-quantum signature standard, derived from SPHINCS+. |
| HQC | Hamming Quasi-Cyclic | A code-based post-quantum key encapsulation mechanism selected by NIST as a backup KEM on a different mathematical foundation than ML-KEM. |
Senior Consultant Security Operations Engineering
Sven-Christian Kruse is a Senior Consultant within NVISO’s Security Operations Engineering team. His work focuses on the design and implementation of practical security engineering capabilities, supported by his background in cryptography-related roles. He also maintains an interest in quantum computing and post-quantum cryptography.