Signatures outlive their assumptions
NIST finalised three post-quantum standards in August 2024: ML-KEM for key encapsulation, and two signature schemes, ML-DSA and SLH-DSA. Most migration discussion has focused on ML-KEM, because key exchange is where harvest-now-decrypt-later risk lives and because TLS is where the operational pain is concentrated.
For regulated organisations, the signature schemes are arguably the more consequential pair, and for a reason specific to how compliance evidence works. Encrypted data that is decrypted in 2035 was still confidential in 2026. A signature that becomes forgeable in 2035 retroactively weakens every claim it was used to support, including claims about 2026.
Two signature schemes, two different bets
The two standardised signature schemes represent genuinely different security assumptions, and for long-retention evidence the difference is not academic.
ML-DSA is lattice-based. It is fast, signatures and keys are reasonably sized, and it is the general-purpose recommendation. Its security rests on the hardness of structured lattice problems, which is a well-studied but comparatively young assumption.
SLH-DSA is hash-based and stateless. Signatures are large and signing is slow. Its security rests on the properties of the underlying hash function and essentially nothing else, which makes it the most conservative option in the set. If lattice assumptions were to weaken, hash-based signatures would be largely unaffected.
For high-volume signing, ML-DSA is the practical answer. For a small number of very long-lived, high-consequence attestations - the anchor points in a compliance evidence chain, root attestations, records with multi-decade retention - the conservatism of a hash-based scheme is worth its size penalty.
The retroactive problem
Here is the scenario that keeps this from being an abstract cryptography discussion.
An organisation has ten years of compliance evidence, each record signed with a classical scheme. In 2033, that scheme is broken. Every one of those signatures is now forgeable by anyone. The organisation still has its records. It has no way to demonstrate that those specific records are the ones it created rather than ones produced afterwards.
This is not a data loss event and no alert fires. Nothing changes about the files on disk. What changes is the evidentiary value of the entire archive, retroactively, on a day nobody was watching.
The standard mitigation is to re-anchor: before the primitive weakens, produce a new proof over the existing corpus using a stronger scheme, and preserve the linkage so the original dates survive the transition. This works, and it has one absolute requirement. It has to happen while the old scheme is still trustworthy. Re-anchoring after a break proves only that the corpus existed at re-anchoring time, which is precisely the fact that was never in question.
- Identify evidence with retention obligations beyond ten years - financial records, medical records, AI system logs tied to system lifetime, intellectual property attestations
- Determine which cryptographic scheme currently backs each integrity claim over that evidence
- Confirm with your platform or provider whether re-anchoring under a new scheme preserves original timestamps or resets them
- Prioritise re-anchoring by consequence and retention length, not by volume
- Record the re-anchoring event itself as evidence, since the linkage between old and new proof is the thing an auditor will examine
Why hash-linked structures age comparatively well
There is a reason approaches built on hash-linking and timestamping tend to fare better across primitive transitions than approaches built on a single signature over a document.
A hash-linked structure derives its force from the difficulty of finding collisions in the hash function and from the public, ordered nature of the chain, rather than from the secrecy of any key. There is no private key that can be stolen or whose scheme can be broken to enable forgery of past entries. Upgrading the hash function is a forward operation that can be linked to what came before.
That does not make such structures immune to cryptographic progress. Hash functions weaken too, and the migration still has to be planned. But the failure mode is more gradual and the re-anchoring path is cleaner, which matters a great deal when the thing you are protecting is a decade of records rather than a session key.
We covered the underlying mechanics in what is cryptographic data integrity: a plain English guide and the regulatory drivers in cryptographic audit trails.
The inventory work that makes any of this actionable is the same inventory described in the FIPS 140-2 sunset and why your integrity proofs need a crypto inventory. If you have not done it, start there.
- Choose signature schemes per use case, not once globally - high-volume operational signing and long-lived attestation have different requirements
- Ask your integrity provider directly how re-anchoring preserves original dates
- Move on long-retention evidence first, while classical schemes still carry weight
- Treat the re-anchoring event as a record in its own right
If you want to see how anchored records survive a primitive transition with their original dates intact, you can test the verification path on your own long-retention records.
Erhalten Sie Einblicke zur Cyber-Resilienz per E-Mail
Praktische, auditfähige Hinweise zu Datenintegrität, Compliance und Kontinuität – sobald wir veröffentlichen.