Quick answer: There is no quantum computer today that breaks RSA or ECC in practice, so panic is unwarranted. But the real risk is "harvest now, decrypt later" (HNDL): encryption carrying data that must stay secret for years (health, legal, government, intellectual property) can be broken in the future. The right move is not panic but preparation: migrating to the post-quantum algorithms NIST standardized in 2024 (ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures). The first step is to enable hybrid key exchange in TLS 1.3 (classic plus ML-KEM together) and build a crypto inventory. Long-lived secrets set the priority.

The narrative that quantum computers threaten encryption has circulated for years and is usually either exaggerated or dismissed entirely. Both are wrong. This guide explains, from an expert perspective, what the threat really is today, NIST's new standards, and the concrete, non-inflated steps an organization should take starting now.

The real threat: HNDL (harvest now, decrypt later)

Today's asymmetric encryption (RSA, ECC/elliptic curve) can be broken by a large error corrected quantum computer running Shor's algorithm. No such machine exists yet and when it will is uncertain. So your TLS sessions today are secure today.

The real problem is on the time axis. An attacker (especially at nation state level) can store encrypted traffic crossing the network today, or stolen encrypted archives, and decrypt them retroactively when quantum capability matures. So data you send today but that must stay secret for 10 to 15 years is at risk starting today. This is the HNDL attack. Negligible for short lived secrets (a session cookie); for long lived secrets (patient records, legal archives, state secrets, long term intellectual property) it is a threat worth acting on today.

Symmetric encryption (AES) and hash functions (SHA-2/3) are much more resistant to quantum; Grover's algorithm only halves the effective key length, so AES-256 stays secure in practice. The breakage risk is in asymmetric key exchange and signatures.

NIST post-quantum standards (2024)

After a long evaluation, NIST published the first post-quantum standards in 2024. Three are foundational:

Standard Algorithm Job Basis
FIPS 203 ML-KEM (Kyber) key encapsulation/exchange lattice
FIPS 204 ML-DSA (Dilithium) digital signature lattice
FIPS 205 SLH-DSA (SPHINCS+) digital signature hash based

ML-KEM is the main mechanism that will replace classic key exchange in protocols like TLS. ML-DSA is the primary signature standard; SLH-DSA offers a more conservative, hash based backup signature (diversity in case the lattice assumption weakens later). These algorithms have larger key/signature sizes than the classic ones, so migration requires performance and compatibility testing.

First concrete step: hybrid TLS 1.3

The most practical start is to enable hybrid key exchange in TLS 1.3, which carries web traffic. Hybrid uses a classic curve (for example X25519) and post-quantum ML-KEM at the SAME time; the session key is derived from the combination of both. That way, even if one is broken in the future, the other protects, and backward compatibility is not broken. Modern browsers and servers support these hybrid groups (for example X25519MLKEM768).

On the web this is usually enabled at the CDN/edge layer; providers like Cloudflare support hybrid post-quantum TLS and enabling it at the edge is usually a single setting. We covered edge configuration in our Cloudflare security configuration article. For SSH connections too, post-quantum key exchange (for example sntrup761x25519) is available in modern OpenSSH versions; an up to date client/server already negotiates hybrid PQ.

Crypto agility and inventory

The real lesson of the PQC migration is not swapping a single algorithm but crypto agility: designing your systems so they can easily change the algorithm they use. Because standards evolve, one may weaken, a new one arrives.

The practical roadmap is this. First, build a crypto inventory: which system, which protocol, which algorithm, which key lifetime. Then prioritize by risk: systems that carry long lived data and will stay up for a long time first. Then start with hybrid TLS/SSH and expand toward signature and certificate infrastructure. This discipline also aligns with compliance frameworks; we covered the governance and audit side in our ISO 27001 and SOC 2 comparison article and continuity planning in our business continuity and disaster recovery article.

What not to do: panic and "your own algorithm"

There are two common mistakes. The first is panic: RSA/ECC are not broken today, replacing all infrastructure overnight is unnecessary and risky. The second is using non standard or your own "quantum resistant" encryption design; designs that have not passed expert cryptographic review are almost always weaker. The right path is to use NIST standard algorithms, with mature libraries, in hybrid mode. Be skeptical of claims that market non standard crypto as "strong".

The KAOS and DSET approach

At DSET we begin an organization's crypto agility journey with inventory and risk prioritization: which data is long lived and under HNDL risk, which system can move to hybrid TLS/SSH today. We believe not in the inflated "quantum is coming, change everything now" narrative but in a measured, standards based roadmap. The KAOS tool we develop flags weak or old TLS/encryption configurations, non standard crypto claims and certificate weaknesses during a scan. To assess your organization's post-quantum readiness, contact DSET with our team at Ankara Hacettepe Teknokent. We also examined the modern crypto on the authentication side in our two factor authentication and passkey article.

Frequently asked questions

When will a quantum computer break RSA, should I migrate immediately? There is no quantum computer today that breaks RSA/ECC in practice and when there will be is uncertain, so no panic. But if you carry data that must stay secret for a long time, the HNDL risk begins today. First build an inventory, prioritize systems carrying long lived secrets, and start with hybrid TLS. You do not need to change all infrastructure overnight.

What does hybrid key exchange mean, why not just classic? Hybrid uses a classic algorithm (for example X25519) and post-quantum ML-KEM at the same time and derives the session key from the combination of both. That way, even if one is broken in the future, the other protects and backward compatibility is not broken. Rather than moving to pure post-quantum alone, hybrid is the safest and most practical choice for today.

Are my AES and passwords at risk too? Symmetric encryption (AES) and hash functions are much more resistant to quantum; Grover's algorithm only halves the effective key strength, so AES-256 stays secure in practice. The real risk is in asymmetric key exchange (RSA/ECC) and signatures. For password security the real issue is not quantum but strong hashing and good password hygiene.

Sources