Zero-knowledge vault design changes the password manager trust model

At a glance

What this is: This is a technical explainer of zero-knowledge vault design and confidential computing, showing how 1Password shifts trust from policy promises to enforced architecture.

Why it matters: IAM, secrets, and identity teams need to understand where encryption, key custody, and cloud processing boundaries sit when a password manager becomes a control point for human, NHI, and agent access.

Context

Zero-knowledge vault design changes the basic assumption behind password managers: the provider should not be able to read plaintext vault contents at any stage. That matters because these tools now sit in the access path for human users, service credentials, and increasingly AI-enabled workflows.

The governance problem is not only whether a vendor says it cannot see data, but whether the architecture makes that claim technically true. For IAM and secrets teams, the question becomes where encryption happens, who ever holds the key, and whether cloud-side processing expands the trust boundary.

1Password frames its approach as a way to keep storage, sync, and cloud computation aligned to the same zero-knowledge model. The practical significance is that trust decisions move from contractual assurances to independently verifiable design choices.

Key questions

Q: How should teams evaluate a zero-knowledge password manager for enterprise use?

A: They should verify three things: encryption happens before data leaves the device, the provider never receives usable keys, and any cloud-side processing occurs inside a verifiable isolation boundary. They should also test recovery, breach-check, and search requirements against those constraints so operational convenience does not quietly reintroduce provider trust.

Q: What breaks when a password manager cannot see vault contents?

A: Central recovery, server-side search, and provider-driven inspection all break by design. That is not a defect in a zero-knowledge model, but it does mean organisations must own recovery paths, key handling, and user support expectations rather than assuming the service can step in later.

Q: Why does confidential computing matter for secrets management?

A: It matters because some enterprise features require data to be processed in usable form, which normally expands trust to the cloud host. Confidential computing narrows that exposure by isolating the computation inside an attested enclave so the infrastructure layer cannot freely inspect the data.

Q: How do IAM teams decide whether zero-knowledge tradeoffs are acceptable?

A: They should compare the security value of reduced provider trust against the operational cost of limited recovery and no server-side search. If the organisation needs the provider to see vault contents for support, the architecture is not truly zero-knowledge and should be treated as a different risk model.

Technical breakdown

Device-side encryption and key custody

Zero-knowledge vaults encrypt data before it leaves the endpoint, so plaintext is transformed into ciphertext on the user’s device and only devices with the right keys can reverse it. In this model, the service provider stores unreadable data and never receives the Secret Key or account password in a usable form. That changes the trust model from custodian to transport and sync layer. It also reduces the blast radius of a server compromise because stolen vault data remains unintelligible without the local keys.

Practical implication: Treat key custody and encryption point as the control boundary, not the vault brand or service promise.

Confidential computing for cloud-side processing

Some enterprise features require server-side computation, which normally forces the provider to handle data in a usable form. Confidential computing addresses that by running workloads inside a hardware-enforced enclave with isolated execution and cryptographic attestation. The enclave limits what the host, cloud operator, and service can observe while still allowing processing to happen. This is not the same as simply encrypting data at rest. It is an attempt to keep computation bounded even when processing moves into the cloud.

Practical implication: Evaluate whether cloud-side features are processed inside attested enclaves before allowing sensitive data into the workflow.

Zero-knowledge tradeoffs for recovery and search

Zero-knowledge architecture also removes provider-side recovery options and server-side inspection features. If the provider cannot see plaintext, it cannot reset forgotten keys on behalf of the user or search vault contents centrally. That creates deliberate constraints, not product gaps. On the positive side, breach intelligence features can be designed to run locally, such as partial-hash checks against known-compromised credentials. The governance question is whether the organisation accepts these tradeoffs in exchange for reduced provider trust.

Practical implication: Map recovery, search, and breach-check requirements before standardising a zero-knowledge vault model.

NHI Mgmt Group analysis

Zero-knowledge vaults convert trust from a promise into a technical property. The provider’s inability to decrypt vault contents is only meaningful if encryption occurs before data leaves the device and keys never reach the service. That removes a whole class of provider-side exposure assumptions and makes architecture, not policy language, the primary assurance mechanism.

Confidential computing is the control that closes the gap between local privacy and cloud processing. Once enterprise features require server-side computation, the question is no longer whether the cloud can be trusted in the abstract. The question is whether the computation is constrained inside an attested enclave that materially limits what infrastructure operators can observe.

Zero-knowledge creates a deliberate governance tradeoff that IAM teams must plan for. If the provider cannot see plaintext, it cannot offer central recovery or full server-side search, and that constraint is part of the security model. The practical implication is that organisations should treat recovery design and operational convenience as security decisions, not afterthoughts.

Identity control points are shifting toward verifiable data handling, not just authentication strength. Password managers now sit in the path for humans, NHIs, and AI agents, so the critical question is who can ever see the secrets they broker. Practitioner teams should require evidence of key custody, enclave attestation, and local-only processing where plaintext is involved.

Zero-knowledge vault design is a useful marker for the broader secrets-management market. The category is moving away from trust-me SaaS patterns toward architectures that can withstand vendor compromise, legal compulsion, and expanding machine access. Teams evaluating vault and password manager platforms should assess whether the product reduces trust or merely relocates it.

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: Guide to the Secret Sprawl Challenge

What this signals

Zero-knowledge vaults push identity governance toward verifiable custody. If a provider cannot decrypt stored secrets, then review cycles need to focus on key location, device trust, and the processing boundary instead of assuming that SaaS controls are sufficient. That is a material shift for teams managing human access, NHI credentials, and agentic access paths.

Confidential computing becomes the bridge control for cloud-based secret processing. When a password manager must compute on sensitive material, the relevant question is whether the work happens inside an attested enclave with a narrow visibility surface. For practitioners, this is where secrets governance meets workload identity and cloud trust assurance.

Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey at a time when password managers are increasingly part of broader access workflows. That gap matters because a zero-knowledge model only helps if secrets handling is centralised, governed, and understood across the access stack.

For practitioners

• Verify where plaintext is first exposed Map the exact point at which secrets are encrypted and confirm that encryption happens on the device before sync or storage occurs.
• Check who ever receives the keys Confirm that the Secret Key and account password never transit or persist on provider systems, backup paths, or support tooling.
• Review cloud processing boundaries Require evidence that any server-side computation runs inside attested confidential computing enclaves rather than general-purpose infrastructure.
• Document recovery and search tradeoffs Decide upfront whether your operating model accepts provider-limited recovery and the absence of server-side vault search in exchange for zero-knowledge guarantees.
• Assess agent access through the same trust model Apply the same custody and processing questions to AI-driven workflows that retrieve secrets, because agent access expands the blast radius of weak vault governance.

Key takeaways

• Zero-knowledge vault design changes the trust question from vendor assurance to architectural proof, because the provider cannot read plaintext by design.
• The main tradeoff is operational: if the service never sees the keys, it also cannot provide central recovery or full server-side inspection.
• For IAM and secrets teams, the deciding factors are encryption point, key custody, and whether any cloud computation stays inside an attested boundary.

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.
• Confidential Computing: A method of processing sensitive data inside a protected hardware enclave so the cloud operator cannot inspect the data while it is in use. It combines isolation, attestation, and controlled execution to reduce exposure during cloud-side computation without forcing plaintext access.
• Cryptographic Attestation: Cryptographic attestation is a method of proving that a workload or service is genuine by using cryptographic evidence instead of static shared secrets. It is especially useful for short-lived access models because identity proof is tied to runtime context rather than reusable credentials.
• Secrets Custody: Secrets custody is the operational responsibility for storing, decrypting, and exposing credentials only to the systems that truly need them. In workflow and agent platforms, weak custody means a runtime compromise can reveal API keys, OAuth tokens, certificates, and cloud credentials at once.

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.