Security & Architecture

How we protect your data.
In plain English.

Your vault contents are encrypted on your own device before they ever reach our servers. The key that unlocks them never leaves your browser. No marketing copy here, just how it actually works.

The one-line promise

Only you can read your vault.

Not our employees. Not our infrastructure provider. Not a government subpoena. Not a future buyer of NestVault. Here is why that is true, and where the honest limits are.

Zero-knowledge, literally
Every piece of data in your vault is encrypted in your browser with your vault password. We receive, store, and sync only ciphertext, random bytes we have no mathematical way to decode.
The three steps that happen when you save

From your keyboard to our database.

01 · YOUR BROWSER
Derive a key from your vault password
Your vault password is run through PBKDF2 with 310,000 iterations and a random 16-byte salt to produce a 256-bit AES key.
Never leaves your device
02 · YOUR BROWSER
Encrypt the data
Your vault section is encrypted with AES-256-GCM using a fresh random 12-byte initialization vector. The plaintext is discarded.
Never leaves your device
03 · OUR SERVER
Store only the ciphertext
The encrypted bytes, salt, and IV are stored in Supabase with row-level security tied to your user ID. We never see, log, or cache the plaintext.
Encrypted blob only
Transparency, not salesmanship

What we can see. What we can't.

We think you deserve to know exactly what metadata we hold. This is the full list.

What we CAN see
  • Your email address (needed to let you sign in and for account recovery)
  • Your display name (the name shown in your dashboard header)
  • The number of sections you have completed (drives your readiness score)
  • When you last updated each section (timestamp only, not contents)
  • Your subscription status and Stripe customer ID (for billing)
  • Account events, signup, login, subscription changes (for audit trail)
What we CANNOT see
  • Your vault password, it never touches our servers, in any form
  • Any account numbers, balances, policy numbers, or institution names
  • The contents of any document you upload (files are encrypted before upload)
  • Your crypto platforms, wallets, or seed phrase locations
  • Your beneficiaries' names, relationships, or contact information
  • Your personal message to your family, or any final wishes
The technical details

For the engineers in the room.

Everything you'd need to audit the approach yourself. All of it is standard, no home-rolled cryptography.

Encryption algorithm
AES-256-GCM
Authenticated encryption via the Web Crypto API. Tamper-evident by design, any bit-flip in storage fails decryption.
Key derivation
PBKDF2-HMAC-SHA256, 310,000 iterations
Matches OWASP 2023 recommendations. A fresh 128-bit random salt is generated per section.
Initialization vector
96-bit random IV, per save
Generated by the browser's cryptographically secure RNG on every encryption, never reused.
Storage layer
Supabase Postgres with Row-Level Security
Policies enforce auth.uid() = user_id on every read and write. You cannot query another user's rows even if you bypass the UI.
Transport
TLS 1.3 end-to-end
Already ciphertext before it leaves your browser, the TLS layer is defense in depth, not the primary protection.
Vault password storage
sessionStorage only, lightly obfuscated
Kept in memory only for the duration of your browser tab. Cleared on sign-out. Never transmitted.
The honest edge cases

What happens if…

The questions we get asked most. Straight answers, including the uncomfortable ones.

…you forget your vault password?
Your vault data is permanently unrecoverable. This is the direct trade-off of zero-knowledge encryption, if we could recover it, so could anyone who compromised us. We offer a one-time recovery code at signup for this exact reason. Print it, store it in a fireproof safe, and you have a second key.
…our database is breached?
The attacker gets a table of ciphertext with random salts and IVs. Without your vault password, that ciphertext is mathematically indistinguishable from random data. Every row uses a different key derivation, so there is no single key that unlocks everything. The breach leaks nothing readable.
…a government serves us a subpoena?
We will comply with valid legal process, as any US company must. What we can hand over is: your email, your subscription status, login timestamps, and the encrypted blobs. We cannot hand over anything readable, we do not possess the key that decrypts them, and we have no mechanism to obtain one.
…NestVault shuts down one day?
You will always be able to export your entire vault as an encrypted archive. A shutdown notice would give you 90 days to download. If you still have your vault password, you can decrypt that archive offline forever, the open-source reference decryption tool is committed to a public GitHub repository, not held inside NestVault.
…a rogue NestVault employee tries to read your vault?
They see ciphertext. Full stop. Even our database administrators with root access to Postgres see only the same random bytes an external attacker would see. There is no backdoor, no master key, no "break glass" mode. We wrote it this way on purpose.
…your beneficiary requests access after you're gone?
They submit a death certificate and ID through our release portal. Our team verifies the documentation within 48 hours. Once verified, a one-time read-only link is sent to the beneficiary's email, derived using a secondary recovery path you set up during onboarding, not your primary vault password. Detailed procedure is published at our vault release page.
Independent review

What we have. What we're building.

We'd rather tell you honestly where we are than claim certifications we haven't earned yet.

In production
Open architecture
The encryption code runs in your browser. You can read it right now, view the source, inspect the network tab, confirm nothing leaves your device unencrypted.
In production
Row-level security
Every table enforces auth.uid() = user_id at the database layer. A bug in our application code cannot expose your data to another user.
Planned 2026
Third-party penetration test
Engaging an independent security firm for a full black-box pen-test once we cross 1,000 paying members. Report will be published.
Planned 2027
SOC 2 Type II
Standard for companies holding sensitive customer data. Preparation begins once recurring revenue supports the audit cost. No empty badge before then.
In development
Open-source decryption tool
A standalone CLI that takes your exported vault archive and your password, and decrypts it offline. So you never have to trust a single company to keep your data readable.
In development
Public whitepaper
A plain-English two-page document covering the same architecture above, plus threat model and known trade-offs, downloadable as PDF for your records.

Questions about our security?

We'd rather answer an awkward question honestly than have you sign up on trust alone. Email the founder directly.

[email protected]