Post-quantum cryptography

Quantum computing has spent years moving between hype, laboratory progress and strategic anxiety. It promises major advances in simulation, optimization, chemistry, materials science and certain forms of computation. But for cybersecurity, its most disruptive consequence is narrower and more immediate: a sufficiently capable quantum computer could break the public-key cryptography that protects much of the modern internet.

This does not mean that every password, file and message is automatically exposed. It does not mean that quantum computers can already break the internet. It means that the mathematical assumptions behind many widely used public-key systems are no longer safe as long-term foundations.

Post-quantum cryptography, usually shortened to PQC, is the response to that risk. It is the development and deployment of cryptographic algorithms designed to remain secure against both classical computers and future quantum computers.

The phrase can sound futuristic, but the practical work is already happening. Standards have been finalized. Migration roadmaps exist. Governments and large organizations are beginning to inventory cryptographic assets. Vendors are testing hybrid key exchange. Security teams are asking a difficult question: what encrypted data must remain confidential for ten, twenty or thirty years?

That question matters because the quantum threat is not only about the day a cryptographically relevant quantum computer appears. It is also about what adversaries can collect before that day arrives.

The real threat is long-term exposure

The most important concept in post-quantum security is not “Q-Day” as a dramatic single event. It is long-term exposure.

Many forms of sensitive data lose value quickly. A one-time login session, a short-lived transaction or a temporary API token may not matter years later. But other data remains valuable for decades: state secrets, health records, legal documents, biometric information, intellectual property, financial archives, defense communications, source code, identity records and confidential business negotiations.

This creates the “harvest now, decrypt later” problem.

An attacker does not need a quantum computer today to create a future breach. They can capture encrypted traffic now, store it, and wait. If the encryption depends on RSA or elliptic-curve key exchange, and if the underlying keys or session secrets become recoverable in the future, old communications may become readable.

This is why post-quantum cryptography is urgent even before quantum computers reach the necessary scale. The migration timeline must be compared not only with quantum hardware timelines, but also with the required confidentiality lifetime of the data.

If a dataset must remain secret for twenty years, then waiting ten years to migrate may already be too late.

Why RSA and elliptic-curve cryptography are vulnerable

Most internet security relies on two broad categories of cryptography.

The first is symmetric cryptography, where the same secret key is used to encrypt and decrypt data. Examples include AES-based encryption. The second is public-key cryptography, where a public key and a private key work together. Public-key cryptography enables secure key exchange, digital signatures, certificates, identity verification and many forms of secure communication at scale.

Quantum computing threatens these categories differently.

The biggest problem is public-key cryptography based on integer factorization and discrete logarithms. RSA depends on the difficulty of factoring large integers. Elliptic-curve cryptography depends on the difficulty of solving elliptic-curve discrete logarithm problems. Classical computers struggle with these problems at modern security sizes.

A sufficiently powerful quantum computer running Shor’s algorithm would change that. It could solve the mathematical problems that make RSA and elliptic-curve systems secure. That would endanger TLS handshakes, digital signatures, code signing, VPN authentication, certificate infrastructures, secure email, cryptocurrency wallets and many identity systems.

Symmetric cryptography is not destroyed in the same way. Grover’s algorithm can reduce the effective security margin of symmetric keys, but the usual response is to use larger key sizes. In simplified terms, AES-256 remains a much stronger long-term choice than AES-128 in a quantum-aware environment. Hash functions also require careful parameter choices, but the public-key side is the area requiring the most dramatic redesign.

That is why PQC focuses so heavily on key encapsulation mechanisms and digital signatures.

What post-quantum cryptography actually means

Post-quantum cryptography does not mean using quantum hardware to secure communications. That is a different field, usually associated with quantum key distribution.

PQC means classical cryptographic algorithms that run on ordinary computers but are designed to resist known attacks from both classical and quantum computers.

This distinction matters. PQC can be deployed in software, firmware, browsers, servers, mobile devices, cloud systems and embedded environments. It can be integrated into existing protocols such as TLS, SSH, IPsec, code-signing systems and certificate infrastructures. It does not require every organization to install quantum communication links.

In practice, PQC is a migration of algorithms, protocols, certificates, libraries and operational processes.

The goal is not to make systems “quantum-proof” in some absolute sense. Cryptography never works that way. The goal is to replace vulnerable mathematical assumptions with better-studied alternatives that are believed to be resistant to known quantum attacks.

The NIST standards changed the timeline

For years, many organizations treated post-quantum cryptography as something to monitor but not yet implement. The argument was simple: without finalized standards, early adoption could create compatibility problems or force expensive rework.

That changed in August 2024, when NIST released its first three finalized post-quantum cryptography standards. These are FIPS 203, FIPS 204 and FIPS 205. FIPS 203 specifies ML-KEM, based on CRYSTALS-Kyber, for general encryption and key establishment. FIPS 204 specifies ML-DSA, based on CRYSTALS-Dilithium, for digital signatures. FIPS 205 specifies SLH-DSA, based on SPHINCS+, also for digital signatures and intended as a backup approach using different mathematical foundations.

This was a major turning point. Organizations no longer need to wait for the first standards to exist. They can begin structured migration planning around named algorithms and standard documents.

NIST has also selected HQC as an additional post-quantum encryption algorithm to serve as a backup for ML-KEM. HQC is based on different mathematics, specifically error-correcting codes, and NIST described it as a second line of defense in case future analysis finds weaknesses in ML-KEM. A draft standard for HQC is expected before final standardization.

The practical implication is clear: migration should begin with the finalized standards, especially ML-KEM for key establishment and ML-DSA for signatures, while organizations continue tracking additional standards as the ecosystem matures.

The main families of post-quantum algorithms

PQC is not one algorithm. It is a landscape of mathematical approaches. Each family has advantages, trade-offs and deployment challenges.

Lattice-based cryptography

Lattice-based cryptography is currently the most important PQC family for general deployment. ML-KEM and ML-DSA both come from this area. Lattice-based schemes are attractive because they offer strong performance, relatively practical key sizes and good suitability for internet protocols.

ML-KEM is designed for key establishment. It helps two parties agree on a shared secret across an insecure channel. In practical terms, this makes it relevant to TLS, VPNs and other secure communication protocols.

ML-DSA is designed for digital signatures. It helps prove that a message, certificate, software update or transaction was authorized by the holder of a private key.

The main challenge with lattice-based cryptography is implementation discipline. Efficient implementations must avoid side-channel leaks, timing weaknesses, poor randomness and subtle parameter mistakes. A mathematically strong algorithm can still fail if implemented badly.

Hash-based signatures

Hash-based signatures are one of the oldest and most conservative post-quantum approaches. SLH-DSA, based on SPHINCS+, is standardized by NIST as FIPS 205. Its strength is conceptual simplicity and reliance on hash functions, which are well-studied cryptographic building blocks.

The trade-off is performance and signature size. Hash-based signatures can be larger and slower than lattice-based alternatives. They may not be the first choice for every high-volume application, but they provide valuable diversity because they are based on different assumptions.

This diversity matters. A healthy cryptographic ecosystem should not depend entirely on one mathematical family.

Code-based cryptography

Code-based cryptography relies on the hardness of decoding error-correcting codes. This family has a long history and is attractive because some code-based assumptions have been studied for decades.

HQC, selected by NIST as a future backup encryption algorithm, belongs to this broad area. NIST emphasized that HQC is based on different mathematics from ML-KEM and can provide fallback resilience if future cryptanalysis weakens the main lattice-based path.

The drawback is that code-based schemes often have larger keys or greater bandwidth demands. That does not make them impractical everywhere, but it does affect where and how they can be deployed.

Multivariate cryptography

Multivariate schemes are based on the difficulty of solving systems of multivariate polynomial equations. They have historically been explored for digital signatures.

This area has produced interesting candidates, but it has also seen important cryptanalytic breaks over time. That does not mean the whole family is useless, but it does show why standardization must be cautious. PQC is not about choosing exotic mathematics because it sounds secure. It is about surviving years of public analysis.

Isogeny-based cryptography

Isogeny-based cryptography was once attractive because of its compact key sizes. However, the field suffered a major loss of confidence after serious attacks broke prominent candidates in the standardization process. It remains an area of academic interest, but it is not the main practical migration path today.

This is an important lesson for PQC generally. New cryptography should not be deployed casually. Algorithms need time, open scrutiny and conservative engineering before they protect critical infrastructure.

Why migration is harder than it sounds

Replacing RSA and elliptic-curve cryptography is not like updating one application.

Cryptography is everywhere, and often invisible. It appears in web servers, browsers, load balancers, cloud APIs, identity providers, mobile apps, hardware security modules, payment terminals, smart cards, industrial control systems, firmware updates, software package managers, container registries, VPNs, SSH keys, S/MIME, code signing, document signing, device certificates, Wi-Fi authentication, IoT provisioning and blockchain systems.

Many organizations do not know where all their cryptography is.

That is the first problem. Before migration, there must be discovery. Security teams need a cryptographic inventory: what algorithms are used, where they are used, what systems depend on them, how long keys live, which certificates exist, what vendors are involved and what data needs long-term protection.

This is often called cryptographic asset management. Without it, post-quantum migration becomes guesswork.

The second problem is compatibility. A PQC-enabled server is not useful if clients cannot negotiate the same algorithms. A new certificate type is not useful if relying systems cannot validate it. A quantum-safe protocol is not useful if old devices cannot be updated.

The third problem is size. PQC public keys, ciphertexts and signatures are often larger than classical equivalents. This can affect bandwidth, latency, memory, packet fragmentation, certificate chains, embedded devices and constrained networks.

The fourth problem is operational risk. Cryptographic migrations can break systems. A rushed migration can create outages. A poorly tested implementation can introduce vulnerabilities. A migration that ignores compliance requirements can create audit problems.

The irony is obvious: a security upgrade can become a security incident if handled badly.

Hybrid cryptography as a transition strategy

For the next phase, many systems will use hybrid cryptography.

A hybrid scheme combines a classical algorithm with a post-quantum algorithm. The idea is to preserve current trust in classical cryptography while adding protection against future quantum attacks. If one component fails, the other may still protect the session, depending on the design.

The European Commission’s recommendation explicitly refers to deployment through hybrid schemes that may combine post-quantum cryptography with existing cryptographic approaches or with quantum key distribution.

Hybrid deployment is attractive because it reduces the risk of betting everything on new algorithms too early. It also allows gradual testing in real systems. However, hybrid cryptography adds complexity. More complexity means more implementation risk, more interoperability testing and more careful protocol design.

The transition period will therefore be messy. For some time, classical, hybrid and fully post-quantum systems will coexist.

Europe’s coordinated roadmap

Post-quantum migration is not only a technical issue. It is also a policy and infrastructure issue.

The European Commission published a recommendation in April 2024 encouraging Member States to develop coordinated strategies for adopting post-quantum cryptography. The stated goal was a synchronized transition among Member States and their public sectors, with clear goals, milestones and timelines.

In June 2025, the EU published a coordinated implementation roadmap as a high-level paper for Member States. It includes recommendations for a synchronized transition and measures to ensure that stakeholders understand the quantum threat to cryptography.

The recommendation also stresses cross-border interoperability, cooperation with cybersecurity experts and ENISA, and the evaluation and adoption of appropriate PQC algorithms as EU standards.

This matters for Poland and the wider EU because public administration, health systems, finance, telecoms, energy infrastructure, identity systems and cross-border public services cannot migrate in isolation. A fragmented transition would create interoperability failures and uneven security.

PQC is therefore becoming part of digital sovereignty and critical infrastructure planning.

What should organizations do first?

The first step is not buying a “quantum-safe” product.

The first step is understanding exposure.

A serious PQC readiness program should begin with several practical actions.

Build a cryptographic inventory

Organizations need to identify where public-key cryptography is used. This includes certificates, TLS configurations, SSH keys, VPNs, APIs, databases, backup systems, code-signing pipelines, firmware signing, mobile applications, third-party integrations and cloud-managed cryptographic services.

The inventory should answer:

• what algorithm is used,
• where it is used,
• who owns the system,
• how long the data must remain confidential,
• whether the system can be updated,
• which vendor controls the component,
• and what would break if cryptography changed.

Without this map, migration becomes reactive.

Prioritize long-lived sensitive data

Not every system has the same urgency. A public website serving non-sensitive content does not have the same risk profile as encrypted medical archives, defense communications or long-term legal records.

The highest priority should go to systems where confidentiality must survive into the future. This includes traffic vulnerable to harvest-now-decrypt-later attacks.

Test hybrid TLS and PQC libraries

Organizations should begin controlled testing with PQC-capable libraries, test environments and vendor-supported implementations. The goal is not to replace all production cryptography overnight. The goal is to understand performance, compatibility, certificate behavior, logging, monitoring and failure modes.

Update procurement requirements

Many organizations will not implement cryptography directly. They will inherit it through vendors. Procurement teams should therefore ask vendors about PQC roadmaps, standards alignment, upgrade paths, hardware dependencies, certificate support and cryptographic agility.

A system purchased today may still be in production in 2035. If it cannot support PQC migration, it may become a future liability.

Design for cryptographic agility

Cryptographic agility means systems can change algorithms without major redesign.

This is essential. PQC will continue to evolve. Some algorithms may be replaced. Parameters may change. New standards may appear. Organizations that hard-code cryptographic assumptions into long-lived systems will suffer during migration.

Agility should be built into protocols, APIs, key management systems, certificate handling and software update processes.

Practical applications of PQC

Post-quantum cryptography will affect almost every area of digital security, but several domains are especially important.

Secure web communication

TLS is one of the most visible migration targets. Browsers, servers, CDNs, cloud providers and certificate authorities will need to support post-quantum key exchange and eventually post-quantum authentication. Hybrid key exchange is likely to remain important during the transition.

Email and messaging

Email encryption, secure messaging and enterprise communication tools must consider long-term confidentiality. Some messages may be sensitive for years. The challenge is not only message encryption, but also identity, signatures, device keys and backup recovery.

Code signing and software updates

Digital signatures protect software supply chains. If a signing algorithm becomes vulnerable, attackers may be able to forge updates, packages, drivers or firmware. This makes post-quantum signatures critical for operating systems, app stores, embedded devices, automotive systems and industrial equipment.

IoT and embedded systems

IoT migration is difficult because devices often have limited memory, processing power and update mechanisms. Some devices remain deployed for many years with weak patching support. PQC algorithms must therefore be evaluated carefully for constrained environments.

Financial systems and blockchain

Banks, payment networks and trading systems rely heavily on authentication, signatures and secure channels. Blockchain systems face additional complexity because public keys and signatures may be permanently visible on-chain. Migration planning must consider both future transactions and already exposed cryptographic material.

Mobile and telecom networks

5G, future 6G systems, SIM infrastructure, device authentication, roaming, lawful interception safeguards and telecom backbone encryption all rely on complex cryptographic ecosystems. PQC migration in telecoms will require coordination between vendors, operators, regulators and standards bodies.

Government and critical infrastructure

Public administration, energy, water, transport, defense, healthcare and emergency systems hold data with long confidentiality lifetimes. They also depend on legacy systems. These sectors need early planning because procurement cycles and infrastructure replacement cycles are slow.

Common mistakes in PQC planning

The first mistake is waiting for quantum computers to become dangerous before starting migration. By that time, old encrypted data may already have been harvested, and large organizations may not have enough time to replace vulnerable systems.

The second mistake is treating PQC as a single product. No vendor can magically make an organization quantum-safe. The problem is architectural.

The third mistake is ignoring signatures. Many discussions focus on encryption, but signatures are equally important. Certificates, software updates, documents, firmware and identity systems all depend on signature schemes.

The fourth mistake is assuming that all PQC algorithms are interchangeable. They differ in key size, signature size, speed, maturity, implementation complexity and security assumptions.

The fifth mistake is forgetting legacy systems. The hardest systems to migrate are often not the newest cloud services, but old appliances, embedded devices, industrial systems and internal applications nobody wants to touch.

The sixth mistake is failing to test performance. Larger keys and signatures can affect real systems in unexpected ways.

The seventh mistake is poor randomness and implementation security. Even strong algorithms can be broken by bad random number generation, timing leaks, memory errors or side-channel vulnerabilities.