The Next RFP Question Is About Your Stored Records. Build the Answer, or Embed It

There is a question that has not yet appeared in most RFPs and will appear in nearly all of them. It sounds like this: "When one of your cryptographic algorithms is deprecated, how do the records our users already stored in your product move to the replacement, without an outage, and how do we prove afterwards that they all moved?" Buyers under OMB M-26-15, under CNSA 2.0 timelines, and under the G7 roadmap for the financial sector are being told to ask it. NIST CSWP 39 section 5.1 states it as a requirement for data at rest. The first time it is asked of your product, there are two possible answers. One is a roadmap. The other is a demonstration.

This article is for the people who decide which answer their product gives: CTOs and platform leads at software vendors, records and case-management providers, secure collaboration and messaging companies, and the integrators and defence primes who assemble systems for buyers with long retention horizons. It lays out what the requirement is, what building it costs, and what changes when the capability is an engine you embed rather than a subsystem you own.

The requirement is bigger than "support ML-KEM"

Adding post-quantum algorithms to a product is now a library upgrade. OpenSSL 3.5, AWS-LC, SymCrypt and the platform key services all ship ML-KEM and ML-DSA. That is the easy half, and it is largely finished for transport.

The hard half is stored state. A product that has written records for five years holds ciphertext, key envelopes, signatures, indexes, backups and audit trails that all encode a cryptographic decision made at write time. Migrating them is not one operation but five: rotating keys within a cipher, changing how keys are established or wrapped, replacing the data cipher itself, moving signatures to a new algorithm, and making sure an old backup cannot revive authority that has since been revoked. Each has a different definition of done, and a buyer's assessor will ask for evidence of each.

Then it has to be done again. IR 8547 deprecates 112-bit security in 2030 and disallows quantum-vulnerable algorithms in 2035, and the standards process has already opened the next round of signature schemes. A product that treats the transition as a one-time migration project will run that project at least twice.

What building it yourself costs

The parts exist and are good. A cloud KMS or HSM rotates keys and signs with ML-DSA. A mainstream database rekeys a tablespace online. A backup product adds algorithm agility to the archive. Ledger features produce externally checkable digests. A team can assemble these, and a sceptical buyer will expect you to have considered doing so.

What the assembled version costs is integration and repetition. The key service does not know which records still depend on retired material. The rekey command reports at the file or tablespace level, not the record, and it rewrites data rather than versioning it. Per-record integrity at post-quantum signature sizes needs its own batching design, its own tree maintenance, and its own atomicity with the store. Recovery under current policy has to be built into restore. Multi-modal products, with relational, document, vector and file data in different stores, do all of this once per store. And when the next algorithm retires, the whole assembly has to be revisited.

For most product teams this is a year of specialist work that produces no feature a customer can see, followed by a certification conversation about the parts you wrote yourself near the cryptography. That is a rational thing to avoid.

What changes when the engine is embedded

8DB is an embedded data engine. It is written in Rust with unsafe code denied, it runs in-process on commodity hardware with no HSM or key-service dependency, and it was designed around the operation described above rather than retrofitted for it. Embedding it changes four things about your product's answer.

The algorithm becomes a versioned property of the record. 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. Your product does not need a migration mode; it has a state.

The post-quantum cost is paid where it belongs. Key establishment uses ML-KEM-1024 (FIPS 203) in a hybrid with X25519, once per established key. Each record is encrypted with AES-256 (AES-256-GCM-SIV by default, with an AES-256-GCM profile for approved-mode deployments). 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 not repeated beside every row. Your storage and latency budgets are not surrendered to the transition.

There is no key database to protect or migrate. 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. A whole class of key-management integration disappears from your product.

One migration covers every modality. Relational, graph, vector, spatial, file and media data can live in one engine under one protection model, so the transition is one operation, not one per store.

Products already built on it

The embedding model is not hypothetical; we use it ourselves, in two very different markets.

BraidEra ↗, our evidence-native computational drug discovery platform, is the most demanding product we run on 8DB. It simulates a therapeutic program across resolution layers from quantum and atomic structure to pathway, cell, tissue and organism, and every prediction carries an evidence tier, a confidence vector and a falsifiable criterion. That only works because the substrate underneath holds quantum, chemical, structural, network and organism-scale state as atoms in one engine, carries confidence at the storage layer, preserves the order of path-dependent biology, and keeps every result attributable. BraidEra's users see a drug-discovery program; 8DB is what makes its evidence auditable and its memory persistent.

Sovereign Clearinghouse ↗, which 8Braid builds and operates under our Digital Fabric ↗ settlement brand, is a regulated clearing service built on 8DB, in which sanctions, jurisdiction and operator policy are hard preconditions on every routing decision and each decision is committed to a replayable audit chain with per-observer disclosure. Its users see a clearing console; the engine underneath is what makes the evidence replayable.

That is the shape we expect embedding to take for your product as well: your interface, your customer relationship, our substrate doing the cryptographic, governance and provenance work you would otherwise have to build.

What we have measured, and what you can run yourself

Product teams should distrust architecture diagrams, including ours, so here is what has been executed. 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 both hosts.¹ The post-quantum cost appears as one 1,616-byte object per established key and one signature per batch, accounted separately. The ML-KEM-1024 and ML-DSA-87 implementations passed NIST's ACVP demonstration server,² and a 35-vector offline known-answer suite reproduces that result on demand. The raw logs are on our stored-data evidence page, and the benchmark and known-answer suite run from source with one command each.

Next comes the transition itself: a running store under load, reads continuing, completion accounted, and recovery under current authority proven, published here with its harness and failure corpus.³ If you are evaluating engines, hold every candidate to that standard.

The commercial shape of it

Embedding a data engine is a platform decision, so we will be specific about how we expect it to work. We work with vendors on component terms: your product ships the engine, your customers see your product. The transition capability, the batch integrity model and the measured cost profile become features you can put in front of a buyer, backed by evidence you can reproduce on your own hardware rather than ours. The compliance story is inherited rather than invented: algorithm correctness demonstrated against NIST vectors today, primitives inherited through aws-lc-rs in the approved-mode profile, a production CAVP certificate through an accredited laboratory as the next step. You are not writing new code near the cryptography, and you are not the one explaining that to an assessor.

Where to start

The right first conversation is technical and short.

• Send us one record type. The schema, the retention horizon, the modality mix, and the integrity requirement your buyers state. We will return an evaluation plan that names the five transition operations as they apply to it, with acceptance criteria your architects can hold us to.
• Run the harness. Ask for the reproducibility package and execute the benchmark and known-answer suite on your build machines before anyone from 8Braid is in the room.
• Tell us the RFP language you are seeing. The exact clauses your buyers are starting to include shape what we publish next.

Write to hello@8braid.com with the subject "Embedding 8DB: evaluation plan". You will get an engineer and a plan, not a partnership deck.

Sources and further reading

• NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility ↗, sections 5.1 and 6.2
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards ↗
• NIST FIPS 203: ML-KEM ↗ and FIPS 204: ML-DSA ↗
• NSA CNSA 2.0 Cybersecurity Advisory ↗
• 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method
• 8DB: The Category 5 Bill Is Paid Once or Paid Per Record

Footnotes

1. Measured in release builds on Windows and Linux x86_64, with the same cipher on both sides. ↩

2. June 2026, ACVP demonstration server session 744723. The demonstration server exercises algorithm correctness against NIST's test vectors; it is not a CAVP certificate. ↩

3. The live 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. 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 acceptance criteria are written so a second evaluator can reproduce every step. ↩

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