Quantum computers capable of running Shor's algorithm at scale don't exist yet, but the encrypted data flowing through backend systems today is already exposed to future attacks. This article explains why RSA and ECC are at risk, what Post-Quantum Cryptography (PQC)actually is, the new NIST-approved standards, and the concrete architectural changes engineering teams should plan for now from crypto-agility to hybrid key exchange.
Why Today's Encryption Won't Last Forever
Quantum computing is coming for the cryptography stack most backend systems already rely on. TLS, key management, and data-at-rest encryption all lean on public-key cryptography such as RSA and ECC. Both work because certain mathematical problems are easy to compute in one direction and, for classical computers, practically impossible to reverse.
It's worth being clear about what"secure" actually means here: encryption doesn't make data unreachable in some absolute sense. It simply makes reaching it expensive enough that no rational attacker bothers. Break-even is the whole game, not an unbreakable wall.
In 1994, Shor's algorithm demonstrated that a sufficiently powerful quantum computer could break that one-way assumption for RSA and ECC, turning a problem that takes billions of years into one that takes hours. The hypothetical date this becomes real has a name: Q-Day - the day today's public-key encryption stops actually protecting anything.
This only threatens public-key cryptography(RSA, ECC, Diffie-Hellman). Symmetric encryption such as AES barely notices quantum computers; Grover's algorithm only gives a quadratic speed-up against it, soAES-256 stays comfortably strong. The real emergency is on the key exchange and signature side and this is exactly where Post-Quantum Cryptography (PQC) comes in.
What Is"Harvest Now, Decrypt Later"?
Quantum computers capable of running Shor's algorithm at scale don't exist yet, but that isn't a reason to wait. Harvest Now, Decrypt Later attacks are already happening:adversaries record encrypted traffic today and decrypt it the moment a capable quantum computer exists. If your sensitive data like financial records, health data, government communications needs to stay secret for years, it's already exposed.
What Is Post-Quantum Cryptography?
Post-Quantum Cryptography vs Quantum Key Distribution
A common mix-up is worth clearing up first. PQCis not Quantum Key Distribution (QKD), which uses quantum mechanics itself (photons and specialised detectors) to exchange keys. QKD needs dedicated hardware and isn't practical for most systems.
PQC is the opposite: new classical algorithms that run on the hardware already in use, built on mathematical problems that are hard for classical and quantum computers alike.
The Lattice-Based Approach
The main new approach is lattice-based cryptography. Picture a massive grid of points with one specific point hidden deep inside it. Finding that point without being told where to look is extraordinarily hard, and unlike prime factoring, no one has found a quantum shortcut for it. That assumption underpins most of the new standards.
RSA's problem is a single path, reverse it and you're done. A lattice problem is a tangle of equally plausible paths, and the right one looks identical to all the wrong ones until it's already known.That's what makes the new mathematics heavier: not a harder single step, but a search space with no shortcut through it.
Is My Data at RiskRight Now?
Yes, if it needs to remain confidential for several years. Nothing encrypted today can be decrypted by existing computers, but "harvest now, decrypt later" means intercepted traffic can sit in storage until a capable quantum computer arrives. Data with a short shelf life is lower risk; whereas long-lived sensitive data like contracts, medical records, national security information, should be treated as exposed already.
The New NIST Standards
NIST ran a multi-year public competition and finalised its first standards in 2024: a key exchange algorithm (ML-KEM)and two signature algorithms (ML-DSA and SLH-DSA). A third signature scheme selected during the competition (FN-DSA) is currently being drafted, and NIST recently added a structurally different backup key exchange algorithm (HQC).
ML-KEM and ML-DSA are on track to become the long-term defaults. OpenSSL, BoringSSL, major browsers, and cloud key management providers are already rolling out support, though most production systems still default to classical algorithms today. Within a few years,"which cipher suite are we using" becomes an active decision again. See NIST's Post-Quantum Cryptography programme for the full standards timeline.
What Does This Mean for Backend Architecture?
Swapping cryptographic algorithms isn't a one-line change. TLS actually performs three separate jobs, and PQC only disrupts two of them.
Authentication and Key Exchange
Authentication and key exchange(RSA/ECDSA, ECDHE) both rely on the mathematics Shor's algorithm breaks, so both need to move to quantum-resistant alternatives (ML-DSA, ML-KEM).
Bulk Encryption Stays the Same
Bulk encryption (AES-GCM, ChaCha20-Poly1305)isn't meaningfully threatened, since Grover's algorithm only gives a quadratic speed-up there. In short, this is a key exchange and signature migration, not are write of the entire encryption stack. RSA/ECC is only ever used to agree on a secret; it's too slow for bulk work, which is why AES handles the actual encrypting.
Bigger Keys, Bigger Handshakes
PQC keys and signatures are meaningfully larger than what engineering teams are used to.
That's not a rounding difference, it changes how much data has to travel over the wire on every handshake. A larger handshake is invisible on a single web request but adds up quickly for high-frequency service-to-service calls, mobile clients on weak networks, or IoT devices. Benchmark this rather than assume it's free.
Crypto-Agility Matters More Than the Algorithm Itself
The most important shift for engineers: stop hard-coding specific algorithms. Systems that treat the algorithm as a configuration setting rather than a fixed assumption can adopt new standards with a deploy, not a rewrite. This is the real insurance policy here, since no one can pin down Q-Day's timeline with confidence.
Hybrid Deployment Is the Current Default
Almost no organisation is jumping straight toPQC-only. The current pattern is hybrid key exchange: run a classical algorithm (X25519) and a post-quantum one (ML-KEM) together, deriving the session key from both. If either one holds, the connection stays secure. Expect this to be the default deployed, not classical or PQC alone.
Do I Need to Replace AES Encryption?
No. AES-256 is not meaningfully weakened by quantum computing. Grover's algorithm only offers a quadratic speed-up, which AES-256's key length already accounts for. The migration effort belongs entirely on the public-key side: key exchange and digital signatures, not bulk data encryption.
What Can Engineering Teams Do Today?
Quantum computers capable of breaking RSA andECC at scale aren't here yet, but data encrypted today doesn't get a grace period. Three practical starting points:
• Inventory where encryption, key exchange, and signing happen across the stack.
• Push for crypto-agility in system design reviews so algorithms can be swapped without a rewrite.
• Watch core frameworks (Java, .NET, OpenSSL) for PQC rollout and default-setting changes.
For engineering teams managing this kind of migration across distributed systems, having dedicated development teams with deep backend and security expertise available as capacity is added makes the transition considerably easier to plan around, particularly when crypto-agility work has to run alongside regular delivery commitments.
Conclusion
The future of computing is exciting, and backend systems need to be ready for it. Post-Quantum Cryptography isn't a distant, theoretical concern, it's a migration that's already begun across browsers, cloud providers, and core frameworks. Teams that build crypto-agility into their architecture now, rather than treating algorithms as fixed, will be the ones that adapt with a configuration change rather than a scramble.
AtCreative Software, our engineering teams work on exactly this kind of forward- looking backend and security work as part of the extended development teams we build for product companies across Scandinavia and Europe. If you'd like to discuss how a similar setup could support your engineering roadmap, our SalesDirector, Mikael Stattin, is happy to jump on a quick 15-minute call to walkthrough the practicalities.