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.
Why trust us over a big bank

The architectural difference.

Big banks get breached in the news every year. So why trust a smaller company like NestVault? The honest answer is not marketing language. It is in how the system is built.

“Why should I trust NestVault when big banks get hacked?”

Big banks get hacked because their business requires them to read your data, which means the key to decrypt it has to live somewhere reachable. NestVault's business doesn't require that. The key to your vault lives only in your head and your own browser. Our database holds locked boxes that even our employees cannot open.

When we eventually do get hacked (everyone does, eventually), the attackers will get a warehouse of ciphertext they cannot decrypt.

That's the architectural difference, and it's baked into how the product works, not just a claim.

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 600,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
The recovery code

Two keys to the same lock.

Your vault password is the everyday key. Your recovery code is a one-time backup that does the same job if you ever forget the password. Both are derived in your browser, and neither one ever reaches our servers.

01 · ONE DATA KEY
A random 256-bit key encrypts your vault
When you set up your vault, your browser generates a Data Encryption Key (DEK) at random. Every section and every file in your vault is encrypted with that one DEK using AES-256-GCM.
Generated in your browser
02 · TWO WRAPS
The DEK is locked twice — and only the locked copies are stored
The DEK is wrapped (re-encrypted) with a key derived from your vault password, and separately wrapped with a key derived from your recovery code. We store the two wrapped copies on our servers. We never see the DEK itself.
Wrapped blobs only
03 · EITHER UNLOCKS IT
Password today, recovery code if you forget
Your vault password unwraps the DEK and decrypts your data. If you ever forget it, your recovery code unwraps the same DEK and lets you set a new password. Changing your password only re-wraps the DEK — your encrypted vault contents are never touched.
Unwrapped in browser 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 reset your account password)
  • 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

During an active session, your vault password and decryption key are held in your browser's sessionStorage — cleared automatically when you close the tab. This memory is not encrypted at rest in the browser, but it is never transmitted to our servers and exists only for the duration of your session. We consider this a reasonable tradeoff between security and usability.

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, 600,000 iterations
A fresh 128-bit random salt is generated per section. Iteration count was raised from 310,000 to 600,000 in the pre-launch period, aligning with the OWASP 2023 PBKDF2-HMAC-SHA256 recommendation.
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 & recovery code storage
sessionStorage only — cleared on tab close
During an active session, your vault password and the unwrapped DEK are held in sessionStorage as base64. Both are cleared automatically when you close the tab. This is light obfuscation, not encryption — the values are readable in DevTools if you have physical access to the unlocked device. Neither value is ever transmitted to our servers.
The honest edge cases

What happens if…

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

…you forget your vault password?
Use your recovery code. At vault setup we issue you a one-time recovery code — a long string of letters and numbers you save somewhere physically safe. If you ever forget your vault password, that code unlocks the same encryption key and lets you set a new password. NestVault still cannot reset or recover anything on your behalf — not for support requests, not for legal process, not for anything. If you lose both your vault password and your recovery code, your encrypted data is permanently inaccessible. See the section above for how the two-key system works.
…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?
We are committed to giving members at least 90 days' notice in any wind-down scenario. We do not yet have a one-click vault export — until we do, the safest practice is to keep offline copies of any critical information you've stored here.
…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?
NestVault has a manual estate access process. A designated beneficiary can submit a claim at mynestvault.com/claim.html with a death certificate and government-issued ID. NestVault reviews the documents and, if approved, sends a setup link. The beneficiary must provide the vault owner's vault password — which should be in the estate documents or a sealed letter with the attorney — to complete the transfer. NestVault cannot decrypt the vault without the owner's password. We verify identity and authorize the transfer, but decryption is always done in the beneficiary's browser using the owner's password. This means the estate plan must include instructions for where to find the vault password. We recommend noting it in a sealed letter with your attorney or estate executor.
…a family member has in-app vault access?
Per-entry sharing controls let vault owners restrict individual entries to specific family members. This is a user-interface restriction within your household trust boundary — it hides entries from the rendered view for members not in the share list. It is not a cryptographic separation: a family member with category-level access holds the same decryption key as the owner. NestVault's security model assumes household-level trust between invited members.
…you hold a security clearance?
NestVault is a consumer product, not an approved system for classified material. Do not store anything classified, controlled unclassified, or operational here. What it IS appropriate for: your personal life admin (TSP, SGLI, VA benefits, BAH paperwork, military POA, beneficiary designations, family records) so your spouse can find everything during a 9-to-12-month deployment. The encryption is strong; the policy posture is consumer. Use it accordingly.
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.
Committed: by end of Q4 2026 or 1,000 paying members, whichever comes first
Third-party penetration test
An independent security firm will run a full black-box pen-test by the earlier of two triggers: 1,000 paying members, or the end of Q4 2026. The redacted report will be published on this page. If we miss the deadline, we will say so here in plain English rather than quietly drop the commitment.
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
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]