The connection closes. The data stays. A sensitive record may spend years in a database, appear in an index, travel to another node and return from a backup. Securing its first journey leaves an important question: what protects each copy afterwards?
8DB, our omnimodal database, brings record protection, typed data and authority checks into selected native storage and transfer paths. The practical opportunity is to evaluate a connected lifecycle: where the data is stored, who can open it, what crosses the network and what recovery allows.
For a buyer planning a post-quantum transition, that is a more useful starting point than a feature label. Pick a valuable record and follow it.
Draw the record's actual journey
Start with the application that creates it. Identify the persistent record, the index that finds it, any temporary output, and the backup that can restore it. Add recipients and the applications that will use their copies.
Each step needs an answer about encryption, key custody and authorized plaintext. The same answer will not cover them all. A well-protected network message can be opened by its intended recipient; the recipient's process and storage then become part of the security assessment.
In 8DB's source-reviewed protected-node composition, the sender creates a fresh recipient-specific encrypted message. The authorized receiver verifies and opens it, then seals the typed records under its own local protection. Participating nodes can therefore retain the same logical data without sharing a storage root.
The recipient receives newly encrypted endpoint content and reseals it for local storage. That makes the key and plaintext boundaries explicit while preserving protection across the handoff.
One logical record · Separate protection boundaries
Follow the data, and the authority to open it.
The reviewed protected-node path gives the message and each local copy their own protection.
- Sender endpoint
Protected local record
An authorized process reads the admitted typed content under its local custody rules.
Local storage root stays here. - Network journey
Recipient-specific message
A fresh encrypted, authenticated frame carries content to the intended peer.
Routing metadata remains observable. - Receiver endpoint
Protected local copy
The authorized receiver verifies, opens and applies the records under local protection.
A separate storage root protects this copy.
Keeping a relay from opening a payload does not remove trust in the authorized processes that use it.
Put each cryptographic job in the right place
Bulk record encryption, key establishment and signatures do different work. NIST's post-quantum guidance distinguishes the public-key transition from the continued use of symmetric encryption. A review should follow the protection of the data key as well as the cipher used on the data.
The protected-node path uses ML-KEM-1024 to establish a message secret and ML-DSA-87 to authenticate its frame. Its source review identifies the encryption provider, bound message context and receiver checks. Local storage has its own protection profile and root-custody requirements.
Our stored-data measurements examine a separate question: how key establishment relates to a fixed record-encryption path. They should not be read as the complete cost of protected peer delivery. Setup, signing, message framing, durable application and recovery all belong in that workload's measurement.
This separation helps an engineering team place the work deliberately and measure it honestly. It also makes an evaluation easier to change when the application needs a different recovery or delivery guarantee.
Make search and recovery part of the plan
A protected record is less useful if its index or derived output falls outside the intended boundary. Ask which indexes are sealed, where they are opened, and what queries expose through access patterns, result sizes or cached plaintext. Opening an encrypted index inside an authorized process is a distinct capability from computation that never reveals plaintext to that process.
Recovery needs equal attention. An intact historical backup may still carry earlier protection or access state. Our migration and restore guide describes a bounded key-derivation transition with registered archives and current-authority checks. Use that as a starting point for a deployment test, rather than assuming that every retained copy or algorithm transition has been covered.
| Part of the journey | Evidence to request |
|---|---|
| Stored record and index | Exact profile, protected files and authorized-open behavior |
| Processing and derived output | Plaintext boundary, temporary storage and disclosure rules |
| Peer delivery | Recipient identity, replay handling, admitted schema and durable outcome |
| Backup and restore | Retained-copy inventory, recovery secrets and intended access results |
| Implementation change | Source and executable identity, affected tests and successor evidence |
Evaluate the complete route
Existing databases, transport security and key-management systems can be assembled into a protected workflow. The question is how much integration and evidence maintenance that particular route requires. 8DB's opportunity is to bring more of the data operations and their protection into one native composition. A matched evaluation should test whether that helps your team in practice.
Use the dated qualification status to distinguish source inspection, retained test artifacts and fresh execution on a named build. Selection of standardized algorithms does not itself certify the database or its deployment. No new product run is reported in this article.
Bring us one record lifecycle to evaluate. Start with a non-sensitive description of its storage, search, recipients and recovery requirements. We can map the required protection and evidence before choosing a test deployment.
Evidence scope Architecture guide · Pinned protected-node review · Recorded storage evidence. Explore the evidence. The reviewed integrated profile uses a defined structured-record schema; integrating and qualifying your schema is the first step of an evaluation. Methods and retained scope notes.