Your Backups Are the Quantum Attack Surface Nobody Inventoried. 8DB Inventories Them From the Record and Migrates Them With the Data.

A cryptographic inventory answers the question "what does this system use today". It does not answer "what did it use in 2019, and where are the copies". Yet every migration programme now running is being scoped by the first question, and the exposure that matters most lives in the second.

A backup is a frozen copy of the envelope. If a data key was wrapped with RSA when the snapshot was taken, that wrap is in the snapshot forever. If the archive manifest was signed with an elliptic-curve key, so is every copy of the manifest. Rotate the live system tomorrow and the backup is unchanged. An adversary who has been collecting your backups, replicas and tape does not need your production system to fall; they need the algorithm in the envelope to fall, on a schedule NIST has already published.

This article is for the people who own backup, disaster recovery and data protection in organisations with long retention: infrastructure and storage leads, security architects, and the programme managers now writing M-26-15 and G7-roadmap migration plans. It sets out why stored copies are the hard part of the migration and what a data system has to do so they are not.

Where the exposure actually is

Symmetric encryption is not the problem. AES-256 stays approved under NIST IR 8547 and a backup encrypted under a purely symmetric hierarchy has no quantum exposure in its bytes. The exposure is the asymmetric envelope around those bytes, and backups multiply it in three ways.

• Key wrapping. Data keys shared or exported with RSA or elliptic-curve key agreement are in every copy that was taken while that wrap was in use.
• Signatures. Manifests, catalogues, integrity certificates and audit records signed with classical algorithms are forgeable later, and long-lived copies are exactly where a later forgery matters.
• Authority. A backup also freezes who was allowed to read what. Restore it into a system whose policy has since revoked a reader, and a naive restore revives that reader's authority along with the data.

The first two are cryptographic. The third is operational, and it is the one most restore procedures never consider.

What the migration has to do about copies

A re-encryption programme that satisfies the guidance has to be able to say four things about every copy of long-lived data, not only the live instance.

1. Which algorithm each stored record depends on, determined from the data, so the inventory covers the warehouse as well as the front door.
2. That the envelope was changed, or the copy was explicitly excepted and scheduled, with completion accounted per record.
3. That a restore obeys today's policy, not the policy in force when the copy was taken.
4. That the whole exercise can be repeated when the next algorithm retires, because it will.

Most estates answer these with a project per system and a spreadsheet per project. The reason is architectural: the algorithm is not a property of the record, so nobody can ask the records.

How 8DB treats copies

In 8DB the algorithm is a property of the record. Every ciphertext produced through the engine's cryptographic registry carries an algorithm version, and that version travels with the record into every snapshot, replica and archive. The question "which stored records still depend on a retired algorithm" is a query over the store, and it is the same query for a live instance and a restored copy.

Key establishment for stored data uses ML-KEM-1024 in a hybrid with X25519, so the envelope a copy carries forward is already post-quantum. Data keys are never stored; they are derived at use from a root secret and the record's governance state at write time, so a stolen backup yields ciphertext and no key table. Batch integrity is one ML-DSA-87 signature over a SHA-384 Merkle root with a per-record inclusion proof, so a copy's integrity is checkable years later without trusting whoever kept it.

Recovery under current authority is a tested operation of the store:¹ an old backup restored into a store whose policy has since revoked a reader does not revive that reader. Governance state is part of the record and part of the key, so the restore is judged by today's policy rather than by the policy frozen in the copy. Two versions of an algorithm can be registered at once, the new one active for writes and the old one still decrypting, and a quarantined algorithm refuses new writes while continuing to serve reads, so a restored copy under an older version is readable during its migration and not writable under the retired algorithm.

The cost, measured

The cost model is published with raw logs on our stored-data evidence page: a 115-byte record encrypts to 131 bytes whether its key came from a classical key-derivation function or from ML-KEM, with median per-record times within one percent on four hosts,² and the post-quantum cost accounted once per established key and once per signed batch. Crash and power-loss recovery over committed sealed data is a tested claim in our independent evaluation package.

What to bring us

• Your retention schedule. The datasets you must keep past 2030 and 2035, where their copies live, and how they are protected today. We will map them to the four questions above and return an acceptance plan.
• One restore scenario. The backup you would least like an adversary to hold, and the reader you have revoked since it was taken. That is the case the lifecycle evidence already covers, and the one we will run on your copy.
• The reproducibility package. The benchmark and known-answer suite run from source with one command each, on your hardware.

Write to hello@8braid.com with the subject "Backups in the PQC migration: acceptance 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 ↗, section 5.1
• 8DB: M-26-15 Asks Agencies to Re-encrypt What They Already Hold
• 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method

Footnotes

1. The restored-backup case with a revoked reader is enforced by current-authority checks through native data migration and managed recovery, merged to the trustdb main branch in PR #3484 on 2026-09-12, with retained-copy accounting. Evidence folders protection-lifecycle-2026-09-11, managed-restore-source-2026-09-12 and combined-lifecycle-qualified-2026-09-12 in the public evidence tree hold the runs, and the harness is written so a second evaluator can reproduce them. ↩

2. Measured in release builds on four hosts: Windows on a Ryzen 7 7800X3D (2026-07-19), Linux x86_64 on a Xeon (2026-09-11), Windows on a Ryzen 9 9950X3D (2026-09-11) and Linux aarch64 on a Graviton3 (2026-09-12). The hosts, the harness and the raw logs are on the stored-data evidence page linked above. ↩

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