Quantum readiness · long-lived documents

Will it still verify in twenty years?

Nobody buys a document tool because of post-quantum cryptography. But somebody on your side of the table has it on a checklist — so here is the honest answer, along with the two more likely ways a signature dies of old age.

Sign a contract today. Someone opens it in 2041 — an auditor, a court, a successor who wasn't born when the deal was struck. For the seal to still mean something, three things have to survive two decades that were never designed with them in mind.

A signature doesn't usually fail because the math broke. It fails because the world moved on around it.

Three ways a signature dies of old age

In rough order of how likely they are to bite you.

Threat one · the likely one

The key is long gone

Keys get rotated. Staff leave. Companies get acquired and identities get retired. In most systems, the day a signing key goes away is the day every signature it ever made turns into a shrug — the verifier looks for a key that no longer exists and gives up.

What we do: keep the history, permanently. Every rotation is recorded in a tamper-evident log that travels with the identity — each entry signed and chained to the one before it, so entries can't be forged, reordered or quietly deleted. A verifier looks up the key that was active when the document was signed, not today's key. And retired identities stay resolvable forever: signing stops, verification never does. Your signatures keep working even if you leave — with one shared duty worth writing into your retention policy: an identity on your own domain is reachable only while that domain is. We keep the keys and the history; you keep the domain registered.
Threat two · the sneaky one

The clock is a lie

Key history only helps if you can trust when a document was signed — and the timestamp inside a signature is just whatever the signer's computer said it was. Someone holding an old, retired key can set their clock back and produce a document that looks like it was signed years ago, while that key was still good.

What we do: get the time from someone else. An independent time-stamping authority signs the moment, so the time is no longer the signer's word. The verifier already enforces this today: a signature leaning on a retired or revoked key without trusted time is refused rather than waved through. Issuing those timestamps at signing is rolling out to customers now.
Threat three · the checklist one

The math gets weaker

This is the one on the questionnaire. A large enough quantum computer would break the signature algorithms almost everything uses today. Nobody has built one. The uncomfortable part is the timing: a document signed now may still need to be provable long after such a machine exists — so waiting until it does is waiting too long.

What we do: sign twice, already. Every TrustDID document carries two signatures — the classical one, and a post-quantum one using ML-DSA-44, the algorithm NIST standardised as FIPS 204. Today's verifiers check both. If the classical one is ever broken, the second proof is already sitting in every document you have ever signed — not something you have to go back and add to twenty years of paperwork.

For the checklist

The short, precise version — including where we are not post-quantum yet.

Straight answers

Are signatures post-quantum?
Yes, today, by default. Every document is dual-signed: Ed25519 plus ML-DSA-44 (FIPS 204). Not an upgrade path, not an option to switch on — it is what the tools already do.
Is encryption post-quantum?
Not yet — file encryption uses X25519, which is classical. We would rather say so than let you assume otherwise. It is the natural next step, and it does not affect signatures or the long-term verifiability described above.
Do old documents keep verifying after a key rotation?
Yes. The signed key-history log lets a verifier resolve the key that was active at signing time, and retired identities stay resolvable permanently.
What do we have to do to keep documents verifiable?
Keep the domain. A did:web identity resolves through the domain it names, so an identity on your own domain stays checkable only while that domain is registered and serving its DID document — give it the same lifetime as the documents it signs. We keep the keys, the history and the published record; identities we host live on our domain.
Can a signature be back-dated onto a retired key?
No. A signature relying on a retired or revoked key without trusted time is refused by the verifier — enforced today.
Are these open standards?
Yes — W3C decentralized identifiers, NIST FIPS 204, and DNS-based corroboration. No proprietary format holds your documents hostage, and no blockchain is involved.

None of this is why anyone falls in love with the product — people come for catching the fake invoice. It is simply what has to be true for a document sealed today to still be worth something in twenty years. So we built it in, and you get to tick the box.

Documents that outlive their keys.