Your customer's new encryption requirement arrives after years of records are already in your product. New writes can use the new protection. The harder question is what happens to the archive, the backup and the person who lost access since that backup was taken.
For a software vendor, that is a product capability worth owning: a repeatable answer to what changed, what still needs attention and who may read restored data. The implementation can be built from existing services or supplied partly by an embedded engine.
8DB is our omnimodal database. Its protected-data lifecycle connects a declared protection transition with registered retained copies and recovery authority. We want vendors to be able to build that evidence into their own products, while keeping their interface and customer relationship. The useful starting point is a defined integration boundary and an evaluation your team can inspect.
Start with the records already written
Cryptographic agility reaches beyond selecting an algorithm for the next connection. NIST's crypto-agility guidance addresses replacing or adapting cryptographic mechanisms while preserving security and operations.
For a records product, several changes may need separate treatment:
| Change | The question your product must answer |
|---|---|
| Rotate a key | Which data and envelopes still depend on earlier material? |
| Change a protection profile | Which stored records have moved to the required profile? |
| Change integrity protection | How will historical signatures and evidence be verified? |
| Restore an older backup | Which current access rules apply to the recovered records? |
These operations have different completion conditions. Calling all of them “rekeying” can hide work that matters to the customer.
Consider a case-management product. An operator changes protection on the live dataset, but an old export remains in the retained-copy register. A completion report that names that export gives the operator something useful to fix. On restore, testing both an authorized reader and a revoked reader checks whether recovery respects the intended current authority.
Choose what your team should build
There are credible existing components. Oracle documents online tablespace encryption and rekeying, including a way to finish an interrupted online conversion. HashiCorp Vault's Transit engine provides key rotation and ciphertext rewrapping; the application still stores the ciphertext.
The integration work lies between those components and your actual records, retained copies, recovery paths and customer-facing evidence. That is the work an integrated engine can bring into one evaluation.
An embedded engine gives your team a way to evaluate several responsibilities together. Compare the complete delivery path: integrating the data, changing its protection, restoring an older copy and showing the customer what happened.
What the 8DB evidence establishes
Our recorded native lifecycle qualification exercises a specific transition: HKDF-SHA256 to HKDF-SHA384 for key derivation, with AES-256-GCM-SIV unchanged. In that scenario, a registered old archive blocks completion. Historical recovery checks the current required protection profile and authority, including access for the current owner and refusal for a revoked reader.
The migration evidence guide follows the demonstrated transition through retained-copy accounting and authorized recovery. Use it as the starting point for your own migration acceptance test.
That distinction helps an integration team choose the next experiment. Start with the demonstrated lifecycle, then name the extra behavior your product needs instead of assuming that an algorithm registry completes the whole migration.
Build versus embed · Responsibility map
Put the work on the right side of the boundary.
Use the engine's supported mechanisms. Qualify them inside your product's actual rules.
Mechanisms and evidence
- Declared protection transition
- Registered retained-copy accounting
- Recovery checks against required authority
- Artifacts for the scoped result
Rules and integration
- Users, permissions and retention policy
- Backups and exports in scope
- Root-secret custody and deployment
- Customer promises and operations
One record type → one protection change → one retained backup → authorized and revoked-reader checks.
Embedding changes the work boundary
Your product team still decides who may access information, what must be retained, where secrets are held and what a customer is promised. The engine can supply supported mechanisms and evidence for a defined storage path. The combined deployment must show that those mechanisms enforce the product's actual rules.
For example, a register of retained artifacts is only as useful as its declared scope. Your application must identify the exports and backups it controls. A storage engine cannot account for an undeclared plaintext copy made elsewhere.
Root-secret custody also remains a design decision. Derived record keys do not remove the secret material from which they are derived or the need to protect it. Our key-protection guide explains why the data cipher and its key-recovery path deserve separate review.
The same precision applies to validation. NIST's CMVP guidance tells buyers to check the relevant module certificate and the vendor's statement of how it is used. An embedded component does not, by itself, establish compliance of the surrounding product. Define the module, configuration, operating environment and assessment requirements before promising an inherited status.
Evaluate one customer workflow before committing
A useful first evaluation can fit around one representative record type, its backup and one authority change. Agree on:
- The old and new protection profiles, and exactly which change is being tested.
- The records, registered exports and backups included in completion accounting.
- The authorized and revoked-reader outcomes after recovery.
- The required interruption, rollback and availability behavior.
- The logs and artifacts another reviewer will use to check the result.
Then run that workflow on the intended deployment. Compare the build-from-components route with the embedded route using the same acceptance conditions. Measure integration effort, operational complexity and runtime cost separately; passing the lifecycle tests answers a different question from winning a speed comparison.
Also record the smallest team and deployment that can operate the accepted workflow, including adoption, updates and recovery; lower entry cost can matter as much as a faster operation.
The commercial opportunity is a product that can answer a customer's migration question with inspectable evidence. 8DB gives us concrete lifecycle mechanisms to evaluate with you, and an architecture designed to keep that evidence close to the data.
Bring us one stored-data migration requirement. Include a representative record type, retention horizon, backup path and the protection change your buyer needs. We can turn that into a scoped evaluation with a clear division of responsibilities.
Evidence scope Recorded KDF and restore qualification · Source-reviewed implementation · Integration guide. Explore the evidence. Methods and retained scope notes.