Cloud Password Manager vs Self-Hosted Password Vault: Who Carries Breach and Patching Risk

Choosing between a cloud password manager and a self-hosted password vault is really a choice about who you trust to hold an encrypted copy of every password your organisation uses, and who patches, backs up and recovers the thing when it breaks. Both models encrypt vault contents on the client, so the debate is rarely about the cipher. It is about where ciphertext and metadata pile up, how much a hostile or breached server can do, who carries the patching burden, and what happens to sign-ins at 03:00 when the vault is unreachable. This guide compares the two models for security architects, IT managers and risk owners making or revisiting the decision. It goes deeper than the Password Manager Buyer's Guide on the hosting question and does not repeat its evaluation criteria. Products are listed alphabetically where named, and order is never a ranking.

Key takeaways

• The cipher is the same; the blast radius is not. A cloud provider concentrates millions of encrypted vaults in one place, so a provider breach exposes ciphertext and unencrypted metadata for every customer at once; a self-hosted vault limits exposure to your own estate but makes you the target and the responder.
• "Zero knowledge" is a design claim, not a guarantee. Peer-reviewed research published for USENIX Security 2026 found 31 attacks against four cloud password managers under a malicious-server model, so treat the server as untrusted whichever model you pick.
• Self-hosting moves the patching clock to you. Your team owns the operating system, container runtime, database, reverse proxy and application updates, and a known exploited flaw in a self-hosted vault server is your incident, not the vendor's.
• Offline resistance depends on your settings, not your hosting. If vault ciphertext leaks, the master password length and the key derivation function settings decide how long it holds, so enforce them in both models.
• Recovery and availability are the deciding factors for most organisations. Decide in advance how users get access during a provider outage or a self-hosted server failure, and test it; that test usually settles the choice.

How the two models differ

The NCSC's password manager guidance draws the basic line: cloud-sync managers store password data on a remote server so it can be reached from several devices, while on-device managers keep the data on one device, which means an attacker must reach that device but is less convenient for people who work across devices. A self-hosted vault sits between the two: a server you run, usually in your own data centre or cloud tenancy, that syncs encrypted vaults to your users' clients. File-based vaults such as KeePass databases are a lighter form of self-hosting, where the encrypted file lives on storage you control.

Threat model: cloud password manager

A cloud provider is a high-value, shared target. The NCSC notes that password managers are a natural target for anyone trying to gain unauthorised access to accounts, and that data crosses untrusted networks between cloud and client.

• Provider infrastructure breach: attackers who reach the provider's storage can copy encrypted vaults for many customers in one go. In the LastPass breach of 2022, the company's own incident notice describes keys taken in an August 2022 intrusion being used to access a third-party cloud storage environment and copy a backup of customer vault data containing fully encrypted fields and unencrypted fields such as website URLs. The UK Information Commissioner's Office fined LastPass UK Ltd £1.2 million on 11 December 2025, said up to 1.6 million UK users were affected, and found no evidence that customer passwords were decrypted.
• Offline cracking after exfiltration: stolen ciphertext can be attacked indefinitely. The same notice tied customer risk to the master password and the PBKDF2 iteration count on each account, which is why legacy accounts with low iteration counts or short master passwords were the exposed ones.
• Malicious or compromised server: "zero knowledge" claims imply the provider cannot read vaults even if its server turns hostile. The ETH Zurich and Università della Svizzera italiana paper, published as IACR ePrint 2026/058 and at USENIX Security 2026, tested that claim against 1Password, Bitwarden, Dashlane and LastPass and described 31 attacks under a fully malicious server model, noting that "Zero Knowledge Encryption" has no strict technical meaning. The authors reported the findings to the vendors and said remediation was underway. Their lesson applies to every product: sharing, key rotation, organisation key distribution and recovery features are where server trust creeps back in.
• Tenant takeover through identity: most real tenant compromises go through admin accounts, SSO trust and SCIM tokens rather than cryptography. Admin console hardening is covered in Securing the enterprise password manager.
• Concentration and dependency: a provider outage or regional incident stops sign-ins that depend on vault access, and you cannot fix it.

Threat model: self-hosted password vault

Self-hosting removes you from a shared pool, so a mass provider breach no longer exposes your vaults. In exchange you inherit everything the provider used to do.

• Internet-facing server exploitation: a vault server reachable from the internet so remote staff can sync is a classic initial access target. CISA's Known Exploited Vulnerabilities catalogue added CVE-2022-35405, a remote code execution flaw in a self-hosted password and privileged access product, on 22 September 2022, a reminder that self-hosted credential stores are exploited in the wild and that the patching deadline is yours.
• Patching lag and end-of-life platforms: Bitwarden's self-host FAQ says self-hosted updates typically arrive a few days after the cloud release and that self-hosted servers should run on platform versions that are still in support. Every day between release and your deployment is exposure you own.
• Host and database compromise: anyone with root on the host or access to the database and its backups gets the same ciphertext a cloud attacker would, plus server-side configuration and secrets such as installation keys, which Bitwarden's documentation says should be treated as secrets.
• Insider and admin risk: your infrastructure admins can alter server code or configuration. Against a malicious server, the ETH Zurich findings apply just as much to a server you run if an insider or attacker controls it.
• File vault handling (file-based model): a KeePass database is encrypted as a whole, including user names, URLs and notes, with AES-256 or ChaCha20 and HMAC-SHA-256 integrity, but copies of the file spread to laptops, sync folders and backups. The protection then rests entirely on the master key and KDF settings.
• Backup and key loss: losing the database, its keys or configuration can lock everyone out. Restoring an old backup can also resurrect revoked users or old secrets.

Vendor breach exposure and zero-knowledge claims

Most products in both models perform encryption on the client. Bitwarden's documentation, for example, says data is encrypted on the device before it is sent and that servers are only used to store encrypted data, using AES-256-CBC with HMAC-SHA-256 and RSA-OAEP for sharing features such as organisations and emergency access. The NCSC's criteria say the decryption key should not be accessible to others, including the cloud service provider, and that administrators should not be able to see or use individual passwords unless they belong to a shared group.

What separates a resilient design from a brittle one is what remains exposed when ciphertext leaks, and how much the server can influence clients. Use this table when reading a vendor's security white paper or testing a self-hosted build.

For KDF settings, Bitwarden's documentation states a default of 600,000 PBKDF2-SHA256 iterations, described as recommended by OWASP, and Argon2id defaults of 32 MiB memory, 6 iterations and 4 threads. KeePass offers AES-KDF and Argon2 (Argon2d or Argon2id). Whatever the product, set organisation minimums and audit for old accounts below them. Master password length rules follow NIST SP 800-63B-4; see the Password Policy Guide (NIST-aligned).

Patching burden, recovery and availability

This is where self-hosting is usually under-costed. A realistic self-hosted operating model includes:

1. Platform patching: host OS, container runtime (Bitwarden self-hosting runs in Docker Linux containers), database engine, reverse proxy and TLS certificates, each on its own release cycle.
2. Application updates within a defined window: for example 72 hours for security releases and immediately for anything listed in the CISA KEV catalogue, with a staging instance to test client compatibility.
3. Backups that include keys: database, server-side keys, configuration and attachments, encrypted and stored immutably and separately from the server's admin identities. See the Backup Security and Immutable Backup Guide.
4. Restore testing: a quarterly restore to an isolated host, verifying integrity before use and that revoked users stay revoked.
5. High availability and disaster recovery: a second site or region, documented recovery time and point objectives, and monitoring with an on-call owner.
6. Offline access: clients that cache vaults locally keep working when the server is down; confirm cache behaviour and how long it persists on lost devices.

Cloud services remove most of that list but not all of it. You still own client updates on managed devices, offline cache policy, exports, and a plan for a provider outage. For both models, break-glass credentials for the identity provider, the vault's own admin accounts and core infrastructure should not depend solely on the vault being reachable. See the Break-Glass Account Guide.

Where identity fits

Password managers hold human credentials, but many vaults end up holding machine ones too: cloud access keys, API tokens and database passwords that engineers paste into personal or shared folders. The LastPass incident is the clearest example, where keys for backups sat in an engineer's vault. Whichever hosting model you choose, move non-human credentials to a secrets manager or workload identity and keep the password manager for people. See Password Manager vs Secrets Manager. The vault platform also has its own non-human identities, SCIM tokens, directory connectors and API keys, which need owners and rotation; see the Password manager (enterprise) integration security guide.

Decision guidance

Small vs large organisations: small teams rarely sustain the patching and restore discipline self-hosting needs. Large organisations often split: a cloud product for the general workforce and a self-hosted or file-based vault for segregated networks, with privileged and break-glass credentials in a PAM platform. Product-specific settings for the options named here are in the 1Password Security Guide, Bitwarden Security, Dashlane Security, KeePass and KeePassXC Security and LastPass Security guides.

Worked scenario: a 900-person firm with one segregated network

A professional services firm has 850 office and remote staff and a 50-person team working in a segregated client network with no internet access. Its IT team has three engineers and no 24-hour cover.

1. Split by environment: the general workforce moves to a cloud password manager with SSO, enforced MFA, a 15-character master password minimum and an organisation KDF minimum. The segregated team uses a self-hosted vault inside its enclave, because cloud sync cannot reach it.
2. Size the self-hosted burden: the enclave vault serves 50 users, so the firm accepts a single server with a warm standby, a seven-day patch window (KEV items within 48 hours), and nightly encrypted backups to immutable storage inside the enclave.
3. Remove machine credentials: an audit of shared folders finds 140 cloud keys and service passwords; these move to the secrets manager and are rotated.
4. Test failure modes: the firm simulates a provider outage (users confirm offline cache access, break-glass identity provider accounts are held outside the vault) and restores the enclave vault to a test host each quarter.
5. Write the exit plan: export procedures for both vaults are documented, run on managed devices only, and followed by secure deletion. See the Password manager (enterprise) migration playbook.

Detection and measurement

The NCSC criteria call for logging vault access, failed unlocks and device enrolment, auditing admin access and distinguishing shared from individual credentials. Send those events to your SIEM in both models; for self-hosted servers add host, database and proxy logs. Watch for bulk exports, new admin grants, recovery requests, KDF or policy downgrades, unusual device enrolments and unlocks from new locations (MITRE ATT&CK T1555.005 Password Managers covers adversaries extracting credentials from vaults).

• Patch latency (self-hosted): hours from vendor security release to production; target within your defined window, 100% for KEV items.
• KDF compliance: percentage of accounts at or above the organisation's KDF minimum; target 100%.
• Restore success: quarterly restore tests passed, with measured recovery time against objective.
• Machine credentials in human vaults: count of cloud keys, tokens and service passwords found in vault folders; target zero.
• Admin and recovery hygiene: admin accounts with phishing-resistant MFA and recoveries performed with logged approval; both 100%.
• Provider assurance (cloud): date of last reviewed third-party audit and vendor advisory review; annually at most.

Framework mapping

Common failure patterns

• Choosing self-hosted for control, then not patching it: an internet-facing vault server months behind on updates is worse than a cloud tenancy. Set a patch window before go-live and track it.
• Machine keys in a person's vault: the LastPass breach of 2022 shows how backup keys held in an engineer's vault turned an endpoint compromise into access to customer vault backups.
• Legacy KDF settings left in place: old accounts keep low iteration counts after defaults are raised, which is exactly what offline cracking targets after ciphertext leaks.
• Backups without keys, or keys without backups: self-hosted teams restore the database and discover server keys or configuration were never captured.
• Treating "zero knowledge" as a reason to skip assurance: the 2026 research shows sharing, recovery and organisation key features need testing and vendor evidence.
• Break-glass that depends on the vault: the identity provider's emergency accounts stored only in the password manager become unreachable in the outage they exist for.

Practitioner checklist

• Record the hosting decision with the threat model, the operating owner and the reasons, and review it annually.
• List which vault fields are unencrypted in your chosen product and decide whether that metadata is acceptable at the host.
• Enforce a master password minimum and an organisation KDF minimum, and audit legacy accounts below it.
• For self-hosted servers, set patch windows, subscribe to vendor advisories and the CISA KEV feed, and keep platforms in support.
• Back up database, server keys, configuration and attachments together, immutably, and restore-test quarterly.
• Hold identity provider and vault break-glass credentials outside the vault and test access during a simulated outage.
• Move cloud keys, API tokens and service passwords out of human vaults into a secrets manager.
• Send vault, admin and recovery events to the SIEM and alert on bulk export, policy downgrade and new admin grants.
• Ask cloud vendors for current third-party audits and their response to the 2026 malicious-server research.
• Document and rehearse an exit or migration path for whichever model you choose.

Standards and references

• NCSC: Password manager buyers guide
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• IACR ePrint 2026/058: Zero Knowledge (About) Encryption, A Comparative Security Analysis of Three Cloud-based Password Managers
• CISA: Known Exploited Vulnerabilities Catalog
• ICO: Password manager provider fined
• LastPass: Notice of recent security incident
• Bitwarden: Self-host FAQs
• KeePass: Security

Related NHI Mgmt Group resources: Password Manager Buyer's Guide · Securing the enterprise password manager · Password Manager Vault Breach Response Playbook · Password Manager vs Secrets Manager