Security
What is encrypted, what is released, and when
Digital Legacy Vault is designed for layered defense, not vague trust claims. This page explains the current security model in plain terms.
Current model
The practical trust boundary today
The product uses client-side encryption for normal vault storage, then a separate protected release path for post-unlock viewing.
Client-side encrypted vault data
Normal vault items and attachments are encrypted before they leave the browser or app. The server stores ciphertext for day-to-day vault records.
Controlled release path
Released access uses a separate snapshot path after an approved unlock event. That lets trusted requesters view released content later without the owner’s master password.
Mandatory MFA for high-risk actions
Sensitive actions now require MFA enrollment and step-up verification. Actions like release-policy changes, trusted-contact changes, unlock confirmations, and released-content viewing should not succeed on a password-only session.
Important trust boundary
Digital Legacy Vault is not a full zero-knowledge release system today. The server can decrypt released snapshots after the release rules are satisfied, but it cannot decrypt the owner’s normal vault ciphertext during normal operation.
What the server can and cannot do
The server should not be able to decrypt normal vault ciphertext without the owner's master password. It can decrypt released snapshots only after the release workflow has actually unlocked access for the requester.
Operational safeguards
Controls around the cryptography
Encryption only helps when the surrounding operational controls are strict too.
High-risk actions require MFA enrollment and step-up verification. Sensitive routes are rate limited. Released-access writes fail closed if the release-key environment is incomplete or mismatched. Internal audit logs are designed to exclude decrypted vault content, filenames, and plaintext secrets.
Questions
Common security questions
Is Digital Legacy Vault zero-knowledge?
Not in the strict sense. Day-to-day vault content is client-side encrypted, but released snapshots are designed to be decrypted by the server after an authenticated unlocked request.
Can support or admins read decrypted vault contents?
Internal tools are intended to stay metadata-only. Support and admin workflows should expose counts, states, and audit history, not decrypted vault content or released attachments.
What should users do if they enable MFA?
Keep access to the authenticator app safe and use a backup authenticator device or second enrolled factor where possible. Recovery codes are not available yet in the current auth provider flow.