Skip to main content

Security

Your data, protected at every layer.

The encryption, authentication, and infrastructure choices behind MyVaultedLife, explained plainly.

Last updated: June 2026

MyVaultedLife is built around a simple principle: your information belongs to you, and you have entrusted us to help you keep it protected. This page explains the technical measures we take to fulfill our promise to you.

Encryption

At rest

Your vault is end-to-end encrypted. When you sign in, your password is stretched into an encryption key inside your browser (using Argon2id). That key encrypts every vault field with authenticated encryption (XChaCha20-Poly1305) before anything is sent to us. We receive only ciphertext, and we never receive your password or your keys. The practical result: we cannot read your vault, and neither can anyone who obtains a copy of our database, including our own staff and our hosting provider.

Sharing stays encrypted. When you grant a deputy or a family manager access to a section, your browser re-encrypts that section's key directly to their key (X25519 sealed box). They decrypt only the sections you grant, in their own browser. We pass the sealed key along but never hold one that can read the contents.

Tamper-evidence. Each field write is signed with your personal key (Ed25519), so a reader can confirm who wrote it and that it has not been altered in our database.

What we can and cannot see

Because your vault is end-to-end encrypted, we cannot read any field value, custom prompt, or response. We can see structural metadata (which sections exist, which fields are filled, your completeness score, and which deputies you have shared with), but never the contents behind them.

There are two deliberate exceptions, which we disclose plainly rather than bury:

  • Final messages. Your “One Last Thing” messages are delivered on your behalf (often to people who have no account and hold no key) after your check-in switch lapses. No end-to-end scheme can hand plaintext to someone who holds no key, so messages are encrypted at rest under a separate key that we hold, not end-to-end. Keep passwords and secrets in your vault; use messages for personal words.
  • Family-managed vaults. If your vault is set up and managed for you under a Family plan, it is readable by you and the family managers you designate: “you and your managers,” not “only you.” A vault you own yourself stays end-to-end encrypted to you alone until you choose to share it.

Unlocking with a passkey

Typing your passphrase is not the only way to unlock your vault. You can enroll a passkey—Touch ID, Face ID, Windows Hello, or a hardware security key—and unlock with a fingerprint or your face instead. Under the hood this uses WebAuthn's PRF extension: your device derives a secret that never leaves the authenticator and that we never receive, and that secret unwraps your vault key inside your browser. A passkey augments your passphrase rather than replacing it, so an unsupported or lost device never locks you out—your passphrase and recovery options keep working. As with everything else here, we only ever store a wrapped key we cannot open.

Recovery

Because only you hold your key, we cannot reset it the way an ordinary password reset works. There is no master key on our side to fall back on. At sign-up you receive a one-time Recovery Key to store somewhere safe, and you can set up social recovery with people you trust, who can together help you regain access. We explain the trade-offs of each option in the app.

Where the trust boundary sits

End-to-end encryption moves the trust boundary to your browser: keys exist there only while your vault is unlocked, and are cleared on sign-out and after a period of inactivity. We harden that surface with a strict Content-Security-Policy and careful dependency review, but a device compromised by malware or a malicious browser extension is outside what any in-browser encryption can defend. This is inherent to end-to-end encryption in a web app, and we would rather state it than imply otherwise.

In transit

TLS everywhere. All communication between your browser and our servers is encrypted with TLS. Modern browsers connect over TLS 1.3; TLS 1.2 is our floor, so anything older is refused. We do not serve any content over plain HTTP.

Authentication

Passwords. Passwords are hashed using bcrypt with a per-user salt before storage. We never store plaintext passwords and cannot recover them. If you forget your password, we email a reset link—but because your vault is end-to-end encrypted, completing the reset also requires your Recovery Key (see “Recovery” above). The emailed link alone is not enough to unlock your vault, by design.

One-time verification codes. Every sign-in triggers a one-time code sent to your email address. This acts as a second factor and ensures that access to your account requires both your password and access to your inbox. Codes expire after 10 minutes.

TOTP (Authenticator app). Users can enable time-based one-time passwords via an authenticator app (Google Authenticator, Authy, etc.) for an additional layer of sign-in security.

Passkeys. You can also enroll a passkey (Touch ID, Face ID, Windows Hello, or a hardware key) to unlock your vault with biometrics instead of typing your passphrase. This is a hardware-backed convenience that augments your passphrase; the cryptographic details are under “Unlocking with a passkey” above.

Session management. Sessions are signed JWTs with a rolling seven-day lifetime, so an idle session expires on its own. Signing out clears your session immediately, and we re-check your account standing (including suspension) on the server while you're signed in.

Access controls

Deputies. Access to your vault is strictly controlled. Deputies (trusted people you designate) can only view the specific domains you grant them access to. Deputies have read-only access and cannot modify your vault content. Access can be revoked at any time and takes effect immediately.

Principle of least privilege. Our internal systems and API routes are designed so that each part of the application only has access to the data it needs. Deputy access is validated on every request, not just at login.

Infrastructure

Hosting. MyVaultedLife is designed, maintained, and hosted in the United States: it runs on DigitalOcean's App Platform in their New York (NYC) region, so your data stays in U.S. data centers. All traffic is served over HTTPS/TLS, and the application sends HSTS, a Content-Security-Policy, and other browser-hardening headers on every response.

Database. Your data is stored in a DigitalOcean Managed PostgreSQL database in the same region. Connections are encrypted in transit and verified against a pinned certificate authority. Your vault fields are stored as end-to-end-encrypted ciphertext that we hold no key to open. Personal messages and your authenticator (TOTP) secret are encrypted at rest under a server-held key (messages because we deliver them on your behalf, and the TOTP secret because the server must verify your codes), so the database never contains plaintext for any of it.

Backups. The managed database is backed up automatically by DigitalOcean, with point-in-time recovery, so your data can be restored in the event of a failure.

Responsible disclosure

If you believe you have found a security vulnerability in MyVaultedLife, please report it to us privately at security [at] myvaultedlife.com. We ask that you give us reasonable time to investigate and address the issue before any public disclosure. We take all reports seriously.

Questions

If you have questions about security that are not addressed here, please contact us.

Ready to get organized?

Start with a free account and get started in just a few minutes.

Start your vault, freeRead our privacy policy