Protecting vault data is fundamental to how Vault App is designed. Passwords, secure notes, credit cards, contacts, and other vault items are encrypted on the device before they are transmitted or stored. The platform uses AES-256-GCM authenticated encryption and a zero-knowledge architecture so that only the account holder can unlock vault contents.
Many password managers extend into the browser through plugins that autofill credentials across the web. Vault App takes a different approach. The vault runs as a dedicated application surface—not as a browser extension that injects itself into every site visited.
That choice is deliberate. Browser extensions sit in a privileged position: they can read page content, intercept form fields, and become a high-value target when a store listing, update channel, or dependency is compromised. Autofill also trains users to trust prompts that appear on login pages—an attack surface phishing kits routinely exploit.
By keeping vault access inside a controlled application context, credential use stays intentional. Secrets are unlocked when needed, copied or applied deliberately, and never continuously exposed to the browser's broader execution environment.
Vault App is structured so cryptographic control stays with the account holder. Encryption and decryption happen on trusted devices. Master passwords and derived keys are not held by the network in a recoverable form. The infrastructure stores and synchronizes ciphertext; it does not hold the means to read it.
In that sense the vault is decentralized at the point that matters: authority over secrets. Availability and sync may rely on networked storage, but confidentiality does not. Compromising the transport or datastore yields encrypted blobs without the keys required to interpret them.
Sensitive vault data is encrypted locally on the device before leaving it. Encryption keys are derived from the master password and are never transmitted in a form that would allow anyone else to decrypt vault data.
Because encryption occurs before synchronization, data stored in the network remains unreadable without those keys.
The system is designed so that vault contents, master passwords, and encryption keys remain solely under the account holder's control.
Encryption and decryption occur exclusively on trusted devices. At no point does the network possess the information required to decrypt vault data.
The master password is the foundation of vault security.
Because the master password never leaves the account holder's control in a recoverable form, nobody else can unlock the vault on their behalf. Recovery is something you set up yourself, before you need it.
You can generate a recovery code in Settings after confirming your master password. The code wraps that password on your device. The service stores only the resulting ciphertext — never the code, and never the password in a recoverable form.
Keep the code somewhere safe. Generating a new one replaces the previous wrap. Changing your master password unsets it. If you forget the master password later, enter the recovery code on the sign-in screen to set a new one and keep your vault.
A recovery code is not a backdoor for the service. It is a key you hold, used only on your device.
If you do not have a recovery code, you can reset your vault from the sign-in flow. Your account remains. Every vault item is permanently deleted. That is the only way to sign in again when the master password is lost and no recovery code exists.
Reset is irreversible. The service cannot restore deleted items, and there is no support channel that can recover sealed vault data.
Encryption keys are derived from the master password using PBKDF2 and a unique cryptographic salt generated for each account.
Key derivation increases the computational cost of password-guessing attacks and helps protect encrypted data even if an attacker obtains a copy of the encrypted vault.
All vault data stored in the network remains encrypted.
Each encrypted field uses a unique initialization vector (IV), ensuring that identical values produce different ciphertext. This prevents pattern analysis and improves cryptographic strength.
The infrastructure employs strict access controls, encrypted communications, and continuous monitoring to protect stored data and system integrity.
Vault App does not continuously push credentials into third-party pages. Access is deliberate: unlock the vault, retrieve what is needed, and keep the session within the application boundary.
That model reduces silent exfiltration risk from malicious scripts on the open web and avoids normalizing credential entry through overlays that can be mimicked. Security here prefers clarity of action over invisible convenience.
Shared vaults and delegated credential access are intentionally unsupported. Each account retains exclusive control over its secrets, reducing lateral risk from shared links, team vaults, or forwarded access that outlive their intended purpose.
Account authentication can be strengthened with multi-factor authentication and trusted-device controls. These layers protect account access itself—separate from the cryptographic barrier that protects vault contents.
Even with account credentials compromised, vault items remain ciphertext without the master password and derived keys held on trusted devices.
Omitting a browser extension reduces the platform's attack surface and clarifies trust boundaries:
Convenience that requires injecting secrets into the browser is treated as a security tradeoff—not a default. Vault App favors explicit unlock, deliberate retrieval, and a smaller trusted computing base over ambient autofill across the open web.
Because vault data remains encrypted end to end, no one else has the information required to read stored secrets.
Security is an ongoing process. Architecture, threat models, updates, and cryptographic implementations continue to evolve as standards and risks change.
Strong security controls are maintained while preserving the privacy and confidentiality of vault data.
Vault items are encrypted on your device with AES-256-GCM before they are stored or synced. Encryption keys are derived from your master password, which is never stored in a recoverable form. Only you can unlock passwords, secure notes, credit cards, and contacts.
It means Vault App never has the material required to decrypt your vault. Encryption happens locally; the service stores ciphertext. Vault contents cannot be viewed, accessed, or recovered by anyone else — including Vault App.
Generate a recovery code in Settings while you still know your master password, and keep it somewhere safe. If you forget the password later, enter that code on the sign-in screen to set a new one and keep your vault. The service never sees the code or the password in a recoverable form. If you do not have a recovery code, you can reset your vault: your account stays, and every vault item is permanently deleted. Nobody else can restore a forgotten master password or sealed vault data. Paid billing can still be canceled through Stripe receipt or invoice emails.
Passwords and usernames, website addresses, secure notes, credit cards — including cardholder name, number, expiration, and CVV — and contacts with names, emails, phone numbers, and addresses. Everything uses the same end-to-end encryption and zero-knowledge architecture.
Enterprise accounts can download an encrypted backup and restore it later. Only the master password used when the backup was created can decrypt it. The service never gets a readable copy of your passwords, notes, cards, or contacts.
You can require a 6-digit code from an authenticator app each time you sign in. MFA protects account access. It does not give the service a way to decrypt your vault. A stolen username is not enough, and Vault App still cannot read your items.