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.
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.
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.
offers both algorithms
elliptic curve, as today
FIPS 203, lattice-based
both secrets, one key
secure unless BOTH break
retire it, or it is your exposure
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.
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.
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.
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.
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.
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.
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.
It is the cheapest step and the one everything else depends on. We build the AI systems we deliver to be crypto-agile.
30-minute technical call · no deck
What we built, what stage it is at, and a link to the live thing wherever there is one.
yourOS is an operating system with an AI at its heart. You talk to it like a person, out loud or typed. It makes your calls, plans your days and works on your projects with a crew of agents, on your own private server. Our own product, built from the first commit; the waitlist is open.
Website, backend and app assets for Sonora, a free AI sound-therapy app on iOS and Android published by Cognitive AI.
Brand, website, prototype, apps on five platforms, the AI backend and the algorithm-intelligence pipeline for Podswap, a social growth engine that runs without a human in the loop.
In closed beta: Roxy, a private AI assistant with permanent memory running on infrastructure the user owns. Brand, site, product, backend and conversational design.
Live at coherence.com: brand identity generated with AI agents we directed, the motion system and website for the group behind Sonora, AboutAI, WakeUp and MudShadows. Agent work remains in build.
Live at domainbooth.com for DomainBooth, a premium domain brokerage: a new animated mark, every page redesigned and rebuilt with designed mobile layouts, and a custom CMS for its sales record, featured names, press and enquiries.
Apps, platforms and campaigns for these teams, long before the AI work. Every one is written up on the work page — what we did, and where our part ended.
