There's a question almost no leadership team asks yet, and it should be on the agenda of any risk committee that takes medium-term security seriously: what happens to the data we're encrypting today, ten years from now?
It's not rhetorical. It's the foundation of everything in this article.
The problem isn't the present — it's the past someone is storing
The asymmetric cryptography powering nearly all of today's digital infrastructure — RSA, Diffie-Hellman, elliptic curves (ECC) — relies on mathematical problems that are extremely hard to solve with classical computers. Factoring a 2048-bit number into primes, for instance, would take longer than the age of the universe with today's classical computing power.
The problem is that those same mathematical problems stop being hard against a sufficiently powerful quantum computer. In 1994, mathematician Peter Shor published an algorithm — Shor's algorithm — that, run on a quantum computer with enough stable logical qubits, would break RSA and ECC in polynomial time. Fast, in other words.
The honest question, as of this article, is: does that computer exist yet? No. Current quantum systems don't yet have the scale or the low enough error rate to run Shor's algorithm against real-world key sizes in a practical timeframe. But that's not fully reassuring, for one very concrete reason.
"Harvest now, decrypt later": the attack that's already happening
You don't need a functional quantum computer today for the risk to be real today. It's enough for an adversary — a nation-state actor, a well-resourced competitor, an intelligence agency — to be capturing and storing encrypted traffic right now, intending to decrypt it later, once quantum technology matures.
This strategy has a name: harvest now, decrypt later. And it's not a paranoid lab theory. It's an explicit concern of agencies like the NSA (which issued post-quantum migration guidance back in 2022) and of NIST itself, which accelerated its standardization process precisely for this reason.
The question we ask every client when assessing their exposure isn't "are you afraid of quantum computing?" It's this: what data do you encrypt today that needs to stay confidential 10 or 15 years from now?
Think about:
- Medical records and genetic data.
- Diplomatic or national security communications.
- Long-lived trade secrets (patents in development, formulas, proprietary algorithms).
- Financial data with long-term regulatory confidentiality obligations.
- Identities and communications of journalistic sources or political dissidents.
If anything you encrypt today needs to stay secret a decade from now, that data is already at risk — not because someone can decrypt it today, but because it might already be stored, waiting.
What NIST has done about it
In August 2024, after nearly eight years of public evaluation with dozens of proposals from around the world, NIST published the first three official post-quantum cryptography standards:
- FIPS 203 (ML-KEM, based on Kyber): a key encapsulation mechanism, the post-quantum replacement for Diffie-Hellman/RSA in establishing shared keys.
- FIPS 204 (ML-DSA, based on Dilithium): a digital signature scheme, the post-quantum replacement for RSA/ECDSA signatures.
- FIPS 205 (SLH-DSA, based on SPHINCS+): a second signature scheme, based on hash functions instead of lattices, intended as a conservative fallback in case a mathematical weakness is ever found in lattice-based schemes.
This matters: it's not that post-quantum cryptography vaguely "exists" in an experimental state somewhere. There are official, published standards, with audited reference implementations, production-ready. The "wait and see" window has already closed from a technical standpoint.
Why Kyber and Dilithium (and not something else)
Both rely on the hardness of certain problems over lattices — mathematical structures in high-dimensional spaces. The reason these problems resist both classical and quantum computers, as far as we currently know, is that there's no known quantum algorithm (like Shor's for factoring) that solves them efficiently.
It's worth being honest here: "as far as we currently know" isn't an absolute mathematical guarantee — it's the current state of cryptanalytic knowledge. That's why NIST keeps a backup scheme (SPHINCS+) with entirely different mathematical foundations — if a weakness is ever found in lattices, the whole building doesn't collapse at once.
Kyber, specifically, has a significant practical advantage: keys and ciphertexts are relatively compact compared to other candidate post-quantum algorithm families (code-based or isogeny-based ones), which makes it viable for protocols we already use today — TLS, SSH, VPNs — without a prohibitive performance cost.
What "migrating" actually means in practice
This is where most guides stay abstract. In practice, a serious post-quantum migration goes through several phases, and none of them is "swap RSA for Kyber everywhere next month":
1. Cryptographic inventory. Most organizations have no idea where they use which algorithm. TLS on the web server is the visible part; there's encryption in databases, backups, internal VPNs, device firmware, and third-party integrations you don't even directly control.
2. Classification by sensitivity and lifespan. Not everything needs protection against a future quantum adversary. Data that loses its value in two years isn't in the same risk category as an industrial secret that must stay confidential for twenty.
3. Hybrid cryptography as an intermediate step. The dominant technical recommendation today (and the one we follow at NyxqLab) isn't to swap the classical algorithm for the post-quantum one outright, but to use hybrid schemes: combining, for example, X25519 (classical) with Kyber (post-quantum) in the same key exchange. That way, for an attacker to break the session, they need to break both schemes — if Kyber had an unknown weakness today, the classical component still protects; if a quantum computer broke the classical component, Kyber still protects.
4. Prioritization by real exposure, not by trend. The first thing we migrate with a client isn't the most visible system — it's whatever combines the longest confidentiality lifespan with the highest exposure to interception and storage (traffic crossing public networks, for example, versus already-segmented internal traffic).
What post-quantum cryptography is not
Two frequent confusions are worth clarifying, because we run into them constantly in sales conversations with clients who've already talked to other vendors:
- It's not "quantum encryption" or "quantum key distribution" (QKD). That's a different technology, using physical properties of quantum mechanics to transmit keys, requiring specialized hardware (dedicated fiber optics or satellites), and it's not what most companies need or can deploy. The post-quantum cryptography discussed here is pure software: mathematical algorithms that run on classical hardware and resist quantum attacks.
- It's not "more secure" in the sense of "more bits, stronger." It resists a different kind of attack. A poorly implemented post-quantum algorithm remains vulnerable to the same old errors: bad key management, side channels, implementation bugs.
The cost of doing nothing
If your organization handles data that needs long-term confidentiality — and most of the ones we've audited do, even if they hadn't framed it this way — the cost of inaction isn't abstract. It's the cost that, a decade from now, information you consider protected today will stop being so, with no way to retroactively fix what's already been captured.
A well-executed post-quantum migration isn't an overnight infrastructure revolution. It's a risk-based prioritization process you can start today without breaking what already works.
Frequently asked questions
Does quantum computing already break the encryption I use today?
No, not yet. There is no quantum computer with enough stable logical qubits to break RSA-2048 or ECC in a practical timeframe. The risk isn't today — it's that data captured today gets decrypted in 10-15 years.
Which post-quantum algorithms should I use?
NIST has standardized Kyber (ML-KEM, FIPS 203) for key exchange and Dilithium (ML-DSA, FIPS 204) for digital signatures. These are our default recommendation unless your sector requires something else.
Do I have to migrate everything at once?
No, and you shouldn't try. Migration is prioritized by data sensitivity and lifespan: whatever needs confidentiality beyond 2035 goes first.
Need help with this?
Message us on WhatsApp