How do you evaluate whether a password vault is truly zero-knowledge?

What makes a password vault zero-knowledge in practice?

A true zero-knowledge vault is defined by who can technically decrypt data, not by marketing language. The provider should only see encrypted blobs and limited operational metadata, while encryption and decryption happen on the user device. That means the design must prevent the provider from reconstructing the master secret or silently acting as a decryption party.

The strongest test is whether the service can function without ever possessing the material needed to read vault contents. Client-side encryption, user-controlled keys, and a key derivation design that never exposes the master secret to the provider are the core indicators. If provider support can reset access by itself, that is a warning sign that some recovery path may exist outside the zero-knowledge boundary.

A useful way to frame this is to distinguish encryption from custody. Encryption Guide explains the broader cryptographic controls, but zero-knowledge depends on where the keys live and who can influence recovery. If the provider can ever derive, recover, or escrow the secret material needed to decrypt the vault, the service is not zero-knowledge in the practical sense.

Which design checks prove the claim?

Start with the key path. Confirm that the master secret is generated and held only on the user side, then verify that the provider never receives a reusable copy during sign-in, sync, or recovery. A legitimate zero-knowledge design should make server-side compromise insufficient to reveal plaintext vault data, because the server never holds the decryption key.

Next, inspect the recovery model. Some products say they are zero-knowledge while still offering account recovery that depends on email links, recovery codes, shared secrets, or provider-mediated reset flows. Those features are not automatically disqualifying, but they need close scrutiny, because the provider should not be able to regain access to vault contents on its own. The Password Manager Buyer's Guide is useful here because it focuses on the exact questions to ask about encryption scope, metadata exposure, and reset paths.

Finally, examine the cryptographic implementation, not just the headline claim. A strong key derivation function, protected local storage, and careful handling of sync metadata all matter because weak derivation or poor client design can expose the master secret through brute force, device compromise, or implementation error. The claim is only credible if the provider is structurally unable to decrypt, not merely promising not to do so.

What evidence shows the provider can still see your secrets?

If the provider can read vault contents, inspect decrypted fields, search indexed data, or perform support actions that reveal secrets, then the zero-knowledge claim has failed. The same is true if the architecture allows the provider to reset access without user-held recovery material, because that usually means the provider has some privileged role in restoring decryption capability.

Watch for operational wording that reveals the trust model. Phrases like full account recovery, emergency support access, server-side decryption assistance, or policy-based access restoration often indicate that the provider has a path to influence plaintext access. For enterprise buyers, this is not a cosmetic issue, because the wrong recovery model can turn a vault into a managed secret store rather than a genuinely user-controlled one.

That is why procurement should include breach and recovery scenarios, not just feature checklists. Password Manager Vault Breach Response Playbook is relevant because it shows how fast the question becomes, which secrets were protected by the vault, and what can still be rotated if the provider or an attacker can reach the encrypted store.

Risk and Threat Considerations

The main risk is false trust. A vault that is only "encrypted" but not zero-knowledge can still expose every stored credential, token, or recovery secret if the provider is compromised, coerced, or operationally misconfigured. In practice, this creates a single point of failure for the user’s highest-value secrets and can widen the blast radius of one vendor incident.

Failure mechanism: The architecture leaves some entity on the provider side able to decrypt, derive, or restore access to vault contents, so attacker compromise, insider access, or support-driven reset can cross the boundary into plaintext exposure.

Impact: Vault contents, recovery paths, and sometimes related session or account data may become readable or resettable at scale, which can trigger credential theft, account takeover, and broad downstream compromise.

Practitioner Guidance

What to verify: Ask the vendor to explain, in plain terms, which operations are impossible for them to perform. A credible answer should separate encrypted storage from recoverable access and should show that the provider cannot decrypt vault data, recover the master secret, or impersonate the user during recovery.

Decision rule: If the vendor can reset access without user-held recovery material, treat the service as not truly zero-knowledge until you have audited the exact recovery design and accepted the resulting trust boundary. If the product depends on provider-mediated support to restore secrets, that is a different security model.

Practitioner takeaway: Zero-knowledge is a cryptographic and operational property, so the real test is whether the provider can ever become a decryption path, not whether the product advertises encrypted storage.

Related resources from NHI Mgmt Group

• Guide: Privileged Access Management Guide
• Password Vault
• Zero Knowledge
• How should security teams evaluate zero-knowledge claims in password managers?
• What is the difference between zero-knowledge password management and standard vault-based password storage?