Notifications
Clear all
Topic starter
10/06/2026 10:59 pm
TL;DR: Encryption happens on the device, the keys never reach the service’s servers, and cloud processing is moved into confidential computing enclaves, according to 1Password. That shifts the real security question from trust in promises to trust in architecture, and it matters as password managers become a control point for human, NHI, and AI agent access.
NHIMG editorial — based on content published by 1Password: Zero-knowledge, not promises: How 1Password secures your data
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
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.
Q: Why do zero-knowledge password managers matter for NHI and secrets governance?
A: They reduce the number of places where secrets can be exposed, which matters when service accounts, API keys, and human credentials are all managed through the same platform.
Q: What breaks when a password manager offers cloud features that need plaintext access?
A: The zero-knowledge boundary breaks the moment the provider must see readable data to perform a feature.
Practitioner guidance
- Verify key custody boundaries Map exactly where encryption, decryption, and recovery occur in your password manager and secrets tooling.
- Demand attestation for cloud-side processing For any feature that processes sensitive identity data in the cloud, require hardware-backed attestation, published execution code, and a documented trust model for the enclave or equivalent control.
- Reassess convenience features that imply server visibility Test whether search, reporting, breach checks, or analytics force plaintext exposure anywhere in the workflow, especially when the same platform also supports human logins and automated access paths.
What's in the full article
1Password's full post covers the operational detail this analysis intentionally leaves for the source:
- The exact local encryption and key derivation model used to protect vault data before sync
- The confidential computing enclave approach used for cloud-side processing and verification
- The recovery constraints and feature tradeoffs that follow from a zero-knowledge architecture
- The implementation details behind breach checks, attestation, and published code review
👉 Read 1Password’s explanation of zero-knowledge vault architecture →
Zero-knowledge vaults: what it means for IAM and secrets teams?
Explore further
12/06/2026 4:45 am
Zero-knowledge is a control boundary, not a branding claim. The article’s core point is that the service cannot read vault contents because the architecture makes that impossible, not because a policy says so. That distinction matters across human credentials, NHI secrets, and agent access because trust statements fail the moment a provider, host, or attacker can observe plaintext. Practitioners should treat this as an architectural constraint that changes what the platform can ever be asked to do.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
A: They should look for hardware-backed isolation, published enclave code, and cryptographic attestation that lets them verify what ran inside the protected environment. If those pieces are missing, the cloud feature is relying more on trust than on technical containment. That is a weak position for identity and secrets workflows that handle high-value credentials.
👉 Read our full editorial: Zero-knowledge vault design changes the password manager trust model
