The 2035 Migration Is Already Scheduled. Is Yours?

Most technology migrations are reactive. Something breaks, a vendor ends support, a regulator arrives, and the organisation moves. The post-quantum transition is different in one way that almost nobody is planning for: the next one is already on the calendar. NIST IR 8547 deprecates 112-bit-security public-key algorithms in 2030 and disallows quantum-vulnerable algorithms in 2035. The standards process has already opened the next round of signature schemes. Hybrid constructions are treated as the steady state for a decade, not a stopgap. Whatever you migrate to now, you will migrate again, and the date is known.

That changes the question. It is no longer "how do we get to ML-KEM and ML-DSA" but "how do we make algorithm replacement on stored data a routine operation, so that 2035 is a change ticket rather than a programme". This article is for the architects and programme leads writing those plans: in agencies under M-26-15, in financial institutions under the G7 roadmap, and in any organisation whose data outlives its cryptography. It describes what repeatable agility requires and how 8DB delivers it.

Why most systems will migrate twice

Ask what "swap the algorithm" means for a system that has been storing data for ten years, and it turns out to be five different operations, each with its own definition of done: rotating keys within a cipher, changing how keys are established or wrapped, replacing the data cipher itself, moving signatures to a new algorithm, and ensuring an old backup cannot revive authority that has since been revoked. NIST CSWP 39 section 5.1 asks for a mechanism that handles encrypted data at rest when the algorithm is replaced. Most systems have no such mechanism, because the algorithm was never a property of the data. It was a property of the code, the configuration, or the key service, and the data merely inherited it silently.

So the first migration becomes a project: find every artifact, rewrite it, verify it, repeat per system. When 2035 arrives, nothing about that project is reusable except the pain, because the new data is as silent about its algorithm as the old.

What repeatable agility requires

1. The algorithm has to be a versioned property of each record, so the question "what depends on the retiring algorithm" can be asked of the data.
2. Two versions have to coexist, with the new one active for writes and the old one still decrypting, so the transition happens while the system runs.
3. Retirement has to be a state, so a deprecated algorithm can refuse new writes while continuing to serve reads until the sweep completes.
4. Completion has to be accountable, per record, with exceptions stated rather than hoped away.
5. Recovery has to obey current authority, so a restored copy under an old version does not revive retired keys or readers.

A system with those five properties migrates once, and the second time it changes a registry entry and runs a sweep.

What 8DB has built

Every ciphertext produced through 8DB's cryptographic registry carries an algorithm version. Two algorithm versions can be registered at once, the new one active for writes and the old one still decrypting, and an algorithm placed in quarantine refuses new writes while continuing to serve reads. Version dispatch is tested at the registry layer and exercised end to end on a running store: the engine changes the protection profile under live reads, accounts for completion per record, refuses to declare the migration complete while a registered copy still carries the old profile, and judges every restore by current authority. Key establishment uses ML-KEM-1024 in a hybrid with X25519, records are encrypted with AES-256, and integrity is one ML-DSA-87 signature per batch over a SHA-384 Merkle root, so the envelope being versioned is already post-quantum and the per-record cost is unchanged.

The operation on a running store, with reads continuing, unconverted records accounted for and recovery under current authority shown, is published with its harness and evidence folders, and each test names which of the five operations it performs, because "algorithm swap" is a phrase reviewers take apart and we would rather take it apart first.¹

Where the incumbents stand

Mainstream databases are not fixed-algorithm systems. Online tablespace rekey and conversion exist, key services rotate material, backup products advertise agility for the archive, and versioned ciphertext with a retirement floor is an established pattern in secrets managers. Each is a real capability and each covers part of the requirement. What none of them offers is one engine in which the version is on every record, coexistence and quarantine are states of the store, completion is accounted per record, and recovery is judged by current policy.²

What a plan written for 2035 looks like

A plan that expects the second migration puts the algorithm version on the record now, so the 2035 inventory is a query. It tests recovery under current authority now, because that property does not depend on which algorithm is retiring. It writes acceptance criteria as evidence a second evaluator can reproduce, so the 2035 sign-off reuses the 2026 method. And it chooses systems whose cost profile does not rise with each transition, which is why the per-record parity measurement matters.

What to bring us

• One long-lived dataset and its retention horizon. We will return a plan that names the five operations as they apply to it, and the evidence each requires.
• Your 2030 and 2035 milestones. The dates your programme office has committed to. We will show which of them become routine with a versioned store.
• Your evaluator. The reproducibility package and the evaluator bundle exist so your assurance team can check the mechanism before anyone from 8Braid is in the room.

Write to hello@8braid.com with the subject "Repeatable crypto agility: migration plan". You will hear back from an engineer.

Sources and further reading

• NIST IR 8547: Transition to Post-Quantum Cryptography Standards ↗
• NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility ↗
• 8DB: Your Backups Are the Quantum Attack Surface Nobody Inventoried
• 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method

Footnotes

1. The registry mechanism (versioning, coexistence, quarantine) is tested at the registry layer. The running-store transition, with recovery under current authority and retained-copy accounting, is on the trustdb main branch (PR #3484, merged 2026-09-12); evidence folders protection-lifecycle-2026-09-11, managed-restore-source-2026-09-12 and combined-lifecycle-qualified-2026-09-12 hold the runs, and the posture exports that account for completion per dataset are CycloneDX 1.6 documents under the same tree. The test behind each of the five operations is named in the 21-questions grid. ↩

2. Each incumbent capability named here is real and documented by its vendor. The comparison is against the combination in one engine, and the 21-questions grid states, cell by cell, what we checked for each. ↩

Continue the technical conversation

Where could this help your work?

Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.

Discuss this work