Post-Quantum Cryptography: Why Your RSA Keys Are Already Living on Borrowed Time

In our last post, we covered AES and RSA — the two pillars of modern encryption. Here's the uncomfortable follow-up: one of those pillars has an expiration date, and it's earlier than most developers think.

NIST has finalized new encryption standards, governments have published binding migration deadlines, and major browsers already encrypt most of your traffic with algorithms you've probably never heard of. This isn't a future problem. It's a 2026 engineering problem, and it's already showing up in TLS handshakes you use every day.

---

The Threat, In One Sentence

A sufficiently powerful quantum computer will be able to break RSA and ECC — the asymmetric encryption behind HTTPS, SSH, and most digital signatures — by solving the math problems they rely on almost instantly.

Nobody has built that computer yet. Estimates for when a "cryptographically relevant quantum computer" (CRQC) might exist range widely, with most serious projections landing sometime in the 2030s. So why is 2026 the year everyone suddenly cares?

Because of one specific attack pattern: Harvest Now, Decrypt Later.

---

Harvest Now, Decrypt Later (HNDL)

This is the idea that makes "quantum computers don't exist yet" a useless excuse:

2026: Attacker intercepts and stores your encrypted traffic
      (they can't decrypt it — yet)
        ↓
2026-2035: Attacker just... waits
        ↓
203X: A cryptographically relevant quantum computer arrives
        ↓
203X: Attacker decrypts everything they harvested years ago

You don't need to be a target of a future attack — you're a target of a present-day one, quietly happening now, with the payoff deferred. If the data you're encrypting today needs to stay confidential for more than a few years — medical records, IP, source code, government or legal data — the question isn't "will quantum computers ever exist." It's "does my data's confidentiality lifetime outlast the time it takes a quantum computer to arrive." For a lot of organizations, the honest answer is no — which is exactly why intelligence agencies and financial institutions are the earliest movers here.

---

What NIST Actually Standardized

After a multi-year public competition — the same format that gave us AES in the early 2000s — NIST finalized its first three post-quantum cryptography standards:

A fourth, FIPS 206 (FN-DSA, based on FALCON), was expected to follow later in 2026 for use cases needing smaller signatures.

Both ML-KEM and ML-DSA are lattice-based — their security rests on math problems (like finding short vectors in high-dimensional lattices) that remain hard even for quantum computers, unlike the factoring and discrete-log problems RSA and ECC depend on. SLH-DSA takes a different, more conservative approach based purely on hash functions, trading larger signature sizes for an extra layer of confidence.

---

Why This Isn't "Just Swap the Algorithm"

If you've read our AES/RSA piece, you know the drill: generate a key pair, call encrypt, call decrypt, done. Post-quantum migration is a different beast entirely.

1. The keys and signatures are bigger — a lot bigger

That size difference isn't cosmetic. Protocols, packet size assumptions, embedded systems with tight memory budgets, and hardware security modules built around RSA-sized keys all need to be re-evaluated.

2. Hybrid deployment is the current best practice

Nobody serious is ripping out classical crypto and replacing it with pure PQC overnight. The recommended approach is hybrid: combine a classical algorithm with a post-quantum one, so you're protected even if either one turns out to have a flaw nobody's found yet.

Traditional key exchange:  X25519 (classical, well-tested)
                                  +
Post-quantum key exchange: ML-KEM-768 (new, quantum-resistant)
                                  ↓
                     Combined shared secret

If ML-KEM has an undiscovered weakness, X25519 still protects you. If a quantum computer breaks X25519, ML-KEM still protects you. This is exactly what Cloudflare, Google, and Apple have already rolled out at scale — a large share of browser traffic to major CDNs is now protected by hybrid post-quantum key exchange, even though most users have no idea.

3. Crypto-agility becomes an architectural requirement

The single biggest lesson from the PQC transition: hardcoded cryptography is a liability. Systems built so that swapping an algorithm means touching one config value — not rewriting application logic — are the ones migrating smoothly. Systems with RSA calls scattered across the codebase are the ones facing years of remediation work.

# ❌ Hardcoded, not crypto-agile
def encrypt_session_key(data, rsa_public_key):
    return rsa_public_key.encrypt(data, padding.OAEP(...))

# ✅ Crypto-agile: algorithm resolved via policy, not hardcoded
def encrypt_session_key(data, key_provider: KeyExchangeProvider):
    return key_provider.encapsulate(data)

# key_provider might resolve to RSA, ML-KEM, or a hybrid combiner
# depending on a central policy — no application code changes needed

---

Code Example: Hybrid Key Exchange (Conceptual)

Post-quantum primitives are landing in mainstream libraries now (liboqs, OpenSSL 3.x with the OQS provider, and Python bindings like oqs-python). Here's what a hybrid handshake looks like conceptually:

# Illustrative — real usage depends on your library of choice
from oqs import KeyEncapsulation
from cryptography.hazmat.primitives.asymmetric import x25519

def hybrid_key_exchange_client():
    # Classical half
    classical_private = x25519.X25519PrivateKey.generate()
    classical_public = classical_private.public_key()

    # Post-quantum half
    pq_kem = KeyEncapsulation("ML-KEM-768")
    pq_public_key = pq_kem.generate_keypair()

    # Both public values get sent to the server
    return {
        "classical_public": classical_public,
        "pq_public_key": pq_public_key,
        "classical_private": classical_private,  # kept secret
        "pq_kem": pq_kem,                          # kept secret
    }

def combine_secrets(classical_shared_secret, pq_shared_secret):
    """Combine both secrets into one session key (simplified)"""
    import hashlib
    return hashlib.sha384(classical_shared_secret + pq_shared_secret).digest()

The combined secret is only as weak as its strongest component being broken — which, by design, requires breaking both algorithms simultaneously.

---

The Timeline You Actually Need to Track

Deadlines vary by country and industry, but the direction is consistent everywhere: classical public-key crypto is being formally phased out on a fixed schedule, not left to organizations' discretion indefinitely.

2024 ── NIST finalizes FIPS 203, 204, 205
2026 ── Federal agencies (US) begin binding PQC migration deadlines
         for high-value assets; national PQC strategies due in the EU
2027 ── NSA's CNSA 2.0 mandates PQC for new national security systems
2029-30 ── Major vendors (Cloudflare, etc.) targeting full PQC readiness;
            RSA-2048 / ECC P-256 deprecated in NIST guidance
2031 ── US federal deadline for post-quantum digital signatures/certs
2035 ── Quantum-vulnerable algorithms fully removed from NIST standards;
         EU medium-risk use cases expected to complete migration

The realistic timeline to migrate a large enterprise is measured in years, not a quarter. That's the actual reason 2026 matters — not because quantum computers arrived, but because the runway to migrate safely is long enough that starting now is the only way to beat the deadline.

---

A Practical First Step: The Cryptographic Inventory

Every migration guide agrees on the starting point, and it's not buying a new library — it's figuring out where you're already exposed.

# Simplified example: scanning a codebase for classical crypto usage
# that will need review before a PQC migration

import re
from pathlib import Path

CLASSICAL_CRYPTO_PATTERNS = {
    "RSA": r"\brsa\.(generate_private_key|encrypt)\b",
    "ECDSA": r"\bec\.(generate_private_key|ECDSA)\b",
    "ECDH": r"\bec\.(ECDH|exchange)\b",
}

def scan_for_classical_crypto(directory: str) -> dict:
    findings = {algo: [] for algo in CLASSICAL_CRYPTO_PATTERNS}

    for path in Path(directory).rglob("*.py"):
        content = path.read_text(errors="ignore")
        for algo, pattern in CLASSICAL_CRYPTO_PATTERNS.items():
            if re.search(pattern, content):
                findings[algo].append(str(path))

    return findings

# Usage
results = scan_for_classical_crypto("./src")
for algo, files in results.items():
    if files:
        print(f"{algo} found in {len(files)} file(s):")
        for f in files:
            print(f"  - {f}")

Run something like this (or a proper SCA/crypto-discovery tool) across your codebase, your TLS configs, your certificate authorities, your embedded firmware, and your HSMs. You cannot migrate what you haven't inventoried.

---

Protocols Most at Risk (Prioritize These)

Not everything needs equal urgency. Focus first on the protocols where public-key cryptography is doing the heavy lifting:

---

Common Misconceptions

Myth: "Quantum computers don't exist, so I have time."

Reality: Harvest Now, Decrypt Later means your risk window started the moment your data was encrypted, not the moment a quantum computer exists. If your data's confidentiality lifetime is longer than the migration timeline, you're already exposed.

Myth: "AES is quantum-vulnerable too, right?"

Reality: No — this is a common mix-up. Quantum computers threaten asymmetric cryptography (RSA, ECC) far more severely than symmetric cryptography (AES). Grover's algorithm gives quantum computers a quadratic speedup against AES, which is why the practical response is simply doubling key size (AES-256 instead of AES-128) — not replacing the algorithm.

Myth: "This is only a government/defense problem."

Reality: Regulatory pressure is real, but the underlying math doesn't care about your industry. Healthcare records, source code, M&A communications, and any data with a multi-year confidentiality requirement are exposed regardless of sector.

Myth: "Quantum Key Distribution (QKD) is the real solution."

Reality: QKD requires specialized hardware and dedicated physical links between two points, which doesn't scale to internet-wide use. The standardized, deployable path is NIST's mathematical PQC algorithms (ML-KEM, ML-DSA), not QKD.

---

A Six-Step Migration Playbook

Based on the joint guidance coming out of NIST, CISA, and NSA, a credible enterprise PQC migration looks roughly like this:

1. Inventory — Find every place classical public-key crypto is used: TLS, SSH, code signing, VPNs, certificates, embedded firmware.
2. Prioritize — Rank by data sensitivity and confidentiality lifetime. Long-lived secrets go first.
3. Adopt crypto-agility — Refactor so algorithms are swappable via configuration, not hardcoded.
4. Pilot hybrid deployments — Test ML-KEM + classical combinations in non-production environments first.
5. Migrate high-risk assets — TLS termination points, VPNs, and long-term signing infrastructure first.
6. Monitor vendor readiness — Your migration is capped by your slowest dependency; track whether your libraries, HSMs, and cloud providers support PQC yet.

---

Quick Reference Checklist

• Cryptographic inventory completed across code, infra, and certificates
• Data classified by confidentiality lifetime (HNDL exposure assessed)
• Crypto-agility introduced — no hardcoded algorithm calls in critical paths
• TLS termination points tested with hybrid ML-KEM key exchange
• Code-signing pipeline evaluated for ML-DSA / SLH-DSA migration
• Vendor and library PQC support tracked (OpenSSL, cloud KMS, HSMs)
• Migration roadmap has a realistic multi-year timeline, not a single sprint
• AES key sizes reviewed (256-bit preferred for long-lived data)

---

Conclusion

Key takeaways:

1. The risk isn't "quantum computers exist" — it's "your data outlives the migration." Harvest Now, Decrypt Later makes this a today problem for anything with a multi-year confidentiality requirement.
2. AES is fine. RSA and ECC are the ones on the clock. Don't confuse symmetric and asymmetric exposure.
3. Hybrid deployment, not a hard cutover, is the current best practice. Combine classical and post-quantum algorithms so a flaw in either one doesn't break you.
4. Crypto-agility matters more than any single algorithm choice. Systems that can swap algorithms via policy will migrate in weeks; systems with crypto hardcoded everywhere will take years.
5. Start with an inventory, not a purchase. You can't migrate what you haven't found.

The migration to post-quantum cryptography is already underway at the bottom of the internet stack — most people using HTTPS today are benefiting from hybrid PQC without knowing it. The question for engineering teams isn't whether this happens. It's whether your systems are ready before the deadlines that are already on the calendar arrive.

Remember: the safest assumption about quantum-vulnerable cryptography isn't "it'll be fine for now" — it's "anything encrypted today with RSA or ECC has a shelf life, and that clock is already running."