Post-Quantum Cryptography (2026): Preparing for the End of RSA and ECC

Post-Quantum Cryptography
For decades, modern cybersecurity has relied on a handful of cryptographic foundations. Technologies such as RSA and Elliptic Curve Cryptography (ECC) protect everything from online banking and VPNs to software updates and digital signatures. These algorithms have withstood years of scrutiny and remain secure against conventional computers.
However, the emergence of quantum computing presents a challenge unlike any previous advancement in computing power. While today’s quantum computers are not yet capable of breaking widely deployed cryptographic systems, researchers have demonstrated that sufficiently powerful quantum computers could render many of our most trusted encryption and digital signature schemes obsolete.
This looming threat has given rise to a new field known as Post-Quantum Cryptography (PQC).
What Is Post-Quantum Cryptography?
Post-Quantum Cryptography refers to cryptographic algorithms designed to remain secure against both classical and quantum computers.
Unlike quantum cryptography, which relies on quantum mechanical principles and specialized hardware, PQC algorithms are implemented in software and can run on conventional computer systems. The goal is to replace vulnerable public-key cryptographic systems while maintaining compatibility with existing infrastructure.
The challenge is significant. Much of modern public-key cryptography relies on mathematical problems that are extremely difficult for classical computers but could be solved efficiently by a large-scale quantum computer.
Why Quantum Computers Threaten Current Cryptography
Most current public-key cryptography depends on the computational difficulty of problems such as:
- Integer factorization / prime numbers (used by RSA)
- Discrete logarithms (used by Diffie-Hellman)
- Elliptic curve discrete logarithms (used by ECC)
In 1994, mathematician Peter Shor developed an algorithm that demonstrated how a sufficiently powerful quantum computer could solve these problems exponentially faster than classical computers.
As a result, algorithms including:
- RSA
- Diffie-Hellman
- Elliptic Curve Cryptography (ECC)
- ECDSA
- ECDH
would become vulnerable once practical cryptographically relevant quantum computers emerge. Note, as of Q2, 2026, we don’t have those quantum computers, yet.
Symmetric cryptography such as AES and cryptographic hash functions are less affected. While quantum algorithms may reduce their effective security margins, increasing key sizes generally provides an adequate defense.
Harvest Now, Decrypt Later
One of the most significant concerns is not future communications but communications happening today.
Adversaries can collect and store encrypted traffic now, even if they cannot decrypt it. Once sufficiently powerful quantum computers become available, they may be able to decrypt archived communications that were protected using vulnerable algorithms. In the meantime, storage manufacturer stock prices will go up.
This threat is commonly referred to as “Harvest Now, Decrypt Later” (HNDL).
Organizations handling long-lived sensitive information — including government agencies, healthcare providers, financial institutions, and critical infrastructure operators — must consider whether data encrypted today will still require protection decades into the future.
A few years ago, one may have worried about whether information placed on a public blockchain via an Ethereum DApp (or similar technology) might one day have be decrypted due to obsolete encryption algorithms. This is a slight variation of that problem. The process is being sped up by a dramatic leap forward in hardware / algorithm capabilities.
Regardless, it does add a new dimension to concerns around hostile actors monitoring your network traffic.
NIST and the Standardization of PQC
Recognizing the need for quantum-resistant cryptography, the National Institute of Standards and Technology (NIST) launched a multi-year effort to evaluate and standardize post-quantum algorithms.
After years of analysis and international review, several algorithms emerged as leading candidates.
- ML-KEM (formerly CRYSTALS-Kyber): Primary replacement for RSA key transport and Elliptic Curve Diffie-Hellman.
- ML-DSA (formerly CRYSTALS-Dilithium): Digital signature algorithm.
- SLH-DSA (Formerly SPHINCS+): Hash-based signature scheme.
ML-KEM (Formerly CRYSTALS-Kyber)
ML-KEM is a key encapsulation mechanism used for establishing shared secrets over untrusted networks.
It is designed to replace traditional key exchange mechanisms such as RSA key transport and Elliptic Curve Diffie-Hellman.
ML-KEM is currently considered the primary standard for quantum-resistant key establishment.
This is published as the NIST 203 standard. You can find the published NIST standard here.
ML-DSA (Formerly CRYSTALS-Dilithium)
ML-DSA is a digital signature algorithm designed to replace RSA and ECDSA signatures.
It offers strong security, efficient performance, and broad applicability across software and infrastructure environments.
This is published as the NIST FIPS204 standard. You can find the published NIST standard here.
SLH-DSA (Formerly SPHINCS+)
SLH-DSA is a hash-based signature scheme that provides a different security foundation than lattice-based algorithms.
Although signatures tend to be larger, hash-based cryptography offers an additional level of diversity and confidence.
This is published as the NIST FIPS205 standard. You can find the published NIST standard here.
How Post-Quantum Algorithms Work
Many PQC algorithms rely on mathematical problems that are believed to be resistant to both classical and quantum attacks.
These include:
- Lattice-based cryptography
- Hash-based cryptography
- Code-based cryptography
- Multivariate polynomial cryptography
- Isogeny-based cryptography
Among these approaches, lattice-based cryptography has emerged as the leading candidate due to its balance of security, efficiency, and practical deployment characteristics.
The mathematical structures involved are significantly different from the number-theory foundations of RSA and ECC. While the details can be complex, the key takeaway is that no efficient quantum algorithms are currently known for solving these problems.
TLS Support
PQC support in Transport Layer Security (TLS) is one of the biggest ongoing changes to internet security. The goal is to protect TLS connections against future quantum computers that could break widely used public-key algorithms such as RSA and elliptic-curve cryptography (ECC). Modern TLS v1.3 typically uses:
- Key exchange: ECDHE (e.g., X25519, P-256)
- Authentication: RSA or ECDSA certificates
A sufficiently large quantum computer running Shor’s algorithm could break:
- RSA
- Diffie-Hellman
- Elliptic Curve Diffie-Hellman
- ECDSA
This would allow attackers to:
- Recover private keys
- Decrypt recorded traffic
- Impersonate servers
The “harvest now, decrypt later” threat is particularly concerning because encrypted traffic captured today could be decrypted years from now if quantum computers become capable enough.
How PQC Fits Into TLS
There are two major areas:
Key Exchange
Today:

Today — Key Exchange
Post-quantum:

Post-Quantum — Key Exchange
But most deployments currently use:

Hybrid(Today, Mostly)-Key Exchange
This is called a hybrid key exchange.
The session key is derived from both:
- Classical ECDHE
- PQC ML-KEM
An attacker must break both mechanisms to recover the session key.
This is the preferred migration path.
Certificates and Signatures
Today certificates commonly use:
- RSA
- ECDSA
Future certificates may use:
- ML-DSA
- SLH-DSA
However, deployment of PQC signatures is lagging behind key exchange because:
- Signature sizes are larger
- PKI infrastructure changes are significant
- Browser and CA ecosystems require updates
Most near-term deployments focus first on hybrid key exchange.
Current TLS Standards Activity
The Internet Engineering Task Force has been developing TLS extensions for PQC.
The leading deployment model is X25519MLKEM768, which combines:
- X25519 ECDHE
- ML-KEM-768
This hybrid approach has become the de facto first-generation PQC TLS deployment.
Browser and Vendor Support
Major vendors have already begun deployment. This blog post isn’t even going to attempt to cover every vendor / product status for PQC adoption, but this section gives you an idea.
Google has conducted large-scale experiments with:
- CECPQ1
- CECPQ2
- X25519Kyber768
- ML-KEM hybrids
Chrome and Google services have been among the earliest large-scale PQC TLS adopters.
You can learn more at the Google Chrome Security Blog.
Cloudflare
Cloudflare PQC Resources
Cloudflare has enabled PQC support across much of its network and offers hybrid TLS options.
AWS
AWS has been testing and introducing PQC support across selected services and cryptographic libraries.
You can learn more at the AWS Cryptography Blog.
Microsoft
Microsoft has integrated PQC support into various cryptographic initiatives and Windows-related tooling.
You can learn more at the Microsoft Security Blog.
OpenSSL Support
Recent OpenSSL versions are adding support through:
- OpenSSL 3.x
- OQS-OpenSSL provider integrations
- Open Quantum Safe project
The most common test configuration today involves X25519MLKEM768 rather than pure ML-KEM.
Performance Impacts
Using PQC algorithms in TLS introduces tradeoffs, like everything in life. On the one-hand, the advantages are:
- Resistance to known quantum attacks
- Addresses harvest-now-decrypt-later risks
On the other-hand, one has the following challenges:
- Larger public keys
- Larger ciphertexts
- Larger signatures
- Increased TLS handshake sizes
The bandwidth increase is noticeable but generally manageable for modern internet infrastructure.
Migration Challenges
Migrating to post-quantum cryptography is not simply a matter of swapping one algorithm for another.
Organizations must consider:
- Larger key and signature sizes.
- Legacy infrastructure.
- Cryptographic agility.
- Hybrid cryptography.
- Regenerating all keys and certificates
Larger Key and Signature Sizes
Many PQC algorithms require larger public keys, ciphertexts, and signatures than their classical counterparts.
This can affect:
- Network bandwidth
- Storage requirements
- Embedded systems
- IoT devices
In the meantime, if you can’t regenerate your keys / certs immediately, simply increasing the key size may be an acceptable risk mitigation in the short-term to medium-term.
Legacy Infrastructure
Many applications, protocols, and hardware security modules were designed around RSA and ECC.
Upgrading these systems may require:
- Software updates
- Firmware updates
- Hardware replacements
- Certificate infrastructure changes
Cryptographic Agility
Organizations should strive for cryptographic agility, which is the ability to replace cryptographic algorithms without redesigning entire systems.
Systems built with agility in mind will be better positioned to adapt as standards evolve.
Hybrid Cryptography
Many organizations are adopting hybrid approaches during the transition period.
A hybrid key exchange might combine:
- ECDH (classical)
- ML-KEM (post-quantum)
The connection is considered secure if either component remains secure.
This approach provides protection against both current and future threats while organizations gain confidence in newly standardized algorithms.
Regenerating All Keys and Certificates
Once all of your platforms support PQC algorithms, you will still have to regenerate all of the key pairs (keys and certificates) and other key material to be able to use the new algorithms. This could be accomplished by simply rolling out the needed changes over the course of normal certificate renewals. Of course, that has to line up with the adoption timeline, but with a bit of planning can work out.
What Organizations Should Do Today
While large-scale quantum computers capable of breaking RSA and ECC do not yet exist, preparation should already be underway.
Recommended actions include:
- Inventory cryptographic assets.
- Identify systems using RSA and ECC.
- Assess long-term data confidentiality requirements.
- Build cryptographic agility into applications and supporting infrastructure.
- Evaluate support for NIST-standardized PQC algorithms.
- Develop migration roadmaps.
- Monitor guidance from standards organizations and vendors.
- Upgrade products, patches, firmware, etc to get to versions of products that support PQC algorithms.
- Regenerate key pairs using PQC algorithms.
Organizations that begin planning now will be better prepared for a transition that could ultimately affect nearly every digital system in operation.
WebSphere DataPower’s PQC Support
This is the shameless product plug.
If you’ve been reading my posts for a while, then you may recall that before I switched my career focus to application security and identity, I was a DataPower consultant. I read the release notes and blog posts about what is changing in the DataPower space. Not so long ago, IBM announced PQC support for Websphere Datapower.
IBM is also promoting a pattern wherein DataPower is installed on the edgee of your network and serves as an entry point for all external traffic to your network. In this way, your network, at least, has outward-facing support for PQC inflight encryption.
Eventually, you’ll have to address the full data center / network’s PQC capability, but this could be a useful stop-gap solution in the short-term.
Conclusion
Post-Quantum Cryptography represents one of the most significant transformations in the history of cybersecurity. The widespread deployment of RSA and ECC has protected the Internet for decades, but advances in quantum computing are forcing the industry to prepare for a new era.
The transition will take years, perhaps decades, to fully complete. Fortunately, standardized post-quantum algorithms are now available, allowing organizations to begin evaluating and deploying quantum-resistant solutions today.
The quantum threat may not arrive tomorrow, but the systems being designed and deployed today will likely still be operating when it does. Organizations that invest in post-quantum readiness now will be in a far stronger position to protect their data, systems, and customers in the years ahead.
Notes
- AI / GenAI / ChatGPT / etc were not used to generate the text of this article.
- ChatGPT was used to generate the images.
- I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now.
- Names have been changed to protect the guilty.
- None of the hostnames or users used in examples actually exist.
- Feel free to post any comments or suggestions below.
Originally published on Medium.