TL;DR: ETH Zurich researchers tested password managers against a fully malicious server model and 1Password says the paper does not reveal new attack vectors beyond documented architectural limits, highlighting how zero-knowledge designs depend on local keys, public-key provenance, and end-to-end encryption. The broader lesson is that trust boundaries in encrypted identity systems are architectural, not just policy-based.
At a glance
What this is: This is 1Password's analysis of ETH Zurich research testing password managers against a fully malicious server model, with the key finding that the paper surfaces known architectural limits rather than new attack paths.
Why it matters: For IAM and identity security teams, it clarifies that zero-knowledge claims depend on key ownership, provenance, and encryption design, not on server-side permission controls alone.
Context
Zero-knowledge password managers are systems where the service cannot read customer data because decryption keys stay with the customer. In this model, server-side access policy is not the primary protection mechanism; cryptographic design is. That distinction matters for identity programmes because compromise assumptions shift from who can log in to who can prove key provenance and control local secrets.
1Password says the ETH Zurich paper did not reveal new attack vectors against its architecture, but it did re-emphasise a hard problem for encrypted identity systems: trusted key distribution under a hostile server assumption. For practitioners, the point is not whether the server is administratively restricted, but whether the system can still preserve confidentiality if the server is dishonest, compromised, or coerced.
Key questions
Q: What fails in a zero-knowledge password manager when the server is malicious?
A: The failure is not automatic decryption of vaults. The real issue is that a malicious server may be able to influence key distribution or substitute public keys, which can redirect encryption to the wrong recipient. Strong zero-knowledge designs still depend on local key custody and verifiable provenance, not on trusting server behaviour.
Q: Why does public-key verification matter in encrypted identity systems?
A: Because encryption is only as trustworthy as the key you encrypt to. If a service can hand out a dishonest public key, it can create a substitution path that preserves the protocol flow while breaking recipient trust. That is why provenance verification is a core control, not an optional enhancement.
Q: How should security teams evaluate zero-knowledge claims in password managers?
A: They should verify where encryption happens, who holds the keys, and whether the provider can ever access plaintext during normal operation or cloud processing. A true zero-knowledge design should make backend compromise far less useful because stored data is ciphertext only. The test is architectural, not contractual, and the strongest evidence is local encryption plus verifiable key custody.
Q: What is the difference between server-side access control and cryptographic trust?
A: Server-side access control limits what administrators can do inside the service, while cryptographic trust determines whether the service can ever read or reroute the protected data. In zero-knowledge architectures, cryptography defines the hard boundary. Policy can reduce exposure, but it cannot replace client-held keys or key provenance guarantees.
Technical breakdown
Why zero-knowledge systems depend on local key custody
Zero-knowledge architecture means the service never has enough information to decrypt customer data on its own. In the model described here, decryption requires the account password, the Secret Key, and the encrypted vault data, with the Secret Key retained on the client. Secure Remote Password (SRP) helps ensure password-derived secrets are not transmitted in reusable form. The important technical point is that confidentiality is enforced by the cryptographic boundary, not by server permission settings or administrative restraint.
Practical implication: Practitioners should treat local key custody as the control boundary and verify that no server-side workflow can reconstruct customer secrets.
Public-key provenance and vault-key substitution
The article’s central architectural concern is not a traditional permission bypass but weak public-key provenance. If a server can hand out dishonest public keys, it can redirect encryption and enable vault-key substitution under a malicious-server model. This is a structural limitation of server-mediated key distribution unless users can verify that a public key really belongs to the intended recipient. In other words, the failure mode is trust in key origin, not just trust in access policy.
Practical implication: Identity teams should evaluate how systems verify key provenance before relying on them for high-value secret exchange.
End-to-end encryption does not remove trust, it relocates it
End-to-end encryption keeps data hidden from the provider, but it does not eliminate trust assumptions. It moves them into client identity, key lifecycle, and the mechanisms used to verify recipients and rotate trust over time. The article points to broader industry-wide difficulty in building group encryption and management models that preserve trust in long-lived vault data while user-owned keys change. That makes encrypted identity systems a governance problem as much as a protocol problem.
Practical implication: Security architects should map which trust assumptions are cryptographic, which are operational, and which cannot be delegated to the provider.
Threat narrative
Attacker objective: The attacker’s objective is to trick users into encrypting to the wrong key path so vaulted data can be exposed through key substitution.
- Entry begins with a fully malicious or compromised server that can influence what keying material users receive.
- Credential abuse would occur if dishonest public keys or substituted vault keys redirect encryption to an attacker-controlled trust path.
- Impact is limited to what the architecture already permits, because the paper does not show a new bypass of end-to-end encryption or client-held secrets.
Breaches seen in the wild
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
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
Zero-knowledge security is a key-provenance problem, not a permission problem: The article reinforces that server-side access controls do not define the actual trust boundary in end-to-end encrypted identity systems. If the provider never holds the keys, then the real question is whether clients can verify where those keys came from and whether they were substituted. Practitioners should evaluate encrypted identity products on provenance guarantees, not on administrative access narratives.
Public-key substitution is the governance gap that matters here: The paper’s malicious-server model highlights that a dishonest server can remain within the protocol while still undermining trust in recipient identity. That is not a new class of policy failure, but a structural weakness in server-mediated key distribution. For identity programmes, this means recipient verification and key lifecycle design belong in the core control model, not in an appendix.
Encrypted identity systems relocate risk from the server room to the client and lifecycle layer: When the provider cannot decrypt data, customer trust depends on local secret custody, reliable device state, and careful handling of rotating user-owned keys. That makes account governance, key verification, and recovery design part of the same control plane. Security leaders should treat zero-knowledge as a cryptographic governance model with operational consequences, not as a marketing shorthand.
Key provenance should be treated as a named control domain: The practical challenge in this article is what we can call key provenance assurance, the ability to prove that encryption targets belong to the intended recipient. Without that assurance, even strong end-to-end encryption can be forced into a dishonest path by a compromised service. Practitioners should build identity architecture around provenance, not just around secrecy.
The paper validates the limits of hostile-server testing without rewriting the threat model: Scrutiny against a fully malicious server is useful because it stress-tests trust assumptions, but it should not be mistaken for evidence that the architecture is broken. The right interpretation is that some encrypted identity systems have known, hard-to-eliminate provenance gaps. Practitioners should use those gaps to decide where additional verification is mandatory.
What this signals
Key provenance assurance: Zero-knowledge products are only as strong as the mechanism that proves the recipient key is genuine. If the service can substitute keys or influence distribution, the confidentiality model depends on trust that the architecture was meant to eliminate.
Security leaders should treat malicious-server testing as a design review for trust assumptions, not as a feature comparison exercise. The useful question is whether the product can preserve confidentiality when the provider cannot be trusted to behave honestly.
For encrypted identity systems, lifecycle governance extends to key verification, client-side secret custody, and recovery design. That is where the control boundary lives, and that is where assurance work has to focus.
For practitioners
- Map the cryptographic trust boundary Document where decryption depends on client-held keys versus server-held metadata, and make that boundary explicit in your identity risk model.
- Verify public-key provenance Require a way to confirm that encryption targets belong to the intended recipient before relying on server-mediated key distribution for sensitive vault data.
- Review group-encryption assumptions Check whether shared vault or team-key workflows still preserve trust when user-owned keys rotate over time or when a provider cannot be assumed honest.
- Classify local secret custody as a control Treat account passwords, Secret Key storage, and client-side decryption paths as governance objects, not implementation details.
Key takeaways
- Zero-knowledge password managers shift the security boundary from server permissions to client-held keys and verifiable key provenance.
- The ETH Zurich research, as discussed by 1Password, does not show a new bypass of end-to-end encryption, but it does stress known architectural limits under a malicious-server model.
- Practitioners should evaluate encrypted identity tools on key custody, public-key verification, and recovery design rather than on administrative access claims alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article focuses on client-held secrets and trust in authentication and key distribution. |
| NHI-07 — Long-Lived Secrets | The analysis depends on how long-lived vault data and user-owned keys remain trustworthy over time. | |
| Recommendation — Review authentication flows for any server-mediated step that can undermine client-held trust. Reduce dependence on long-lived trust relationships and verify how keys are rotated and recovered. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key and secret lifecycle management is central to the custody model discussed in the article. |
| Recommendation — Apply authenticator lifecycle controls to client-held keys, secrets, and recovery material. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article distinguishes policy controls from cryptographic trust boundaries in identity systems. |
| Recommendation — Align authorization decisions with cryptographic trust boundaries instead of relying on admin permissions alone. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The malicious-server model is about abusing key material and trust paths that expose credentials. |
| Recommendation — Map dishonest key distribution and vault-key substitution to credential-access scenarios in threat monitoring. | ||
Key terms
- Zero-Knowledge Architecture: A design pattern in which the service provider cannot decrypt customer data because it never receives the keys needed to do so. The provider may store encrypted data and coordinate sync or processing, but it remains technically unable to read plaintext unless the architecture is broken.
- Public-Key Provenance: The ability to verify that an encryption key really belongs to the intended recipient. This matters when a service mediates key delivery, because a dishonest or compromised provider can otherwise redirect ciphertext without breaking the protocol in obvious ways.
- Secret Key: A Secret Key is an additional authentication factor used to strengthen account access beyond a password alone. It changes the security model by making one stolen credential less useful, but it also raises the bar for recovery and device trust because access depends on more than a memorised password.
- Vault key substitution: Vault key substitution is a failure mode in which a malicious or compromised server supplies the wrong public key, causing a user to encrypt data to an unintended recipient. The ciphertext remains encrypted, but confidentiality fails because trust in key provenance has been broken.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org