We're in beta — products are not yet available for purchase. Leave your email and we'll notify you when we go live.
Most password managers ask you to trust them. Vault is designed so you don't have to. Your secrets are locked before they ever leave your device — and only you hold the key.
Traditional password managers protect your data with strong encryption — but they hold the keys. That's a meaningful difference.
The service encrypts your data, but the encryption keys live on their servers or are derived in a way the server can participate in. Decryption can happen server-side.
Your data is encrypted on your device before it goes anywhere. The keys never leave your machine. The server only ever receives ciphertext it cannot read.
This isn't a policy statement. It's an architectural property. Here's what it means in practice.
When you unlock your vault, your master password is processed locally to derive the encryption key. Nothing is transmitted. We have no password reset mechanism because we genuinely cannot recover it.
The keys that protect your secrets are derived on-device and stay there. Even during sync, only the locked ciphertext travels over the wire. Our servers are a blind relay.
If you asked us to show you your own vault contents from the server side, we couldn't. The data is mathematically locked to a key only your device can produce.
Your data isn't protected by a single lock. It's protected by three — each one independent, each one requiring a separate key. Breaking one doesn't break the others.
The entire local database — every record, every field — is encrypted on disk. Without the correct master password, the file cannot be opened at all. An attacker who physically stole your hard drive would get an unreadable binary file.
A dedicated vault key encrypts your secrets. That vault key is itself encrypted and locked behind your master key. This indirection means changing your password only needs to re-lock the vault key — not every secret individually. Two keys must align to reach your data.
Every secret is individually encrypted with a unique random value. Even within the vault, secrets are not a single mass of data that unlocks all at once — each one is a self-contained sealed item. This contains any theoretical damage from a partial compromise.
Why three layers matter: Each layer uses a different key and a different mechanism. There is no single point of failure. An attacker who somehow compromised the database file still faces the vault key. An attacker who somehow obtained the vault key still faces per-secret encryption. Each layer buys time and contains the blast radius of any theoretical breach.
Every step of the journey, on your device and off.
Your password, note, or credential lives in your app as plaintext — only in memory, only on your device. At no point does it leave in this form.
Using your master password and a unique salt that never changes, your device produces a cryptographic key. This process is deliberately slow and expensive to make brute-force attacks economically pointless. The key exists only in memory, never written to disk.
Your secret is locked using the key from step 2 with industry-standard authenticated encryption. Authenticated means any tampering with the ciphertext is immediately detected on decryption. The result is an opaque blob that reveals nothing about its contents.
When syncing, the encrypted blob is transmitted. Our servers store it and relay it to your other devices. To us it is meaningless binary data. We cannot distinguish a password from a note from a random number.
On another device, you enter your master password. The same key is derived locally. The ciphertext is decrypted on-device and your secret appears. The server was never involved in reading it.
Sharing secrets with teammates sounds like it would require the server to broker access. It doesn't.
When you share a vault with someone, a dedicated encryption key is created for that shared space. Using public-key cryptography — the same foundation that secures financial transactions globally — that key is individually wrapped for each authorized member using their own public key. Only the intended recipient can unwrap it using their private key, which only exists on their device.
Our servers store the wrapped keys, but wrapping a key is meaningless without the corresponding private key to open it. No server-side operation can bridge that gap. Sharing is a client-to-client cryptographic handshake; the server just holds the sealed envelope.
Each member receives a version of the vault key cryptographically sealed to them personally. Adding or removing someone doesn't require re-encrypting every secret.
When someone loses access, the vault key is rotated. They retain no cryptographic path to future secrets — the math enforces it, not an access policy we could misconfigure.
Our servers cannot grant themselves access to a shared vault any more than they can grant access to a personal vault. There is no admin override.
Zero-knowledge isn't an abstract principle. It has concrete consequences — some reassuring, one important to understand.
If attackers stole everything stored on our infrastructure, they would have encrypted blobs and no means of decryption. Your secrets would remain private.
If served with a legal order to hand over user data, we can comply fully and produce only encrypted data that neither we nor any third party can read.
Adding a new device doesn't require sending keys over the network. The same master password, the same derivation process, the same vault key — reproduced locally on every device.
A password change re-derives the encryption key on your device. The vault is immediately sealed under the new key. No server-side key update is required.
Because we cannot access your vault, we also cannot recover it for you if you forget your master password. There is no "forgot my password" link that sends a reset email, because such a mechanism would require us to hold or retrieve a decryption key on your behalf — which is precisely what zero-knowledge prevents. Your master password is your key. Keep it somewhere safe.
Transparency means being explicit about this.
Zero-knowledge is a design constraint, not a feature we toggle on. It means every architectural decision — sync, sharing, mobile, browser autofill — is built around one principle: your keys stay with you. The technical audit trail is in our architecture documentation for anyone who wants to dig deeper.