Security you can actually verify.

This is the question technical readers are actually asking, so here is the direct answer.

Harbor can technically read everything. We hold the master encryption key and we operate the database. A Harbor administrator with production access could read plaintext fields directly and could decrypt encrypted fields using that key. Harbor is not zero-knowledge and not end-to-end encrypted, and we will not claim otherwise to make this page read better.

What limits that in practice. The key lives outside the database, in a managed secret store, so a database-only compromise yields ciphertext for the sensitive columns rather than credentials. Ordinary application code runs under your session with row-level security applied — even our own app cannot read across households on a normal request path. Every decryption performed through the application writes an audit row naming the user who asked for it. Interactive production database access is limited to a single person; standing backup credentials (Backblaze B2 application keys and the backup encryption key) are stored separately in the secret store and can decrypt off-platform backups.

When we would look. Only to resolve a specific support issue you have raised, to comply with a valid legal order, or to investigate a security incident. We do not browse vaults, and no automated process reads vault contents for analytics, marketing, or model training.

A successor is a person you name who can reach your vault when you can't. The mechanism is a request-and-wait hold, and it works like this:

1. You invite them by email, choosing the scope of what they'll see — everything, or a subset such as estate documents, critical accounts, wallets, or logins — and the length of the hold.
2. They accept and enroll in two-factor. Acceptance is a required four-step sequence: context, TOTP enrollment, downloading recovery codes, and confirmation. There is no skip path, and the server enforces it — the underlying database policies require a completed two-factor challenge, so access cannot be obtained by going around the interface.
3. They request access. Nothing opens immediately. A timer starts — 72 hours by default, selectable as 24 hours, 72 hours, or 7 days — and you and your named emergency contacts are emailed at the moment of request, again at the midpoint, and again if it completes.
4. You can cancel instantly. One click, any time before the timer completes, ends the request and logs it.
5. If the timer runs out, access is granted by a scheduled job running every 15 minutes inside the database. It is read-only, scoped to the single household on that link, and revocable by you at any time.

Mandatory two-factor for every account — owners and successors — is a design decision, not a caveat. The person who will need this vault will need it on the day they have to step in for someone else. Being locked out at that moment is the single worst outcome Harbor can produce — worse than the friction of setting up an authenticator app on a calm afternoon. So we require it at signup, while there is still someone around to help owners and successors do it, and we make successors download recovery codes before they can finish.

What a successor sees once granted: a read-only walkthrough of the one household on their link — your letter and key contacts, estate documents, critical and important accounts, wallets, and logins, filtered to the scope you chose. They cannot edit, delete, or add anything. They cannot see any other household, and they never gain write access to yours. Every view is logged and visible to you.

Harbor does not independently verify death or incapacity. We do not check death registries, require a death certificate, or make any judgment about your condition. The waiting period is the control. It exists so that a request made in bad faith gives you time to see it and stop it.