# Credential Compartmentalization

The default password-manager assumption is one vault for everything: one master password, one sync surface, one breach radius. Credential compartmentalization rejects that and splits credentials across several tools chosen for their individual fit. Two arguments converge: no single tool actually fits every requirement (sharing, CLI access, offline use, mobile reliability, audit logs), and a single vault makes the blast radius of any breach the whole identity.

The pattern was articulated in [[marius-bitwarden-not-recommended]] as "divide and conquer" after the author abandoned a single self-hosted [[bitwarden]] / [[vaultwarden]] setup.

## The grouping rule

The split is along *what gets exposed if this group leaks*, not along *which tool feels nicest*:

- **Client / professional work.** Sharing matters. SSO, audit logs, browser extensions on managed corporate machines matter. Pick a SaaS password manager built for that, accept proprietary, scope it tightly.
- **PII-bearing accounts** (banks, shops, insurers). Counter-intuitively, the leak risk floor is already high — the underlying services leak this data themselves. Cross-device availability and offline reliability win out. A second cloud manager from a different vendor, different master password, different recovery — so a compromise of the work group does not cascade.
- **Non-PII accounts** (forums, services, throwaway logins). Cloud is unnecessary. A local KeePass database synced via Syncthing is enough. The `.kdbx` is encrypted at rest, so the sync layer is not a trust boundary on its own.
- **Infrastructure** (servers, SSH, CI). Two sub-groups: personal credentials stored like the non-PII group, and automation credentials in a secrets manager (HashiCorp Vault, Infisical) where short-lived tokens, policies, and audit logs are first-class.
- **One-off CLI secrets** (API keys, PATs, tokens). `pass` (GPG-encrypted file per secret in a Git repo) — Unix-shaped, scriptable, no daemon, no sync surface beyond a Git remote you control.

## Why the blast radius matters

Each tool's breach is now bounded to its category. A leak of the work-credentials SaaS does not expose your bank logins. A theft of the KeePass `.kdbx` file does not include your CI secrets. A compromised laptop with `pass` unlocked does not also expose your client work.

Compare to a single-vault breach: every credential, every TOTP seed, every recovery code in one decryption. The KDF parameters and the master password are the entire defense.

The trade-off is operational: more tools means more master passwords, more recovery flows, more places to back up. The countervailing observation is that each tool ends up well-fit to its job, so day-to-day friction goes *down* per group, not up. The cost is concentrated at setup and at recovery time.

## Adjacent ideas

- [[ephemeral-credentials]] — within the infrastructure group, prefer credentials that expire on their own over rotation. The structural answer to long-lived keys.
- [[supply-chain-security]] — a compartmentalized setup limits damage from a compromised CLI tool (e.g. the [[bitwarden|Bitwarden CLI]] Shai-Hulud incident) to the credentials that tool actually touched.
- [[living-off-the-land]] — attackers using legitimate tools is a class of breach where compartmentalization shifts what they can reach.