Cloud password managers expose structural vault trust gaps

At a glance

What this is: Swarmnetics summarises ETH Zurich research showing that major cloud password managers share common structural vulnerabilities, including multiple attack types and design limits that cannot be fully eliminated.

Why it matters: For IAM and NHI practitioners, the article underscores that centralised vault convenience changes the trust model rather than removing it, so vault governance, device trust and secret hygiene remain control priorities.

By the numbers:

• Bitwarden was exposed to 12 attack types in the study, according to Swarmnetics.
• The article says the three password managers have about 60 million users, according to Swarmnetics.

Context

Cloud password managers centralise secrets, but centralisation also concentrates trust in the vault, the sync path and the client. When that trust model depends on the user connecting to a compromised server or completing routine actions that can be observed or abused, the security conversation shifts from convenience to governance.

The identity angle is straightforward: password vaults sit inside broader access control and secret management programmes, even when they are marketed for personal use. For IAM, PAM and NHI teams, the same structural question appears in different forms, namely which assumptions can be trusted at issuance, storage, sync and access time.

The study’s findings are typical of the cloud-vault class rather than an isolated product failure, which is why the article matters beyond one vendor or one flaw. The issue is not simply whether a password manager encrypts data, but whether its architecture can truly eliminate all meaningful exposure paths.

Key questions

Q: What breaks when cloud password managers rely on zero-knowledge claims?

A: The failure is not that encryption disappears, but that the provider can still have a system role in sync, device access and client execution. That leaves exposure paths for compromised servers, compromised endpoints and routine user actions. Security teams should treat zero-knowledge as a storage claim, not a guarantee that secrets cannot be reached through other parts of the system.

Q: Why do cloud password managers still create risk even when secrets are encrypted?

A: Encrypted storage protects the secret at rest, but it does not stop abuse of the access path used to retrieve, display or synchronise that secret. If an attacker can influence login, vault view or sync, they may still reach credentials without defeating the encryption itself. That is why access governance and device trust matter alongside cryptography.

Q: What signs show that a vault design is too dependent on user trust?

A: Warning signs include mandatory multi-device convenience, broad shared access, retained legacy encryption and claims that the provider can never see the vault even though the system still depends on server-mediated workflows. If those features are present, the design may be preserving exposure paths rather than removing them. Teams should test the trust model, not just the encryption statement.

Q: How should organisations govern cloud password managers in broader identity programmes?

A: Treat them as part of secret governance, not a standalone convenience layer. Ownership should cover account lifecycle, device trust, shared access rules and the conditions under which vault access is allowed. That approach aligns vault use with IAM and NHI controls instead of assuming the product itself is the control.

Technical breakdown

Why cloud vault trust depends on the client-server path

Cloud password managers rely on a client-server model in which secrets are encrypted, synced and decrypted across devices and sessions. That design improves usability, but it also creates a trust dependency on the server, the transport path and the client runtime. If an attacker can influence any of those points, the vault’s promise of isolation becomes conditional rather than absolute. The study’s key message is not that cloud vaults are unusable, but that convenience expands the number of places where the trust boundary can be stressed.

Practical implication: Treat the vault, sync channel and endpoint as one control plane and validate each separately.

What zero-knowledge means, and what it does not mean

Zero-knowledge in password managers usually means the provider should not be able to read the contents of a vault in normal operation. It does not mean the system is immune to abuse, because an attacker may still exploit client-side logic, compromised sessions or legitimate user actions such as login, vault view or sync. The article also notes that some products market this idea too broadly. For security teams, the useful distinction is between encrypted storage and a fully resilient access model, which are not the same thing.

Practical implication: Separate marketing claims from actual exposure paths when assessing vault risk.

Why some vault weaknesses are architectural

An architectural weakness is one that arises from the way a system is built, not from a single missing patch. In cloud password managers, features such as multi-device access, shared logins and legacy encryption support can preserve user convenience while also preserving attack surface. That makes certain issues hard to eliminate completely, because removing them may break core product behaviour. The practical lesson is that patching alone cannot solve every exposure pattern when the underlying design preserves the same trust assumptions.

Practical implication: Assume some vault risks need compensating controls, not just vendor remediation.

Threat narrative

Attacker objective: The attacker aims to reach stored secrets through ordinary vault interactions and reuse them for account compromise.

1. Entry occurs when an attacker or compromised server influences the normal vault interaction path, because the study says many attacks first require the user to connect to a compromised server.
2. Credential access follows when routine actions such as logging in, viewing a vault or syncing between devices expose secrets to the attack path.
3. Impact is theft or exposure of stored credentials, which can then be reused against accounts protected by the vault.

Breaches seen in the wild

• Bitwarden CLI npm compromise 2026: A malicious Bitwarden CLI on npm, linked to the Checkmarx campaign, targeted GitHub, npm, cloud and CI secrets from developers for 90 minutes.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud password managers create a vault trust gap: the problem is not encryption alone, but the mismatch between confidentiality promises and the realities of sync, sharing and endpoint exposure. Once secrets must move across devices and users, the vault becomes part storage system and part access control system. That means the governance question is whether the architecture can sustain its trust claims under normal operational use, not just in ideal lab conditions.

Zero-knowledge is often narrower than users assume: providers can avoid reading vault contents and still leave meaningful exposure paths intact. Client-side compromise, compromised servers and ordinary user interactions can all be enough to reach the secret surface. For identity programmes, that distinction matters because a secret store can look private while still failing at the point of access.

Some password manager weaknesses are structural, not merely patchable: supporting legacy encryption, multi-device workflows and shared credentials keeps attack surface alive even after remediation. The issue is similar to other identity systems where convenience preserves risk conditions. Practitioners should read this as a design limitation signal, not a simple product defect.

Secret management and password vaulting are converging governance problems: the same trust assumptions that shape consumer password managers also appear in enterprise NHI and secrets programmes. When a vault is the system of record for credentials, governance has to cover issuance, sync, storage, access and offboarding as one lifecycle. That is the control model security teams should normalise.

Cloud vault convenience should not be treated as a control substitute: the article reinforces that easier access can increase operational dependence on a single secret store. The right question is not whether the vault exists, but which compensating controls exist when the vault is reached through a compromised session or over-trusted device. Practitioners should design for failure paths, not marketing claims.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• Read next: Secrets Management Buyer's Guide

What this signals

Structural vault risk is a governance problem, not just a product problem: cloud password managers can be well designed and still preserve attack paths through device trust, sync and shared access. That means teams should evaluate the lifecycle around the vault, not only the vault itself. The control question is where secrets are allowed to move, who can trigger that movement and under what device conditions.

Secret sprawl and vault centralisation are now part of the same conversation: the more teams rely on a central vault, the more they need inventory, ownership and offboarding discipline for the credentials stored inside it. This is where NHI governance and human password hygiene intersect. A vault is only as safe as the lifecycle controls wrapped around it.

For practitioners

• Map vault trust boundaries Document where the vault provider, client runtime, sync service and endpoint each have visibility or influence over secrets.
• Reduce reliance on shared logins Replace shared password vault access with named accounts, device trust checks and explicit approval for any multi-user secret sharing.
• Harden endpoint access to vaults Require strong device posture before vault access, because many attack paths begin when a user connects from a compromised server or device.
• Review legacy encryption exposure Inventory any retained legacy encryption modes and decide whether user demand is keeping older secret-protection mechanisms alive longer than risk allows.

Key takeaways

• Cloud password managers reduce friction, but they also concentrate trust in the vault, the client and the sync path.
• The study shows multiple attack types across three major products, which is a sign of structural exposure rather than a single implementation bug.
• Teams should govern vault use as part of identity and secret lifecycle management, especially where shared access and legacy encryption remain in play.

Key terms

• Cloud Password Manager: A cloud password manager is a system that stores, synchronises, and retrieves user credentials across devices through an internet-connected vault. Its main security challenge is balancing usability with protection, because the same features that make access convenient also create more places where secrets can be exposed or abused.
• Zero-knowledge encryption model: An encryption design where the provider cannot read the stored data because decryption keys are held by the user or derived locally. For identity programmes, this reduces provider visibility but does not remove the need to govern recovery paths, enrollment state, and administrative authority around access continuity.
• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
• Shared Trust Boundary: A shared trust boundary is the point where multiple systems, teams, or identities rely on the same security controls and assumptions. It defines where trust is inherited rather than independently verified, so a weakness in one participant, credential, or control can affect others within that boundary.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It suits practitioners who need to connect secret governance, access control, and lifecycle risk across human and non-human identities.