Cloud password managers expose structural vault trust gaps

At a glance

What this is: ETH Zurich research, as reported by Swarmnetics, says cloud password managers share structural vulnerabilities that cannot all be removed without changing how shared, multi-device vaults work.

Why it matters: For IAM and NHI teams, the lesson is that convenience-driven vault design creates governance gaps that affect both human credentials and machine secrets.

By the numbers:

• The ETH Zurich study notes that the three password managers it examined collectively have about 60 million users.
• 12.
• Cloud-based password managers have become very popular given that people now tend to juggle well over 100 login credentials.

👉 Read Swarmnetics' analysis of cloud password manager trust gaps and structural flaws

Context

Cloud password managers reduce user friction, but they also concentrate trust into a browser, sync layer, and server-side vault model that attackers can pressure in multiple places. The article’s core finding is that several widely used products share vulnerabilities that arise from how cloud-based vaults balance accessibility with secrecy, which is a familiar governance problem for both human identity and non-human identity programmes.

The identity angle is direct. A vault that serves people, shared accounts, and cross-device access sits close to the same control questions that govern NHI secrets, token storage, and lifecycle discipline. When a design depends on user behaviour to stay safe, the control boundary becomes easier to bypass than most policy documents assume.

Key questions

Q: What breaks when a cloud password manager relies on shared vault access?

A: Shared vault access blurs ownership, revocation, and accountability. Once multiple users or devices can reach the same secrets, compromise is no longer contained to one account or one session. Security teams should assume that shared access expands blast radius unless every secret has a clear owner, a revocation trigger, and a separate review process.

Q: Why do cloud vaults create more risk than offline password storage?

A: Cloud vaults trade isolation for synchronisation and collaboration, which introduces extra trust in client software, recovery flows, and server-side sync. That does not make them unusable, but it does mean attackers have more ways to target the path to the secret. The risk rises when users reuse vault access across devices and contexts.

Q: How do security teams know whether vault controls are actually working?

A: Look for evidence that secrets are owned, rotated, and revoked on schedule, and that shared access is rare and justified. If teams cannot tell who depends on a secret, where it is stored, and how fast it can be removed, the control is administrative rather than operational.

Q: Who is accountable when a password manager vulnerability exposes credentials?

A: Accountability is shared, but not evenly. The vendor is accountable for architectural and software flaws, while the organisation remains responsible for how secrets are stored, shared, and monitored. In practice, IAM and security teams must own the risk acceptance decision for any vault workflow that depends on legacy behaviour or broad sharing.

Technical breakdown

Why cloud vault architecture creates shared trust exposure

Cloud password managers typically separate encryption from synchronisation, which means the vault must be usable across devices while still hiding secrets from the provider. That balance creates a trust chain across client software, sync services, recovery flows, and user sessions. If an attacker can influence any one of those layers, the security model becomes much more fragile than the marketing phrase "zero-knowledge" suggests. The study’s point is not that encryption is meaningless, but that architecture determines where the security boundary actually lives.

Practical implication: treat the sync and recovery path as part of the attack surface, not just the vault contents.

How legacy encryption and compatibility constraints persist

The article notes that some password managers retain older encryption choices because users expect cross-platform compatibility and long-lived access. That creates a familiar security trade-off. Once a legacy method becomes embedded in migration paths, shared account support, or older clients, deprecating it can break workflows, so vendors often patch around it instead of removing it. The result is a structural weakness that persists even after point fixes, because the underlying compatibility promise remains intact.

Practical implication: inventory vault features that depend on legacy compatibility and decide which ones should be retired rather than merely patched.

Where multi-user sharing changes the security boundary

Shared logins and multi-device use make cloud vaults operationally useful, but they also blur responsibility for access, revocation, and session control. In practice, the vault becomes a distribution system for secrets rather than a static container. That matters for identity governance because the same pattern appears in service accounts, API keys, and delegated access where access needs to be time-bound, attributable, and revocable. If sharing is normalised, misuse can look like ordinary behaviour until after exposure.

Practical implication: apply separate governance to shared vault access, especially where the same secrets are reused across people or applications.

Threat narrative

Attacker objective: The attacker wants to turn a single vault interaction into reusable credential access across multiple services and devices.

1. Entry begins when an attacker can influence a compromised server, client session, or sync workflow tied to the password manager.
2. Credential access follows when the user logs in, views the vault, or syncs data, giving the attacker a chance to harvest secrets from routine interactions.
3. Impact occurs when exposed credentials are reused across services, allowing follow-on account takeover or broader access beyond the original vault.

NHI Mgmt Group analysis

Cloud vault convenience is now a governance problem, not just a consumer feature. The article shows that the security model for cloud password managers depends on trust spread across clients, sync services, and user behaviour. That is a governance issue because the attack surface expands every time a tool is designed to be portable, collaborative, and always available. For IAM teams, the right question is not whether the vault encrypts data, but where the trust boundary actually sits.

Legacy compatibility is the hidden reason many secret platforms keep structural weaknesses alive. The study makes clear that some flaws are difficult to remove because deprecating older cryptography or workflow paths would disrupt customers. This is the same pattern that drives NHI secret sprawl, where operational convenience outlasts security redesign. The named concept here is compatibility debt, meaning the accumulated security cost of keeping old access patterns alive to preserve user experience. Practitioners should treat compatibility as a risk driver, not a neutral product requirement.

Cloud password manager risk extends directly into NHI governance. The same storage, sharing, and synchronisation assumptions that affect human passwords also affect API keys, service account secrets, and shared tokens. Once secrets are designed for easy distribution, lifecycle control weakens unless ownership, rotation, and revocation are enforced independently of the vault interface. That makes identity governance the control layer that determines whether convenience becomes manageable or merely tolerated.

Zero-knowledge claims are not the same as zero exposure. The article underscores a common misconception: a vendor may not be able to inspect vault contents, yet attackers can still abuse the mechanisms that move secrets between people and devices. For security architects, that means evaluating control inheritance across client software, browser extensions, and sync channels. The practitioner conclusion is simple: visibility claims do not replace threat modelling.

Architectural flaws require control substitution, not just patch management. If a weakness lives in the way shared vaults function, fixing one code path will not remove the underlying exposure. That is why IAM and PAM teams should look for compensating controls such as stronger session assurance, reduced sharing scope, and tighter secret ownership. The field should stop treating vault security as a product checkbox and start treating it as a lifecycle discipline.

What this signals

Compatibility debt is the clearest operational signal in this topic. When teams keep legacy vault modes alive to preserve convenience, they inherit security assumptions that no longer match how credentials are used across browsers, devices, and shared workflows. Practitioners should review whether their secret handling rules still reflect the actual access paths in use, not the ones assumed by policy.

The practical shift is toward lifecycle discipline for every secret class, including human passwords, API keys, and service account tokens. The governance question is not whether a vault stores secrets securely in theory, but whether ownership, revocation, and rotation are visible enough to survive compromise. That aligns closely with the NIST Cybersecurity Framework 2.0 emphasis on governed protection and recovery, and with the access-control expectations embedded in NIST SP 800-53 Rev 5 Security and Privacy Controls.

The strongest programme response is to stop treating shared vault convenience as a default and start treating it as an exception. Where shared access is unavoidable, teams should introduce stronger review, narrower ownership, and faster revocation, especially for secrets that can unlock multiple systems. That is the same control logic that should govern NHIs, because secret distribution without lifecycle control is just privileged access with a friendlier interface.

For practitioners

• Audit shared-vault dependency paths Map where the password manager relies on browser extensions, sync channels, recovery flows, and shared logins, then document which of those paths would expose secrets if a single layer were compromised.
• Separate human and machine secret governance Do not let the same operational rules govern employee passwords, API keys, and service account tokens. Assign ownership, rotation cadence, and revocation triggers separately for each class of secret.
• Retire legacy encryption-dependent workflows Identify vault features that persist only because older clients or compatibility modes require them, then set a deprecation plan for the weakest pathways before attackers can exploit them.
• Limit secret sharing to explicit business cases Require approval for any shared login or shared vault use, and record the business purpose, owner, and revocation date so that normal collaboration does not become permanent access.

Key takeaways

• Cloud password managers are not risk-free vaults, because their security depends on a trust chain that includes client software, sync services, and user behaviour.
• The reported flaws matter because they affect millions of users and expose structural weaknesses that patching alone may not remove.
• Security teams should govern shared vaults as lifecycle-dependent access systems, not as neutral storage tools.

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: Zero-knowledge encryption is a design claim that the provider cannot read stored secrets because encryption keys are kept client-side. In practice, the term does not eliminate all risk, since compromise can still happen through client software, recovery paths, browser extensions, or session abuse.
• Compatibility Debt: Compatibility debt is the security cost of keeping older authentication, encryption, or workflow paths alive so users do not lose convenience. It often appears when vendors preserve legacy modes for migration or device support, but those paths can become persistent weaknesses that are hard to remove cleanly.
• Shared Secret Governance: Shared secret governance is the discipline of controlling who can use a credential, why it is shared, and when it must be removed. It becomes critical when the same password or token is used across people, devices, or applications, because revocation and accountability become much harder to enforce.

What's in the full article

Swarmnetics' full article covers the technical detail this post intentionally leaves for the source:

• A breakdown of the four attack categories the ETH Zurich study identified across the tested password managers.
• Product-specific vulnerability counts, including which of the three tools fared worst under the test conditions.
• The distinction between zero-knowledge marketing claims and the actual encryption and trust model used in practice.
• The researchers' remediation timeline and which issues they considered architectural rather than easily patchable.

👉 The full Swarmnetics article covers the ETH Zurich findings, attack categories, and product-level comparisons.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical operational terms. It helps security and identity teams connect secret handling to lifecycle control across human and non-human access.