A vehicle can lose its network connection while its data still needs protection. If every cryptographic operation depends on a remote service, connectivity becomes part of the mission's availability budget.
8DB offers a software path worth evaluating for that setting. The reviewed implementation establishes post-quantum message protection locally and derives local storage keys from secret root material and context. It does not require an HSM or a cloud key-service call for those operations. That gives an integrator another way to deploy protected data capabilities on a platform with intermittent connectivity.
The design still needs a custody plan. The root secret, endpoint keys and trusted identities remain security-critical. Keeping them protected is how the deployment earns the benefit of local operation.
Bring the operation onto the platform
Our source-bound protected-node explanation identifies the components and their responsibilities. The inspected path uses ML-KEM-1024 for recipient-specific key establishment, ML-DSA-87 for message authentication, and a selected AES-256-GCM storage and message-protection profile. Third-party cryptographic implementations remain embedded dependencies.
These are the Category 5 ML-KEM and ML-DSA parameter sets described by NIST FIPS 203 and FIPS 204. Category 5 describes algorithm security strength. A deployed product needs its own implementation, protocol and assurance review.
For an engineer, local execution opens a practical option: separate the availability of approved local work from the availability of the network. Test that option with the processor, entropy source, operating system and permissions the platform will actually use.
Local operation · Explicit custody
The cloud call can go. The custody plan stays.
A software deployment still has secrets, authorized processes and recovery responsibilities.
Protect the root
Define provisioning, unlocking, endpoint-key custody and independent recovery material.
Control use
Specify which process may derive storage keys or see plaintext, including while disconnected.
Test recovery
Check the intended reader outcomes after restart or restore under the declared authority policy.
Keep custody visible
In the governed storage path, deriving data keys when needed can remove a persistent per-record key table. It does not remove the secret from which those keys are derived or the plaintext an authorized process can use.
Choose custody around the device and the job. Hardware-backed custody can strengthen protection where available; a software-only deployment needs a custody design suited to its platform. The evaluation should cover both a captured, powered-off device and a compromised running endpoint.
This makes the integration question more useful than “does it need an HSM?” Ask who provisions the root, what unlocks it, where recovery material is kept, and which component may use plaintext. Choose the custody mechanism that fits the mission and its assurance requirements.
Define what offline authority means
An isolated device cannot learn a revocation issued elsewhere after it disconnected. Its permitted behavior must follow an explicit offline policy: which operations remain available, how long authority lasts, what time uncertainty means, and what happens on reconnection.
Those are acceptance conditions for the deployment. A restore that consults current authority in a connected test does not establish immediate remote revocation on an unreachable device. For a local-first system, this distinction belongs in the operator's plan from the start.
Use separate tests for capture, read, export and administration. A mission may permit protected capture while requiring renewed authority before an export. That policy can preserve useful work during an outage while keeping the release decision accountable.
Evaluate the complete path
8DB is an omnimodal database, so the longer-term opportunity is to keep protected storage, relationships, retrieval and recovery close to the same information. Each application still needs to qualify the combination it will use.
Bring your real schema and target devices into the evaluation. Start with one protected data journey, then qualify the custody and recovery behavior your application needs.
The public evidence guide provides cryptographic artifact checks and recorded recovery examples. It distinguishes reviewing those files from running a fresh engine experiment. The dated qualification status preserves the remaining release and sustained-operation work.
Start with one disconnected mission
Choose a platform, a record type and an outage scenario. Define root custody, permitted offline actions and the recovery outcome before measuring performance. Include restart, stale authority and loss of the original device in the test plan where the mission requires them.
Bring us the platform that cannot depend on a live key service. Share a non-sensitive description of its hardware, connectivity and recovery needs. We can scope an evaluation that tests whether local protection reduces an operational dependency while meeting your security boundary.
Evidence scope Source-reviewed software composition · Recorded component evidence · Deployment evaluation guide. 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.