The Database That Reports Its Own Cryptography, Per Dataset, On Demand

Every cryptographic inventory produced today is an outside view. A scanner reads binaries, configurations and traffic and infers what algorithms a system depends on. That is necessary work, and the discovery vendors do it well. It also has a ceiling: a scanner can tell you that a database encrypts, and often with what, but it cannot tell you which of the records written in 2019 still depend on a key established with an algorithm that retires in 2030, or which batches are signed under which scheme, or whether last quarter's migration reached everything.

Executive Order 14412 and OMB M-26-15 now ask agencies for a cryptographic bill of materials and for progress on re-encrypting long-lived data. The people filing those answers need something the scanner cannot give them: the data store's own account of its cryptography, per dataset, as of now. That is what the 8DB self-report is for,¹ and this is an invitation to shape what it files.

What the self-report is

8DB already holds the information. Every ciphertext produced through the engine's cryptographic registry carries an algorithm version. Keys are derived at use from a root secret and the record's governance state at write time. Batches are authenticated by one ML-DSA-87 signature over a SHA-384 Merkle root with per-record inclusion proofs. The engine's approved-mode boundary maintains an inventory of the primitives in use. The self-report turns that internal state into an artifact a compliance team can file.

For each dataset it states:

• Algorithm versions in use, for key establishment, record encryption and signatures, with the count of records under each version and the date range of their writes.
• Key epochs, so a reader can see which material is current, which is retained for historical reads only, and which is quarantined.
• Signature coverage, meaning which batches are authenticated, under which algorithm, and whether every record has an inclusion proof.
• Retirement exposure, the records that would be affected if a named algorithm were deprecated tomorrow, which is the question M-26-15 is really asking.
• Migration completion, after a transition, the records converted, the records explicitly excepted, and the difference between the two.

The export is CycloneDX 1.6, the format software bills of materials already use, validated against the schema when it is generated, so it can be filed, diffed and re-generated rather than written once for an audit and left to drift.

Why this feeds everything else

A migration program has three phases that never quite connect: discovery, execution and proof. The self-report is the connective tissue. It tells the discovery tool what it could not see, it gives the execution team its work list, and it produces the proof from the same source as the work. When the transition is repeated in the 2030s, the report is regenerated rather than rebuilt.

For NIST's discovery workstream and for the assessors who read agency filings, the value is a data source they can point tools at instead of a document they have to trust. For a program office, it is the difference between "we migrated the database" and a per-dataset statement with numbers.

What early access means

We are opening the program to a small number of teams who have to produce these answers for real: agency compliance and cryptography leads, integrators running M-26-15 programs, financial institutions preparing for examiner reviews under the G7 roadmap, and discovery-tool vendors who want a data source rather than a competitor. Participation is straightforward.

• You tell us what you file today. The exact fields your CBOM and migration-progress reports require, and the questions assessors ask that you cannot currently answer from the system.
• We build to that. Participants see the report fields before each release fixes them, and their requirements shape what ships next.
• You run it on your data. Early-access participants receive the engine and the report tooling to run inside their own environment, on a dataset they choose, with the benchmark and known-answer suite alongside so the cryptographic claims can be checked on the same machine.
• Nothing leaves your environment. The report is generated where the data lives. We see what you choose to show us.

Early access is free during the program. What we ask in return is the specificity of your requirements and candour about what the report gets wrong.

Where it stands

The mechanisms under the self-report are shipped: the algorithm version on every ciphertext, the key derivation model and the batch integrity path are in the engine today, and their cost profile is measured and published with raw logs on our stored-data evidence page. The export is shipped too: posture reports for managed inventory and managed restore, for parent and child stores, are generated as CycloneDX 1.6 documents and validated against the schema in the public evidence tree.² The early-access program decides which fields come next, and the reproducible end-to-end run, inventory to migration to completion report, is published with its harness.

Request a place

Write to hello@8braid.com with the subject "Early access: cryptographic posture self-report". Tell us who you file to, what they ask for, and one dataset you would want the report to cover. Places are limited so that each participant's requirements can actually be built; the first cohort is being formed now.

Sources and further reading

• NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility ↗, on inventory and agility-aware design
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards ↗
• NCCoE Migration to Post-Quantum Cryptography ↗, discovery workstream
• 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method
• 8DB: M-26-15 Asks Agencies to Re-encrypt What They Already Hold

Footnotes

1. The inventory the self-report reads from is shipped in the engine, and the CycloneDX 1.6 export is on the trustdb main branch. The early-access cohort shapes the fields that follow. See "Where it stands". ↩

2. Posture exports posture-*.cdx.json with posture-schema-validation.json are under combined-lifecycle-qualified-2026-09-12 and inventory-parts-qualified-2026-09-12 in the public evidence tree. The field definitions above are what the report states today; participants' requirements shape the next release's fields. ↩

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