A password manager is valuable because it replaces dozens of remembered passwords with one protected system. That concentration also creates an architectural question: should ordinary shopping logins, employer credentials, banking records, and infrastructure administrator accounts all sit behind the same unlock boundary? The answer depends on what failure you are trying to contain and whether you can operate several recovery plans correctly.
Quick answer
One encrypted vault is appropriate for many people. Use separate vaults when groups of credentials have meaningfully different owners, policies, privileges, travel exposure, or recovery consequences. Cryptographically separate vaults can reduce what is available when only one vault is unlocked or one recovery key is exposed. They do not rescue an already compromised device, enforce an employer's policy, or replace multifactor authentication. Krypt provides two built-in real vaults and, with Krypt Pro, custom local vaults for deliberate compartmentalization.
A separate vault is a security boundary, not a filing label
Folders and tags help you find records, but every record can still be decrypted after the same vault opens. A separate encrypted vault creates another decision point: another PIN-derived key, another wrapped vault key, another database, and another recovery secret. The second vault remains locked while you work in the first. That is a meaningful difference, provided the application and device preserve the boundary.
This resembles the principle of least privilege, but it is not a direct substitute for enterprise access control. The NIST definition of least privilege limits a user or process to the resources needed for its task. Applied as a personal design analogy, an everyday vault should not automatically expose credentials that are unnecessary for everyday activity.
Think in terms of failure domains. A failure domain is the set of secrets that one event could expose or make unavailable. Moving records into a new folder does not change the cryptographic failure domain. Moving them into an independently keyed vault can change it, but only for events that stop at that boundary.
| Event | Potential benefit | Important limit |
|---|---|---|
| One vault left unlocked | Locked vaults are not part of that unlocked session | Device-level malware may capture later unlocks |
| One Rescue Key disclosed | A custom vault's key does not recover other custom vaults | The built-in Recovery Kit contains both built-in Rescue Keys |
| Wrong vault used | The active-vault label can prompt a deliberate choice | The user can still save a record in the wrong place |
| Device loss or deletion | No direct availability benefit | Each vault needs a usable backup and recovery path |
When one password vault is enough
Separation has a cost. Every additional vault creates another PIN to distinguish, another active-vault state to verify, another backup to test, and another Rescue Key to protect. Complexity can reduce security when it causes forgotten recovery material, stale backups, or records saved in the wrong compartment.
A single vault is often the better choice when one person owns all the accounts, the accounts have similar consequences, the device is used in the same environment, and one clear recovery plan is more reliable than several. Unique generated passwords still prevent a breach of one website from becoming credential stuffing against another. NIST's password-manager guidance highlights that ability to generate and securely store different passwords, while warning that the vault itself contains information valuable to attackers.
Do not build eight vaults simply because the limit exists. A compartment without a named threat, owner, or recovery rule is administrative weight. Start with the smallest number that expresses a real boundary. If you cannot state what belongs in a vault and why it must stay apart, a folder may be the more usable tool.
When separation earns its complexity
Work and personal credentials have different owners
Employment changes the decision because the worker may use a credential without owning its policy. Before placing any work login in a personal manager, check the organization's rules. The NCSC's password-manager buyers guide says home and work passwords need good separation and stresses making the correct vault obvious. It also covers enterprise capabilities such as administration, audit, sharing, and offboarding that a personal local vault does not provide.
If personal storage is permitted, a work-only vault can prevent a routine personal browsing session from opening work credentials at the same time. It does not make a personal device organization-approved, transfer custody to an employer, or provide administrator access when the employee leaves. If policy requires a managed enterprise manager, use that system.
Privileged accounts should not ride with daily browsing
Administrator, registrar, cloud-console, source-control owner, and primary email credentials can unlock many downstream systems. The NCSC's lateral-movement guidance recommends separate normal and privileged administrator accounts and, where possible, separate devices. A high-risk vault can support the same operational discipline: open it only for privileged work, then lock it.
The vault does not remove privilege from those accounts. It also does not isolate processes as strongly as a separate device or operating-system account. Treat vault separation as one layer alongside phishing-resistant MFA, restricted admin use, provider activity review, and a hardened endpoint.
Travel and exposure profiles can differ
A person may need shopping, transport, and ordinary communication credentials while traveling but not tax records, infrastructure access, or recovery codes. A travel-oriented real vault can reduce how often higher-impact records are unlocked. That is exposure minimization, not a promise against device seizure, coercion, forensic tooling, or malicious software.
Recovery ownership can justify a boundary
Some records must be recoverable by you alone; others may be subject to an organization's documented continuity process. Mixing them can make the recovery plan ambiguous. Separate vaults let you map each encrypted backup to its own recovery material, custodian, storage location, and test schedule. They do not create safe sharing by themselves.
Krypt's answer: independently encrypted real vaults
Krypt is a zero-knowledge password manager designed around local vault boundaries. A fresh setup creates built-in Vault A and Vault B as separate real vaults, plus a decoy vault for a different threat model. Krypt Pro can create additional custom real vaults, up to eight real vaults total on a device. Because Vault A and Vault B count toward that limit, the maximum custom-vault addition is six.
The separation is cryptographic and physical within Krypt's local storage layout. Each real vault has a vault-specific salt, PIN verifier, wrapped data-encryption key, and recovery-key wrapping material. Each opens its own SQLCipher database path and uses its own encrypted-file directory. Unlocking one real vault establishes the current session for that vault; it does not merge the other vault's records into the open database.
For custom vault creation, Krypt Pro requires a unique name and a distinct six-digit PIN. It generates a random vault identifier, salt, vault key, and Rescue Key. The vault key is wrapped separately for normal PIN unlock and Rescue Key recovery. Krypt requires the Rescue Key to be saved and acknowledged before it commits the new vault to the registry. This design keeps a custom vault's recovery material outside the built-in Recovery Kit.
These facts do not turn a six-digit PIN into a high-entropy secret. Krypt uses the PIN to derive a key that unwraps a random vault key and applies failed-attempt protections, while the independently generated Rescue Key supports recovery. Choose distinct PINs that are not obvious, protect the device, use the available auto-lock controls, and store Rescue Keys somewhere that a phone loss cannot take with it.
Built-in Vault A and Vault B are a special pair
The built-in vaults share one Recovery Kit document, but the document contains a different Rescue Key for each vault. Setup therefore gives the user one physical artifact to protect for both built-in recovery paths. Rotating that Recovery Kit verifies both built-in vault PINs, generates new Rescue Keys, and re-wraps the existing vault keys. It does not rotate the Rescue Keys of user-created vaults.
Old encrypted backups do not magically adopt new recovery material. A backup made before a built-in Recovery Kit rotation still needs the older matching kit; a later backup needs the newer one. Custom vaults require their own matching Rescue Keys. Inventorying those relationships is part of operating multiple vaults safely.
Krypt also has a Link Built-in Vaults setting for quick switching between Vault A and Vault B. “Linked” describes a user-interface path between that built-in pair; it does not collapse their databases, salts, wrapped keys, or PINs. The target vault still requires its configured unlock path. Custom vaults are listed in the vault switcher but are not part of that built-in link setting.
The decoy vault is not a work/personal organizer
Krypt's decoy vault exists to present separate, safe-looking content under a different PIN in pressure scenarios. Its purpose is plausible deniability, not routine project categorization. Treating it as “Work” or “Banking” confuses its threat model and may produce an unsafe recovery assumption: the decoy is not one of Krypt's real vaults and does not use a real-vault Rescue Key.
If two collections are both genuine and both need backup recovery, use real vaults. Give them descriptive, non-sensitive names that make the active context clear. A vault label is interface metadata, so do not put confidential details into the label itself.
What multiple vaults do not solve
A hostile endpoint remains the central limitation. Malware with enough control can read an unlocked vault, observe the screen or clipboard, capture a PIN, interfere with an export, or wait until another vault is opened. Australia's cyber security agency similarly advises using password-manager vaults only on trusted devices and considering a separate vault for high-value accounts. Vault boundaries improve selective exposure; they do not certify the operating environment.
Separation also does not prevent loss. Locally maintained password databases require deliberate backups, a tradeoff emphasized in CISA's password-manager training. If all encrypted backups and all Rescue Keys are stored on the same phone, theft or hardware failure can defeat every compartment at once. Keep recovery material separate from the protected device and test representative restores.
Finally, Krypt does not ship shared or team vaults. There is no role-based sharing, organization administrator, centrally enforced policy, employee offboarding, or team audit log. Never simulate a team vault by distributing one PIN and Rescue Key among several people; that removes individual accountability and creates uncontrolled copies. Use an employer-approved enterprise system when credentials need shared custody.
A practical three-vault design
For a person who manages ordinary life, employer-approved work accounts, and a few infrastructure-owner credentials, a three-vault model may be enough:
- Personal: shopping, subscriptions, social accounts, household services, and low-impact recovery notes.
- Work: only credentials the employer permits in Krypt, with a backup and deletion plan consistent with policy.
- High-risk: primary email, domain registrar, financial administration, cloud owner, and recovery credentials opened only when required.
The categories are examples, not universal rules. Your bank may prohibit storing credentials, your employer may require its own manager, and your primary email may belong with a separate recovery workflow. Classify by consequence and ownership rather than by how often you use the account.
Use a decision test before creating another vault
For each proposed compartment, answer five questions:
- Threat: What event should stop at this boundary?
- Contents: Which records belong here, and which explicitly do not?
- Unlock: When and on which trusted devices should this vault open?
- Recovery: Where are its matching backup and Rescue Key, and who is authorized to use them?
- Lifecycle: What happens when employment, travel, privilege, or account ownership changes?
Create the vault only when the answers are concrete. Then migrate records deliberately, verify the active vault label before each save, create a current encrypted backup, and test that the recovery inventory identifies the correct Rescue Key without exposing it. Review the design after a role change or major incident. A small, maintained set of compartments is stronger than an elaborate map nobody can recover.
FAQ
Does everyone need separate password vaults?
No. One well-protected vault is usually reasonable when the same person owns every account, the accounts have similar consequences, and a simpler recovery plan is safer to operate. Separate vaults become more useful when credentials differ in policy, privilege, exposure, or recovery ownership.
How many real vaults does Krypt support?
Krypt supports up to eight real vaults on a device. The total includes built-in Vault A and Vault B, so a Pro user can add up to six custom vaults. Each custom vault has its own PIN, cryptographic material, local database, file path, and Rescue Key.
Does a separate vault protect secrets from a compromised device?
Not reliably. Separation can keep a locked vault's key and records outside the current unlocked session, but malware with sufficient device control may capture input, read an unlocked vault, or wait for other vaults to open. Use trusted, updated devices and protect high-risk accounts with provider-side MFA.
Can a team share and administer a Krypt vault?
No. Krypt's real vaults are local compartments for one user's data. Shared or team vaults, role-based access, administrator recovery, audit logs, and employee offboarding controls are not shipped. Follow the organization's approved credential-management policy for work and shared accounts.
Technical references
The primary guidance linked above provides complementary boundaries: NIST explains password-manager concentration and least privilege; the NCSC addresses work/personal vault separation and privileged-account separation; Australia's cyber security agency recommends trusted devices and consideration of a separate high-value vault; and CISA covers local-database backup and recovery planning. None says every user needs several vaults. The decision remains a balance between containment and reliable operation.
Use Krypt's independently encrypted real vaults to separate credentials whose ownership, privilege, exposure, or recovery requirements genuinely differ.
