Encrypted today, readable tomorrow.

Why the cryptographic clock became a board project

For most of the last decade, "post-quantum" was a slide in a security conference and a line in a research roadmap — a real problem, comfortably in the future. Two things collapsed that distance in 2026. The first is that the standards are done: NIST finalised the algorithms that replace today's public-key cryptography, so the question is no longer which quantum-safe scheme to adopt but how fast you migrate to the ones that already exist. The second is a deadline with teeth: transition guidance now names a horizon where the RSA and elliptic-curve algorithms that secure nearly everything are deprecated, and then disallowed for new systems — which turns migration from a research question into a dated programme with a budget and an owner.

Neither of those is what makes it urgent for a document platform, though. The thing that removes the option to wait is "harvest now, decrypt later." An adversary does not need a quantum computer today to threaten a document today; it needs only to capture the encrypted document today and store it. When a cryptographically-relevant quantum computer arrives — in five years or fifteen, the exact date does not change the logic — the stored ciphertext is decrypted retroactively. Anything you encrypt now with RSA or ECC and that still needs to be secret then is already, in effect, exposed. The window of vulnerability is not "from Q-Day onward"; it is "from the moment of capture," and for a long-retention document that moment is now.

That is why this lands hardest on exactly the documents a serious platform holds. A message that is sensitive for an hour does not care about a quantum computer a decade away. A contract, a clinical record, a KYC file, a piece of litigation evidence, a tax record — the documents that must stay confidential and provable for 10, 20 or 30 years — sit squarely inside the window where harvest-now-decrypt-later is a live threat. The retention period is the exposure. An organisation that treats cryptography as a stable dependency discovers, under a regulatory deadline, that the confidentiality of its long-lived documents and the validity of their signatures are decisions a board has to make years ahead — not on the eve of Q-Day.

This is algorithm migration, not content provenance

The fastest way to misfile this problem is to fold it into work you have already done on document trust. Cryptographic provenance — the C2PA-style signing that attests where a document came from and whether a person altered it — is genuinely valuable and genuinely adjacent, and it is not this. Provenance answers "who created or edited this content, and can I detect tampering?" Post-quantum migration answers a different question entirely: "will the cipher that keeps this document secret, and the signature that makes it non-repudiable, still hold when the mathematics they rest on is broken?"

The distinction matters because the two do not substitute for each other, and one can quietly undermine the other. A provenance signature is itself a digital signature — if it is built on a classical algorithm, then a document you signed today to prove its origin becomes a document whose origin proof is forgeable once that algorithm falls. Provenance tells you who signed; post-quantum migration is what keeps the signature meaning something over the retention window. This piece is about the second thing: migrating the encryption and signature algorithms themselves, so that both the secrecy and the provability of a long-lived document survive the transition.

Read the rows together and the design consequence is clear: a document platform can have excellent provenance and strong encryption today and still be building a liability, because both of those rest on classical cryptography with a known expiry. The work is not to add another trust feature on top; it is to migrate the algorithms underneath so the features you already ship keep their meaning after the transition.

The framework that is forming

What is emerging is not a single product but a small set of moves that together turn "we should think about quantum someday" into a migration you can actually schedule and prove. None of them is exotic; each is the long-retention-document version of a discipline that mature security teams already recognise, applied to a deadline they cannot negotiate.

A cryptographic inventory, because you cannot migrate what you cannot see

The foundational move is knowing where RSA and ECC actually live — encryption at rest, encryption in transit, the signature on a stored document, and the timestamp that anchors that signature in time. Most organisations cannot produce this list, because cryptography was chosen once, buried in a library or a key store, and never revisited. Without the inventory, every downstream step is guesswork: you cannot prioritise a migration you cannot see, and you will reliably miss the timestamp on the audit trail while congratulating yourself for re-encrypting the database. The inventory is the cryptographic counterpart to the asset register every security programme already treats as prerequisite — and it is the one thing that turns "we use encryption" into "here is every place a quantum-vulnerable algorithm touches a document that outlives it."

Crypto-agility as an architecture requirement, not a one-time swap

The second move is structural: build the system so the algorithm can be changed without rewriting the system around it. Crypto-agility means the cipher and signature scheme are configuration, not assumptions welded through the codebase — so this migration, and the next one, is a swap rather than a rebuild. The organisations that will struggle are the ones where "which algorithm" is hard-coded into a hundred call sites; the ones that will move are the ones that made the algorithm a pluggable decision. This is the difference between a migration that takes a release and one that takes a rewrite, and it is the single architectural choice that most determines how the deadline feels.

Hybrid classical-plus-post-quantum signatures during the transition

The third move manages the in-between. During the transition, the safe posture is hybrid: sign and encrypt with a classical algorithm and a post-quantum one together, so a document is protected if either scheme holds. Hybrid guards against two opposite risks — that the classical algorithm falls sooner than expected, and that a still-young post-quantum scheme turns out to have a weakness of its own — by refusing to bet everything on one. It costs more in size and computation, which is exactly why it belongs to the transition period and not forever, but for the long-retention document that has to survive uncertainty on both sides, hybrid is how you avoid choosing wrong under a deadline.

Re-signing and re-sealing the documents that outlive their crypto

The fourth move is the one people forget: the documents you signed years ago are still in the archive, and their signatures were made with algorithms now on a countdown. A long-retention document may need to be re-signed and re-timestamped with a quantum-safe scheme before the old one is broken, or its non-repudiation quietly expires while it sits in storage. This is where post-quantum migration meets the signed, versioned trail that makes an autonomous system defensible: a trail whose signatures and timestamps rest on broken cryptography is no longer evidence, and re-sealing it on a quantum-safe algorithm is what keeps a decade-old record admissible rather than merely stored.

Prioritise by sensitivity window times retention period

The last move is triage, because you cannot migrate everything at once and should not try. The right ordering is by exposure: how sensitive the content is multiplied by how long it must survive. A document that is highly sensitive and must be kept for 30 years migrates first; a low-sensitivity record with a 90-day life can wait for the routine algorithm swap. This turns an overwhelming programme into a ranked queue, and it aligns the cost of migrating now with the actual risk of decryption later — so the budget goes to the documents where harvest-now-decrypt-later is a genuine threat, not to the ones where it is a rounding error.

The old question was "is our data encrypted?" The new one is "will what we encrypted and signed today still be secret and provable when the algorithm underneath it breaks?" — a cryptographic inventory so the exposure is visible, crypto-agility so the swap is a release and not a rewrite, hybrid signatures through the transition, and re-sealing of the long-lived documents whose signatures would otherwise expire in the archive.

Four ways it goes wrong

The failures here are predictable, and they cluster into four shapes. Each one lets an organisation feel it is "handling quantum" while leaving the real exposure open, and each surfaces at the worst possible time — a regulatory deadline, a storage bill nobody modelled, or an audit that asks whether a decade-old signature still means anything.

1. Treating post-quantum as a 2030 problem when the harvest is today

The most common failure is scheduling the work by the arrival of the quantum computer rather than by the moment of capture. "We have years before Q-Day" is true and irrelevant: the harvest-now-decrypt-later adversary is collecting encrypted long-retention documents today, so a document that must stay secret for 20 years and is encrypted with a classical algorithm now is already exposed to a decryption that happens later. The fix is to date the migration by the sensitivity-times-retention window of the documents, not by a guess at when the hardware matures.

2. Ignoring the signature-size explosion in the storage and bandwidth budget

The second failure is a modelling error: post-quantum signatures and keys are substantially larger than the ECC ones they replace — enough that signing every document and every audit-trail entry with them changes the storage and bandwidth footprint in a way nobody budgeted. A migration that works perfectly in a proof of concept can blow the archive's cost model at scale. The fix is to size the new signatures against real document volumes early, so the storage and transfer cost is a planned line rather than a surprise that stalls the rollout.

3. Migrating the encryption and forgetting the signature and timestamp

The third failure is partial: teams re-encrypt data at rest and in transit, declare the migration done, and leave the document signatures and the trail's timestamps on classical algorithms. Confidentiality is addressed; non-repudiation quietly is not — and the audit trail whose integrity depended on those signatures becomes forgeable the day the algorithm falls. The fix is to treat signature and timestamp as first-class targets of the migration, equal to encryption, because a long-retention document is only as provable as the signature that anchors it.

4. No crypto-agility, so the migration becomes a rewrite

The fourth failure is architectural debt coming due: when the algorithm is hard-coded across the system, migrating it is not a configuration change but a excavation through every place cryptography was assumed. The programme balloons, slips the deadline, and — worse — leaves the organisation just as stuck for the next transition. The fix is to make the algorithm a pluggable decision now, so that this migration is a swap and future ones are too, rather than paying the full cost of a rewrite every time the cryptographic ground shifts.

The trade-off, stated honestly

The honest version names the tension, because it is real: migrating now costs money, size and effort against a threat whose timing is genuinely uncertain. Post-quantum signatures are bigger, hybrid schemes double some of the work, re-sealing an archive is a real project, and the quantum computer that justifies all of it has no confirmed date. An organisation could rush the whole estate to quantum-safe algorithms tomorrow and pay a premium in storage and complexity for a threat that stays theoretical for another decade. That is a real cost, and pretending the timeline is certain is its own kind of dishonesty.

What you buy for that cost is the one thing you cannot buy later: the confidentiality and provability of documents that were captured while still protected by broken cryptography. The asymmetry is what settles it — if you wait and the threat arrives, the long-retention documents already harvested are not recoverable, because you cannot retroactively unshare a ciphertext someone stored years ago. So the trade is not "migrate now versus migrate later at the same cost"; it is "pay a known premium now on the documents that matter most, or accept an unrecoverable loss on them if the timing goes against you." That is precisely why the prioritisation matters: you spend the premium where sensitivity times retention is high and the harvest threat is real, and you let the routine algorithm swap handle the rest — rather than either rushing everything or, far more dangerous, doing nothing because the date is unknown. Migrating everything at once is over-engineering; migrating nothing because Q-Day has no date is the failure the harvest is built to exploit.

What this looks like for document AI specifically

Document AI is where the abstract cryptography gets concrete, because a document platform is precisely a place where long-retention content is encrypted, signed, timestamped and stored for years — and where the audit trail that makes an extraction defensible is itself a chain of signatures. Four things change when a platform is built for the migration rather than assuming its cryptography is permanent.

The cryptographic inventory is a property of the platform, not a scavenger hunt. A platform that holds documents for a decade should be able to say where every algorithm touches a stored file — the encryption on the object, the signature on the document, the timestamp on the trail — so the migration starts from a map rather than a guess, and the timestamp on the audit trail is never the thing that gets missed.

The algorithm is pluggable, so migration is a swap. Because the cipher and signature scheme are configuration rather than assumptions welded into the pipeline, moving to a quantum-safe algorithm — and running hybrid through the transition — is a controlled change, not a rewrite of the extraction stack. Crypto-agility is the architecture choice that decides whether the deadline is a release or a crisis.

The audit trail is re-sealable, so its signatures outlive their algorithm. The signed, replayable record of what was extracted and why is only evidence for as long as its signatures hold; a platform built for retention can re-sign and re-timestamp that trail on a quantum-safe scheme before the old one breaks, so a decade-old extraction stays provable rather than quietly becoming unverifiable in the archive.

The migration is governance evidence, not just an engineering task. Where a document platform serves regulated buyers, the cryptographic inventory, the migration plan and the re-sealing record become part of the governance evidence an auditor asks for — the demonstrable answer to "how will the documents you hold stay confidential and provable across their retention window," rather than a promise that encryption is handled.

Closing thought

The comfortable framing — post-quantum is a problem for the day the quantum computer arrives — is exactly the framing the harvest is designed to exploit. The threat to a long-retention document is not a future event; it is a present capture with a delayed payoff, and the documents most exposed are the ones a serious platform is built to keep: the contract, the record, the filing, the evidence that has to stay secret and provable long after the cryptography that protects it today has a known expiry. That is why the decision belongs on a board's desk now, with years of runway, and not in a scramble on the eve of Q-Day.

At Cogneris we treat the cryptography under a long-lived document as something that has to be migrated deliberately, not assumed to be permanent: an inventory of where every quantum-vulnerable algorithm touches a stored file, an architecture where the cipher and signature scheme are a pluggable decision, hybrid protection through the transition, and an audit trail we can re-seal on a quantum-safe algorithm so a decade-old extraction stays provable rather than merely stored — because a document you can be asked about in 15 years is a cryptographic commitment for its whole life, not just the day it was filed. If you are working out which of your long-retention documents are exposed to harvest-now-decrypt-later, and how to migrate their encryption, signatures and timestamps without a rewrite, see our product page, read the security page, or talk to our team. We would rather map the cryptographic exposure of your archive — what is stored, how sensitive, how long it must survive — in the first conversation than watch a harvested document surface, decrypted, as someone else's incident a decade from now.