Why Post-Quantum Security Matters for AI

Post-quantum security matters for AI for a reason rarely stated in the boardroom: the danger is not only that your secrets get read, it is that your evidence stops counting. Encryption protects what you want hidden. Signatures protect what you need to prove. An AI system inside a regulated organisation generates far more of the second, and every classical signature it writes today has an expiry date nobody has put in the risk register.

What does harvest now, decrypt later actually mean?

It means an adversary needs no quantum computer to attack you today. It needs storage and patience. Traffic lifted from a wire, a stolen backup, a captured key exchange: all of it can sit in a warehouse until the mathematics catches up. The question is not when a cryptanalytically relevant quantum computer arrives. It is how long your data must stay secret, plus how long migration takes. If those exceed the time until the machine exists, you are late.

AI changes the value density of the harvest. A fine-tuning corpus is decades of case files in one archive. A context window is the most concentrated statement of an organisation's private reasoning ever committed to a network: not the document, but the question someone asked about it, and what a clinician suspected or counsel wanted to test. Whoever quietly collects that traffic is not collecting data. They are collecting intent.

Why do signatures matter as much as encryption?

Because the asymmetry that makes a signature meaningful is the asymmetry Shor's algorithm dissolves. RSA and elliptic curve signatures work because deriving the private key from the public key is infeasible. A large enough quantum computer makes that derivation tractable. On that day, anyone holding your public key can produce a signature indistinguishable from yours, on any document, bearing any date.

Follow that consequence, because it runs backwards. Encrypted data decays item by item: an adversary breaks what they bothered to keep. Signatures fail at once, and retroactively. Every record signed with a classical key becomes forgeable, and therefore deniable, by you and by anyone else. The audit trail does not leak. It evaporates. Re-signing later cannot rescue it: a signature applied in 2033 proves what you asserted in 2033.

Hash functions survive this. Shor's algorithm does not break them; Grover's algorithm offers a quadratic speedup on preimage search, answered by using a wider hash rather than by abandoning hashing. A hash chain therefore endures the transition. The signature over that chain does not, unless it was post-quantum when written. A record hash chained and signed post-quantum keeps both properties: it cannot be reordered, and it cannot be forged.

Which standards are final, and what does each one do?

Three, published by NIST in August 2024 as final Federal Information Processing Standards, not drafts.

• FIPS 203, ML-KEM: key encapsulation. The confidentiality answer, replacing the key exchange that protects data in transit.
• FIPS 204, ML-DSA: a lattice-based signature algorithm. The general-purpose integrity answer, fast enough to sign at operational volume.
• FIPS 205, SLH-DSA: a hash-based signature algorithm. Larger, slower, resting on a different and more conservative assumption.

The shape of that set is instructive. NIST standardised one mechanism for confidentiality and two for signatures, deliberately, on different mathematical foundations. That is a hedge: if the lattice assumption under FIPS 204 were weakened, FIPS 205 does not fall with it. When the standards body declines to bet everything on one branch of mathematics, an architect should take the hint. Before August 2024, waiting for the standard was a defensible procurement position. It is not now.

Is this a cryptography problem or a board problem?

A board problem, because it is about the shelf life of evidence, not the choice of algorithm. In 2032 a court will ask what happened in 2026: which model ran, on which inputs, under whose authority. GDPR Article 22 attaches obligations to automated decisions with legal or similarly significant effect. The EU AI Act adds record keeping duties for high risk systems. Both assume a record made years ago still means something now. That assumption is cryptographic, and the people choosing signature algorithms are rarely in the room where retention periods are set.

What is the honest counter-argument?

That nobody knows the date, and anyone claiming to is selling something. Serious cryptographers disagree by decades about when a cryptanalytically relevant quantum computer becomes real, and some doubt it ever does. The post-quantum algorithms are young, and confidence in a hardness assumption is a function of how long capable people have tried to break it and failed. Migration costs money, keys and signatures grow larger, and every change to a security boundary invites fresh defects.

We accept all of it. The argument rests on an asymmetry, not a date. Sign post-quantum and be wrong about the threat, and you have spent some bytes, some cycles and some engineering attention. Sign classically and be wrong, and there is no remedy: the loss lands on records already written. One error is a line item. The other cannot be corrected at any price. Hybrid, classical and post-quantum together, is therefore the sane default.

What should we do that is not simply waiting for a vendor?

• Inventory what is signed, not only what is encrypted. Most organisations can describe their TLS estate. Few can name every place a private key asserts that something happened.
• Compare retention periods against signature algorithms. Anything that must stay provable for longer than you would bet on classical asymmetric cryptography is a finding.
• Ask suppliers which FIPS standard signs their audit records. An answer about encryption in transit answers a different question.
• Prefer hash chained records to isolated signed documents.

Frequently asked questions

Does post-quantum cryptography mean our existing encryption is broken today?

No. Classical encryption is not broken today, and there is no public evidence of a machine that breaks it. The exposure comes from capture now and decryption later, so it is set by how long your data must stay secret, not by today's threat. Anything that must stay secret for decades is exposed now.

Are FIPS 203, 204 and 205 final, or still drafts?

Final. NIST published all three in August 2024: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures. They are implementable and citable in procurement now, which is why waiting for the standard is no longer a defensible answer from a supplier.

Why sign audit records with ML-DSA rather than upgrade encryption first?

Because encryption can be retrofitted and evidence cannot. In Mickai, the Open Audit Record seals every consequential action before it executes, signs the seal with FIPS 204 ML-DSA-65, and hash chains it so the sequence is verifiable offline by a regulator or a court. The signature resists forgery, the chain resists reordering, and both must be right at the moment of writing.

Can we not just re-sign our archives when the time comes?

No, not honestly. A later signature proves only what you asserted later. It cannot establish that a record existed at its stated time unless something quantum resistant already bound it there. Re-signing after the assumption fails converts evidence into assertion, which is why this is a design decision, not a maintenance task.

Mickai is a British Sovereign Intelligence Operating System, built and live, running offline on hardware the organisation owns, inside its own jurisdiction. Every consequential action is sealed in the Open Audit Record before it executes, signed with post-quantum FIPS 204 ML-DSA-65 and hash chained so it can be verified offline, years later, by a regulator or a court. The architecture is protected by 104 filed UK patent applications carrying 2,340 claims, held by Mickai LTD. It is set out at /sovereign-ai, the record format at /oar. Organisations wanting to find where their evidence expires can start at /ai-readiness.