Category 5 Keys in Software, on the Hardware You Already Have, No HSM Required

The reference architecture for post-quantum data protection assumes a key service. Keys are established, wrapped and rotated by a cloud KMS or a hardware security module, the database holds only symmetric material, and the transition is largely the key service's problem. That architecture is sound where it applies. It does not apply to a large share of the systems that hold the most sensitive long-lived data: platforms and vehicles in the field, sensors and controllers in operational technology, forward-deployed kits, air-gapped enclaves, and sites whose connectivity is intermittent by design or by adversary.

Those systems still fall under CNSA 2.0 and under the migration timelines. Their data is copied by adversaries as readily as any other and stays sensitive for as long. And their refresh cycles are measured in decades, so the protection they ship with now is the protection they will have when quantum-vulnerable algorithms are disallowed in 2035. This article is for the program managers, system engineers and security architects responsible for that class of system, and for the primes and integrators who build it.

What the constraint changes

Take away the key service and three things the reference architecture relied on have to be provided somewhere else.

• Key establishment. Without an HSM or KMS, the system must establish post-quantum keys itself, in software, on whatever processor it has, and must do so without leaving a key database on the device that a captured unit hands to the adversary.
• Integrity at post-quantum signature sizes. ML-DSA-87 signatures are 4,627 bytes. A logging or telemetry store that signs every record independently spends more storage on signatures than on data, on hardware that has neither to spare.
• Migration without an operator. When an algorithm retires, the fleet cannot be brought in for a re-encryption project. The transition has to be a state the store can enter and complete on its own, with reads continuing and with an account of what it could not reach.

Crypto gateways are the usual proposal for legacy and OT environments: place a device in front of the system and let it translate. Gateways protect the channel. They do nothing for the data already at rest inside the system, which is where the long-lived exposure lives.

How 8DB meets the constraint

8DB is an embedded data engine written in Rust with unsafe code denied. It runs in process, in software, on commodity hardware, and it was designed for exactly the case where the key service is absent.

Category 5 key establishment in software. Keys for stored data are established with ML-KEM-1024 (FIPS 203) in a hybrid with X25519, in process, with no external dependency. The implementation uses a constant-time, KyberSlash-patched ML-KEM crate and constant-time comparisons across its cryptographic paths.

No key database on the device. 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 captured unit yields ciphertext and no table of keys.

Per-record cost held constant. Each record is encrypted with AES-256 (AES-256-GCM-SIV by default; an AES-256-GCM profile is available for approved-mode deployments). 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.¹ The post-quantum cost appears once per established key as a 1,616-byte object and is accounted separately.

Integrity without per-row bloat. Batches of records are authenticated by one ML-DSA-87 (FIPS 204) signature over a SHA-384 Merkle root, with a per-record inclusion proof. The 4,627-byte signature is paid once per batch. A single record, its proof and the signed root can be handed to a verifier without the rest of the batch.

Protection that travels with the record. A sealed record can move as the sealed object, so its confidentiality does not depend on the link it crosses. The transport becomes defence in depth rather than the security boundary, which matters when the link is a radio, a removable medium or a courier.

A note on labels, because programs read them carefully. Content is protected at Category 5 before it enters any channel: each record is sealed under an ML-KEM-1024 hybrid key with AES-256, and it moves as the sealed object. Where a public TLS edge is used, the channel negotiates the X25519MLKEM768 hybrid, which CNSA 2.0 classifies at Category 3; that channel is defence in depth around data that is already Category 5.² The security boundary is the sealed record, not the pipe. A design in which TLS is the security boundary would be Category 3. This one is not.

Migration as a state, not a recall. 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 NIST CSWP 39 section 5.1 calls for, and it is the one a fleet needs when it cannot come home.

What you can run today

The measurements above are published with their raw logs on our stored-data evidence page. 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 any machine that can build the engine, which is the right test for hardware you control.

On a running store: inventory of every stored artifact that depends on a retired algorithm, migration while reads continue, an account of anything left unconverted, and proof that a restart or a restored image does not revive obsolete keys or retired authority, published with its harness and evidence folders.⁴ For fielded systems, the last point is the one that matters most: a unit restored from an old image obeys today's policy, not the policy it was imaged under.

On assurance

Programs in this space ask about validation before anything else, and they should. Our position: algorithm correctness is demonstrated today against NIST's test vectors on the demonstration server; the approved-mode profile inherits its primitives from aws-lc-rs; a production CAVP certificate through an accredited laboratory is in procurement.⁵ The stored-data profile uses the CNSA 2.0 suite at Category 5 throughout: ML-KEM-1024, ML-DSA-87, AES-256 and SHA-384.⁶ Programs that must evaluate the mechanism now, ahead of certification capacity across the whole industry, can do so on evidence that does not depend on it, and they can reproduce that evidence on their own target hardware.

What to bring us

The useful first conversation is about one platform.

• One fielded system. Its processor and memory envelope, its storage, its connectivity pattern, the data it holds and for how long, and who must be able to recover it. We will return an acceptance plan that states what is protected, against which adversary, with which algorithms, and what remains outside the boundary.
• Your target hardware. The benchmark and known-answer suite run from source with one command each. Ask for the reproducibility package and run it on the board, not on our laptop.
• Your recovery scenario. The captured-unit and restored-image cases you must evidence are the cases we want the demonstration to cover.

Write to hello@8braid.com with the subject "Category 5 stored data on fielded systems". You will hear back from an engineer.

Sources and further reading

• NSA CNSA 2.0 Cybersecurity Advisory ↗
• NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility ↗, sections 4.4 to 4.6 on legacy, embedded and operational technology
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards ↗
• NIST FIPS 203: ML-KEM ↗ and FIPS 204: ML-DSA ↗
• 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method
• 8DB: What a Post-Quantum Database Actually Has to Protect

Footnotes

1. 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), with the same cipher on both sides; raw logs on the stored-data evidence page. ↩

2. A Category 5 TLS group is scheduled. Until then the public TLS edge is Category 3 defence in depth around records that are already sealed at Category 5. ↩

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

4. The transition on a running store is on the trustdb main branch (PR #3484, merged 2026-09-12), with 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. ↩

5. We describe the ACVP result as algorithm-correctness evidence and will continue to until the certificate exists. ↩

6. CNSA 2.0 is an algorithm suite built on NIST standards, not a certification. Using the suite's algorithms is a design property we can show on any host; a CAVP algorithm certificate and, for a module, CMVP validation are what an accredited laboratory adds, and no vendor grants a programme's authorisation. ↩

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