The Signature You Sign Today Outlives the Algorithm

A signature is a promise made in a language, and the language has an expiry date the promise does not. When you put a cryptographic seal on a record, you are betting that anyone who looks at it in ten or twenty years will still be able to read the maths and agree the seal is genuine. That bet holds while the maths holds. It fails the moment the scheme behind the seal is broken, deprecated, or quietly retired by the bodies that once blessed it.

This is the part of the post-quantum conversation almost nobody wants to sit with. Everyone is rushing to be ready for Q-day, the hypothetical morning a large quantum computer makes today's public-key cryptography readable. Far fewer are asking the harder question. What happens to all the signatures we are about to create, in the very schemes we are migrating to, when those schemes reach the end of their own lives. Because they will. Every one of them.

The migration everyone is selling is the wrong shape

Walk into most boardrooms this year and the post-quantum story sounds clean. We had RSA and elliptic-curve signatures, they are vulnerable to a future quantum machine, so we are replacing them with a lattice-based scheme that resists it. Job done, line drawn, certificate of completion filed. The scheme of the moment is ML-DSA, the lattice signature standardised by the United States National Institute of Standards and Technology under FIPS 204, and it is a genuinely good piece of work. I have no quarrel with the mathematics.

My quarrel is with the shape of the project. A one-time swap to ML-DSA treats the migration as a destination. It is not a destination. It is one stop on a line that keeps going. The honest framing of crypto-agility post-quantum migration is not we moved from old to new. It is we built a system that can keep moving, because the new becomes the old, and probably sooner than the slide deck implies.

“You are not migrating to a final algorithm. There is no final algorithm. You are migrating to the ability to migrate again, without breaking a single record you have already sealed.”

Treat that as the whole thesis if you read nothing else. The deliverable of a real post-quantum programme is not a chosen scheme. It is a property of the system, the property that lets you change the scheme later, at acceptable cost, with every historical signature still verifying. That property has a name, and the name is crypto-agility.

ML-DSA is excellent, and it will be deprecated

Both halves of that heading are true at once, and holding them together is the entire discipline. ML-DSA-65, the parameter set we seal with, is the most carefully scrutinised post-quantum signature scheme available to a commercial system today. Choosing it is the correct call for 2026. I would be suspicious of anyone telling you otherwise.

But look at the history of every cryptographic primitive we have ever trusted. MD5 was a standard. SHA-1 was a standard. RSA-1024 was a standard. DES was a federal standard for two decades. Each was excellent for its era, and each was eventually deprecated, not because the people who chose it were foolish, but because cryptanalysis advances, hardware advances, and what looked like a comfortable margin gets eaten away. Lattice schemes are newer and less battle-tested than the ones they replace, which is an argument for more humility about their lifespan, not less.

So the planning horizon that matters is not the day ML-DSA is adopted. It is the day, somewhere down the standards line, when ML-DSA joins that retired list. On that day, two kinds of organisation will exist. The ones who can re-anchor their old records into a fresh scheme without losing a thing, and the ones holding millions of seals nobody is allowed to trust any more.

The records outlive the scheme by design, not by accident

Here is the asymmetry that makes this urgent. A signature is generated once and verified again and again across the entire life of the record. A contract, a medical decision, a chain-of-custody entry, a regulatory filing, none of these is signed once and forgotten. They are checked at audit, in litigation, at handover, decades after the ink. The signing event is a single moment. The verifying events stretch across the whole future of the data.

Which makes the requirement brutally simple to state and easy to ignore. A seal made under today's algorithm must still verify after that algorithm is gone. If your architecture cannot promise that, you have not migrated to post-quantum security. You have rented it, on a lease that ends the next time the standards cycle turns.

What crypto-agility actually demands

Crypto-agility gets used as a comforting buzzword, so let me make it concrete. It is not a vague willingness to change. It is a set of specific properties baked into the layer that does the signing, and if any one of them is missing the whole thing fails quietly. From everything we have built, these are the non-negotiables.

• Algorithm identifiers travel with every signature, so a verifier reading a record knows exactly which scheme and parameter set produced the seal, without guessing from context that may no longer exist.
• No scheme is hard-coded anywhere in the signing or verification path, so adding a successor algorithm is a configuration change, not a rebuild of the system.
• A re-anchoring path exists, a defined way to wrap an old seal inside a fresh signature under a new scheme, preserving the original while extending its trust into the present.
• Multiple algorithms can coexist and be verified side by side during the transition window, because migrations are never instantaneous and a system that demands a flag-day switch will never get one.
• The integrity of the historical chain is independent of any single living scheme, so the failure of one algorithm degrades trust only in records signed under it, not across the entire archive.

Notice what these have in common. None of them are about which post-quantum scheme you pick. They are about how the surrounding machinery treats schemes as replaceable parts rather than load-bearing walls. You can choose the best algorithm on the market and still build a brittle system around it. The algorithm is the easy decision. The architecture is the one that decides whether you survive the next cycle.

Why I built the audit layer to carry its own algorithm history

This is where I have to talk about how we do it, because the abstract argument only earns its keep when it survives contact with a real system. In the Mickai Sovereign Intelligence Operating System, every consequential action taken by any of our fifty specialised brains is sealed into a post-quantum Open Audit Record. Today that seal is an ML-DSA-65 signature under FIPS 204. That is the algorithm of the moment, and we use it precisely because it is the right call right now.

But the Open Audit Record was never designed around ML-DSA. It was designed around the assumption that ML-DSA will one day not be enough. Each record carries its own algorithm identifier, so a record sealed in 2026 announces what signed it rather than relying on some external register that may be lost. The verification path resolves the scheme from the record itself, which means we can register a successor algorithm and verify old and new records in the same system on the same day.

And the records support re-anchoring. When the time comes, an existing Open Audit Record can be wrapped in a fresh signature under the next standardised scheme, the original seal preserved underneath, the new seal extending its trust into the present standards cycle. The 2026 record is not rewritten and it is not thrown away. It is re-inscribed in fresh light, the old marks still there beneath the new ones, the chamber unbroken.

Sovereignty is what makes re-anchoring possible at all

There is a reason this only works on a system the operator actually controls. To re-anchor a record you need the original record, the original seal, and the authority to extend it, all in your own hands. If your audit trail lives in someone else's cloud under someone else's key rotation policy, you do not get to decide when and how it migrates to the next scheme. You inherit their timetable and their risk appetite.

Because the SIOS runs on the operator's own hardware and is fully offline-capable, the entire archive and the means to re-anchor it stay with the operator. The same holds for Pantheon, our sovereign Bitcoin-anchored Layer 1, where the anchoring of records is a property the operator holds rather than a service they rent. Crypto-agility on infrastructure you do not control is a promise somebody else gets to break.

The objection I hear, and why it is backwards

The pushback usually arrives like this. We do not have time to build an agile audit layer, we just need to be quantum-safe before Q-day, so let us swap in ML-DSA and call it done. I understand the pressure behind that. I think it gets the cost the wrong way round.

Building agility in at the start is a design choice you make once, mostly for free, while you are already touching every signing path to move off the old schemes anyway. Retrofitting it later, after you have generated years of records hard-bound to one algorithm, is the expensive nightmare, the same migration you are doing now but with a vastly larger archive and no clean seam to cut along. If you are going to disturb the signing layer to add ML-DSA, that is the single cheapest moment you will ever have to make the layer agile. Skipping it does not save the work. It defers the work and multiplies it.

There is also a quieter cost to the one-time-swap story, and it is a cost to your credibility. The day ML-DSA is deprecated, every customer, regulator and auditor who trusted a record you sealed under it will ask the obvious question. Does this still verify. If your honest answer is we are not sure, the value of your entire audit history collapses in a sentence. Agility is not a luxury you add for elegance. It is the thing that lets you keep saying yes.

What honest looks like in 2026

So here is the standard I hold us to, and the one I would ask any sovereignty or security vendor to meet. Tell me which post-quantum scheme you sign with today. I expect a strong answer, and ours is ML-DSA-65 under FIPS 204. Then tell me what happens to those signatures when that scheme is deprecated. If the answer is silence, or a confident assurance that it never will be, walk away. No serious cryptographer believes their current scheme is the last one.

The honest answer to the deprecation question is a description of machinery. Algorithm identifiers in every record. No hard-coded scheme. A re-anchoring path. Coexisting algorithms during transition. Integrity that does not depend on any single living primitive. Control over the archive that does the re-anchoring. That is crypto-agility post-quantum migration described as a system property rather than a marketing claim, and it is the only version of the post-quantum story I am willing to put my name to.

The line I want you to leave with

A migration that ends is not a migration. It is a deadline you will live to regret. The schemes will keep turning over, the standards bodies will keep retiring their own recommendations, and the one thing that has to stay constant is your ability to carry the past forward intact. Build for that, and Q-day becomes one event you handle, rather than the last event you survive.

The signature you sign today outlives the algorithm. Make sure the record outlives them both.