Instrument theme
Quantum computing NIST standards published 2024 Migration measured in years

Post-quantum
cryptography.

Everything else in this section is a watch item. This one is not. Data encrypted today with today's public-key algorithms can be captured now and decrypted later, which means the exposure window for anything with a long confidentiality life opened some time ago.

Last reviewed 4 September 2026 · Engineering guidance, not legal advice.
HARVEST NOW, DECRYPT LATER

The threat model is simple enough to explain to a board in two sentences. An adversary with storage and patience intercepts encrypted traffic today and keeps it. When a cryptographically relevant quantum computer exists, they decrypt it.

What that means practically is that the relevant question is not when will quantum computers break RSA. It is how long does our data need to stay confidential. If the answer is a decade or more — medical records, government material, legal files, trade secrets, long-term contracts, biometric data that cannot be reissued — then your exposure is already live regardless of what date the machine arrives. Waiting for certainty about the date is choosing to be exposed for the interval.

The algorithms at risk are the public-key ones: RSA, and the elliptic-curve algorithms underpinning most key exchange and digital signatures on the internet today. Symmetric encryption such as AES is affected far less severely — the practical guidance there is to use longer keys rather than to replace the algorithm.

WHAT REPLACES THEM

NIST completed the first round of its standardisation process and published three final standards in August 2024. Unlike most of this subject, these are settled, implementable and shipping in mainstream libraries.

FIPS 203 — ML-KEM, a lattice-based key-encapsulation mechanism derived from CRYSTALS-Kyber, for establishing shared keys. This is the one that matters for the harvest-now problem, because it protects the confidentiality of traffic.

FIPS 204 — ML-DSA, a lattice-based digital signature scheme derived from CRYSTALS-Dilithium, and the general-purpose signature standard.

FIPS 205 — SLH-DSA, a stateless hash-based signature scheme derived from SPHINCS+. Larger and slower, and valuable precisely because its security rests on different mathematical assumptions — a hedge in case the lattice family is weakened.

NIST's draft transition guidance deprecates the algorithms offering roughly 112 bits of classical security — RSA-2048 among them — around 2030, and disallows all quantum-vulnerable public-key algorithms, including ECC P-256, by 2035. Further schemes are following the first three standards. Government deadlines in various jurisdictions sit inside that window. For a large estate, a migration of this kind runs two to five years, which is what makes 2030 a near date rather than a distant one.

WHAT HYBRID MODE ACTUALLY DOES
HYBRID KEY EXCHANGE
  1. Client hello
    offers both algorithms
  2. Classical KEM
    elliptic curve, as today
  3. ML-KEM
    FIPS 203, lattice-based
  4. Combine
    both secrets, one key
  5. Session
    secure unless BOTH break
  6. Fallback path
    retire it, or it is your exposure
Solid: the hybrid handshake Dashed: the classical-only path that must eventually be removed
Hybrid is not a halfway house. An attacker has to break the classical algorithm AND the lattice one, which guards against undiscovered weaknesses in the newer scheme.
HOW A MIGRATION ACTUALLY GOES
  1. PHASE 01

    Cryptographic inventory

    Find every place you use public-key cryptography: TLS termination, VPNs, code signing, document signing, database encryption, hardware security modules, embedded devices, and every third-party dependency that does any of these on your behalf. This is the hard phase and almost nobody has a complete answer at the start.

  2. PHASE 02

    Classify by data lifetime

    Rank systems by how long their data must stay confidential and how hard they are to change. Long-lived confidentiality plus long replacement cycles — embedded devices, archives, signed records — goes first, because those are the ones where waiting is most expensive.

  3. PHASE 03

    Hybrid deployment

    Deploy classical and post-quantum algorithms together, so a weakness in either leaves you protected by the other. This is current best practice rather than a transitional compromise, and major browsers and libraries already support it for key exchange.

  4. PHASE 04

    Crypto-agility

    Refactor so the algorithm is a configuration rather than an assumption baked into code. The genuine long-term deliverable: this will not be the last migration, and organisations that build agility now pay for the next one at a fraction of the cost.

  5. PHASE 05

    Retire the vulnerable

    Remove classical-only paths once the estate supports the replacements. Verification matters here — a deprecated algorithm still reachable through a fallback is still an exposure.

WHERE THIS TOUCHES AI

Directly, in two places worth naming. First, an AI system is usually a large aggregation point: retrieval indexes, embeddings and logs concentrate data that was previously scattered across systems, which makes the transport and storage protecting them a higher-value target than any individual source. Second, model weights and training data are themselves long-lived confidential assets — a proprietary fine-tune captured in transit today has a decade of value to an adversary.

The practical implication is unremarkable and easy to act on: when you build AI infrastructure now, include it in the cryptographic inventory from the start and prefer hybrid key exchange where your stack supports it. It is a configuration decision at build time and an expensive retrofit later. It is also, incidentally, one more argument for keeping the data path short — a system that never transmits data outside your building has a much smaller surface for anyone to harvest in the first place.

QUESTIONS
QUESTIONS — 4

The inventory is urgent; the full migration is a multi-year programme you should be planning rather than panicking about. The test is your data lifetime: if nothing you protect needs to stay confidential beyond a couple of years, you have time. If you hold medical, legal, governmental or trade-secret material, the harvest-now exposure is live today and we would suggest starting the inventory now.

Partly, and not entirely. Your TLS libraries, browsers and cloud providers will handle a great deal of this for you, and that is genuine leverage. What no vendor can do for you is find the places your own systems and processes depend on public-key cryptography — code signing, document archives, embedded devices, bespoke integrations. That inventory is irreducibly yours.

Running a classical and a post-quantum algorithm together so that breaking the channel requires breaking both. It guards against the possibility that the newer algorithms have undiscovered weaknesses — a reasonable concern for schemes that have had far less cryptanalytic attention than RSA. It is the current default recommendation, not a halfway house.

We build AI systems, and we make sure the ones we build are crypto-agile and inventoried. A full enterprise cryptographic migration is a specialist security engagement and we would introduce you to people who do it properly rather than pretend it is adjacent to what we do.

Keep reading
30-minute technical call · no deck

Start with the
inventory.

It is the cheapest step and the one everything else depends on. We build the AI systems we deliver to be crypto-agile.

CASE STUDIES

Shipped work.
Go and check it.

The work we can name, with the live site, our scope and the boundary made explicit. Select a project to see the evidence; each is a full case study, not a logo or a claim.

sonora.com
The Sonora homepage on desktop: a full-bleed dune landscape behind the headline “Transform Your Life with Sound”, with App Store and Google Play download buttons.
sonora.com — homepage, 1440×900 sonora.com →
Live Consumer wellness · Mobile + web

Sonora

Cognitive AI Ltd · 2026

A free sound-wellness app, described by its publisher as AI sound therapy that reads a short vocal sample at the start of a session and generates a soundscape for that moment. We designed and built the website and its backend, produced assets for the iOS and Android apps, and supported the application prototype.

Read the case study →

See every published project →

WHO WE HAVE BUILT FOR

Twenty-one years of applications, platforms and campaigns for names you know.

See all of our work →