Crypto-agility: designing AI to swap cryptographic algorithms before you are forced to
Design your AI to change cryptographic algorithms by configuration rather than rebuild, so a deprecated signature scheme never forces a costly, high-pressure migration.
Crypto-agility is designing an AI system to swap cryptographic algorithms without re-architecting it, so a deprecated scheme becomes a configuration change, not a forced migration.
This matters now because the post-quantum signature standards were finalised in 2024, and adversaries already harvest encrypted data to decrypt once quantum hardware matures. A regulated buyer who locks one algorithm into an audit trail today will pay for that decision the day it is broken.
What does crypto-agility actually mean for an AI system?
Crypto-agility means an AI system treats its algorithms as swappable choices, not fixed assumptions, so a broken scheme is replaced without touching application logic.
When a system hard-codes one signature scheme, that choice spreads into storage formats, verification code and every integration that touches a signed record. Removing it later means editing all of them at once, usually under time pressure, when the algorithm is already weakened. A crypto-agile system localises the choice: the algorithm is named in the data, selected at runtime and replaced by configuration rather than by a rebuild. The forced migration becomes a routine change.
“A system that cannot change its cryptography without a rebuild has already chosen its own expiry date.”
What does a crypto-agile design look like next to a brittle one?
A crypto-agile design records which algorithm signed each item and selects verifiers at runtime, while a brittle design bakes one fixed scheme into the code.
The difference is visible design choice by design choice. A brittle system assumes one algorithm everywhere and cannot describe any other; an agile system names the algorithm in the record and lets the verifier follow. The table below sets the two approaches side by side.
| Design choice | Brittle approach | Crypto-agile approach |
|---|---|---|
| One scheme hard-coded in source | Chosen from a registry at runtime | |
| Manual, tied to a rebuild | Scheduled, with no code change | |
| Bytes with no scheme label | Self-describing algorithm identifier | |
| Assumes a single algorithm | Reads the identifier, selects the verifier | |
| Rewrite history to migrate | Add new signatures, keep the old |
How does a self-describing audit ledger swap algorithms without breaking old records?
Each ledger record carries an algorithm identifier, so it declares which scheme signed it; new algorithms are added without breaking verification of older records.
A self-describing ledger is the mechanism that makes this practical. Each record stores an algorithm identifier next to its signature, so verification never assumes a scheme: it reads the identifier and loads the matching verifier. Introducing a second signature standard is then additive. New records are signed under the new scheme, old records keep verifying under the old one, and the chain stays continuous. This is what lets an operator adopt a post-quantum signature the moment it is ready, with no disruptive rewrite. The design is the subject of our patent estate: 104 filed UK patent applications and 2,340 claims, owned by Mickai LTD (Companies House 17166618), filed and patent pending.
Which post-quantum standards sign the ledger?
FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) sign the audit ledger; FIPS 203 (ML-KEM) performs key encapsulation and never signs, so the roles stay separate.
Signing and key establishment are separate jobs and must use separate primitives. FIPS 204 and FIPS 205 are digital signature standards, and they are what seal each ledger record; FIPS 203 is a key encapsulation mechanism used to protect data in transit, and it must never be treated as a signature. Conflating them is a common error that a crypto-agile design avoids by binding each record to the identifier of the scheme that actually signed it. When a future signature standard is published, the same identifier mechanism carries it in.
How does crypto-agility satisfy 2026 regulators?
Crypto-agility keeps an audit trail verifiable as standards move, which matters because DORA, NIS2 and the EU AI Act expect durable, tamper-evident records.
Regulators are converging on durable, verifiable evidence. DORA has been in force since January 2025, NIS2 covers essential and important entities, and the EU AI Act's high-risk Annex III obligations, once due 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk duties moving to 2 August 2028 and Article 50 transparency largely unchanged. Across that shifting timeline an audit trail has to stay verifiable for years. A ledger that can swap its signing algorithm without losing the ability to check older entries is how the evidence survives a standards change. Because our ledger is verifiable offline behind a zero-egress inbound perimeter, and identity is hardware-attested and bound to the chain, that evidence also stays inside the operator's control. The US CLOUD Act can compel a US-based provider to hand over data regardless of where its servers sit, which is precisely the exposure an offline sovereign design removes.
When is a cloud AI service still the right pick, and when is a SIOS?
A managed cloud service like ChatGPT suits fast, low-sensitivity work; for classified data, an offline SIOS with a swappable, sealed audit ledger fits better.
There is no single right answer for every workload. A managed cloud assistant such as ChatGPT, Copilot or Gemini is often the fastest, best-value option for open, low-sensitivity tasks, and we say so plainly. The distinction is data sensitivity and control: those services cannot hold a nation's most classified material, and their cryptography is not the operator's to change. Mickai is a Sovereign Intelligence Operating System, a SIOS, built and live, running offline on operator-owned hardware with every action cryptographically sealed. Its 50 brains, 25 domain and 25 operational, reach decisions by cross-model consensus, and each action is sealed into the same agile ledger. Where a cloud service asks you to trust its algorithm choices, a SIOS lets you own and change them.
Frequently asked questions
How is crypto-agility different from just using strong encryption today?
Strong encryption protects data under one algorithm; crypto-agility protects the system's ability to change that algorithm. A cipher considered strong in 2026 may be deprecated within a decade, and a design that cannot swap it will need re-architecting under pressure. We treat the algorithm as a runtime choice, not a permanent assumption.
Will introducing a new algorithm invalidate my existing signed records?
No. Because each record in our audit ledger carries its own algorithm identifier, it declares which scheme signed it. New algorithms sign new records, while older records remain verifiable under the scheme that produced them. Nothing is rewritten and no history is lost.
Do I need to re-sign old records when we migrate?
Re-signing is optional, not forced. You can add a fresh signature under a new algorithm to any record you want to strengthen, while the original signature stays in place. This keeps migration incremental and reversible instead of a single disruptive rewrite.
Is Mickai relying on an experimental cryptographic scheme?
No. We sign the audit ledger with the NIST standards FIPS 204 and FIPS 205, and use FIPS 203 for key encapsulation, never for signing. Crypto-agility means that if any of these is superseded, we adopt the replacement without re-architecting the ledger.
Can the audit ledger be verified without an internet connection?
Yes. Verification is fully offline. Because each record embeds the identifier of the scheme that signed it and the chain stays continuous, an auditor can confirm every entry on operator-owned hardware behind a zero-egress perimeter, with no external service to trust.