Every agency now has two lists. The first comes from inventory tooling and says which systems still depend on quantum-vulnerable cryptography. The second is the one OMB M-26-15 actually asks for: the long-lived sensitive data that must be identified and re-encrypted under keys protected by post-quantum mechanisms. The first list is being produced at speed. The second list has a problem the tooling does not solve. It tells you what is exposed. It does not tell you where the data goes afterwards, how you prove the move finished, or what happens when the algorithm you moved to is itself retired in the 2030s.
That gap is where migration programs stall, and it is the problem 8DB was designed around. This article sets out what the stored-data instruction requires in operational terms, what an assembled stack of tools can and cannot show, and what we have measured, published and committed to demonstrate so an agency can evaluate the work on evidence.
First, what AES already covers
The people who wrote the guidance know this, so the people answering it should say it plainly. Symmetric encryption at rest is not what a quantum computer breaks. NIST IR 8547 keeps AES-256 approved; the 2030 deprecation and 2035 disallowance apply to RSA, elliptic-curve and finite-field public-key algorithms. A database whose records are encrypted with AES-256 under a purely symmetric key hierarchy has no quantum exposure in its stored bytes today.
What is exposed is the asymmetric envelope around those bytes: how data keys are established or shared, how stored objects, backups and audit records are signed, and how any of that can be replaced later. What hurts is the migration itself. M-26-15 is, in practice, an instruction to move the envelope and to be able to prove it, for data that will still matter in 2040.
Five operations hiding inside "re-encrypt"
A migration plan that says "swap the algorithm" compresses five different operations, each with its own definition of done. NIST CSWP 39 section 5.1 states the requirement for data at rest: a mechanism must exist to handle encrypted user data when the algorithm is replaced by a stronger one. Meeting it means being able to name which of these you are doing and to show each one completed.
| Operation | What changes | What completion must show |
|---|---|---|
| Key rotation within one cipher | Key material or epoch | New writes use the new key; authorized historical reads still resolve; retirement is explicit |
| Key-protection transition | How a data key is established, exchanged or wrapped (the post-quantum case) | The cryptographic dependency actually changed; old envelopes are accounted for |
| Data-cipher replacement | The cipher or mode over stored content | Existing ciphertext converted or explicitly excepted; an interrupted conversion stays coherent |
| Signature transition | The algorithm that authenticates stored objects and records | New evidence authenticates the intended content; historical validation rules stay explicit |
| Authorization-policy transition | Who may recover or read recovered data | Old grants inside a backup cannot override current policy |
The last row is the one most programs forget and the one auditors will find. A backup taken before a reader was revoked is a valid backup. Restoring it must not revive that reader's authority or a retired key. Recovery under current authority is a property of the data system, not of the algorithm.
What the assembled stack shows, and what it does not
An agency can describe a credible quantum-safe posture at rest in 2026 from parts that already exist: AES-256 transparent encryption, a symmetric key hierarchy in a cloud KMS or HSM, hybrid post-quantum TLS to the key service, and an online rekey command in the database. That is a real posture and it should be stated without embarrassment.
What it does not give the program is the second list. Rekey commands rewrite datafiles and report at the tablespace level, not the record. Key services rotate keys but do not know which stored records still depend on retired material. Backup products add algorithm agility to the archive, not to the system of record. Signed-object integrity at the record level is mostly absent. And each system in the estate has its own version of all of this, so the migration is one project per system, repeated at the next transition.
The requirement, then, is an engine that treats the algorithm as a versioned property of the record, performs the migration as a database operation with reads continuing, accounts for what remains unconverted, and recovers under current policy. Several of these mechanisms have prior art in individual products. What agencies have not had is one system that ties them to actual records, indexes, backups and access decisions with reproducible completion evidence. That is what 8DB is, and what we measure, following the direction NCCoE has already set for database protection and record integrity.
What 8DB does, and what we have measured
8DB is an embedded data engine written in Rust with unsafe code denied. Its design places the post-quantum cost at the boundaries where it belongs and keeps the per-record path unchanged.
- Key establishment for stored data uses ML-KEM-1024 (FIPS 203) in a hybrid with X25519, in software on commodity hardware.
- Each record is encrypted with AES-256. The default mode is AES-256-GCM-SIV; an AES-256-GCM profile is available for approved-mode deployments.
- Data keys are never stored. Each is derived at use from a root secret and the record's governance state at the time it was written, so there is no key database to exfiltrate.
- Every ciphertext produced through the engine's cryptographic registry carries an algorithm version. Two 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. This is the mechanism CSWP 39 section 5.1 calls for.
- Integrity is one ML-DSA-87 (FIPS 204) signature over a SHA-384 Merkle root per batch, with a per-record inclusion proof, so the 4,627-byte signature is paid once per batch instead of once per record.
The measurements are published with their raw logs on our stored-data evidence page. With the same cipher on both sides, a 115-byte record encrypts to 131 bytes whether its key came from a classical key-derivation function or from ML-KEM, and median per-record encrypt and decrypt times agreed within one percent on four hosts.1 The post-quantum cost appears once per established key as a 1,616-byte object and once per signed batch, and is accounted separately. The ML-KEM-1024 and ML-DSA-87 implementations passed NIST's ACVP demonstration server in June 2026, and a 35-vector offline known-answer suite reproduces that result on demand.2
The transition itself, demonstrated in public
The measurements above establish the cost model. The operation M-26-15 asks for is the transition itself, and we treat it as the thing to prove rather than the thing to describe. The demonstration, with its harness and evidence folders, shows five things:3
- The database publishes its own cryptographic inventory: algorithm versions, key epochs and signature coverage per dataset, as a CycloneDX 1.6 cryptographic bill of materials, validated against the schema when it is generated.
- It identifies every stored artifact that depends on a retired algorithm: pages, indexes, blobs, logs and snapshots.
- It changes the protection while continuing to serve reads, naming which of the five operations it performs.
- It accounts for anything left unconverted, so completion is a statement with exceptions rather than a hope.
- It shows that a restart or an old backup does not silently restore obsolete keys or retired authority.
Every step produces evidence a second evaluator can reproduce. We think that standard is what a program office should demand from any vendor, including us, and we have written our acceptance criteria that way.
The same engine already underpins a regulated-settlement product built for operators with similar evidence obligations: Sovereign Clearinghouse, which 8Braid builds and operates under our Digital Fabric settlement brand, commits every clearing decision to a replayable audit chain with policy bound in as a precondition and per-observer disclosure for different supervisors. Programs that must show an assessor why a decision was valid when it was made will recognise the pattern.
What to bring us
If you own a program that must show M-26-15 progress on stored data, three things are worth an hour of your time and ours.
- A data class. Tell us about one long-lived sensitive dataset: its size, its retention horizon, the systems it lives in, and who must be able to recover it. We will map it to the five operations above and return an acceptance plan your security, data and platform teams can hold us to.
- Your failure cases. The scenarios your inventory found hardest to evidence, whether coverage, completion, interrupted conversion or recovery under current policy, are the ones the demonstration covers; bring them and we will run them on your data class.
- A workload to reproduce on. The benchmark and the known-answer suite run from source with one command each. Ask for the reproducibility package and run it on your own hardware.
Write to hello@8braid.com with the subject "M-26-15 stored-data acceptance plan". The reply will be an engineer, not a deck.
Sources and further reading
- NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility, section 5.1 on encrypted data at rest
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards
- NIST FIPS 203: ML-KEM and FIPS 204: ML-DSA
- NCCoE Migration to Post-Quantum Cryptography
- 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method
- 8DB: What a Post-Quantum Database Actually Has to Protect
Footnotes
-
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 raw logs are on the stored-data evidence page. ↩
-
ACVP demonstration-server session 744723, June 2026. Programs are right to ask about certification, and our position is the one the guidance itself anticipates: algorithm correctness is demonstrated today against NIST's test vectors on the demonstration server; the approved-mode profile inherits primitives that are themselves validated, through aws-lc-rs; a production CAVP certificate through an accredited laboratory is the next step. We describe the result as algorithm-correctness evidence, not as validation, and we will keep describing it that way until the certificate exists. An agency that wants the transition mechanism evaluated now, while certification capacity catches up across the whole industry, can do so on evidence that does not depend on the certificate. ↩
-
The running-store transition is on the trustdb main branch (PR #3484, merged 2026-09-12): current authority enforced through native data migration and managed recovery, retained-copy accounting, and CycloneDX 1.6 posture exports with schema validation. Evidence folders
protection-lifecycle-2026-09-11,managed-restore-source-2026-09-12,combined-lifecycle-qualified-2026-09-12andinventory-parts-qualified-2026-09-12hold the runs; the measurements in the preceding section are published with raw logs on the stored-data evidence page. ↩
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