What is zero-knowledge encryption? How it works in 5 minutes

Zero-knowledge encryption is an architecture where encryption and decryption happen exclusively on the user's device. The server stores only ciphertext and encrypted keys. Even if the provider is breached, subpoenaed, or has a rogue employee with database access, the plaintext stays out of reach.

Zero-knowledge encryption in brief

The server never holds the decryption key. It stores ciphertext and encrypted keys only, so a breach, subpoena, or rogue admin gets nothing readable.
Keys are generated and used exclusively on the user's device, derived from a master password through PBKDF2, RSA, and AES-256 layers.
It protects data at rest, in transit, and in use, but not against phishing, careless sharing, or metadata exposure.
Pairing it with MFA, strong master password hygiene, and air-gapped deployment closes the gaps encryption alone doesn't cover.
A self-hosted deployment keeps the entire chain on the company's own hardware, with no outbound connection and no vendor infrastructure or staff in the trust boundary.
Verify a vendor's claim through a published documentation, independent audits, an honest recovery flow, and, ideally, auditable source code.

What zero knowledge actually means

Zero-knowledge architecture means the provider has no way to read your plaintext data, not that it simply chooses not to look. The distinction that matters: keys are generated and used entirely on the client, and the server only ever holds encrypted blobs it cannot decrypt on its own, even under legal compulsion.

Compare that with ordinary "encrypted storage." A provider might encrypt your data at rest, but if it also holds the decryption key, it can technically read that data whenever it wants. Encryption at rest protects against physical theft of hard drives. It doesn't protect against the provider itself, or against anyone who compromises the provider's infrastructure.

Three properties separate real zero knowledge from marketing copy:

Keys are generated client-side, using a cryptographically secure pseudo-random number generator (CSPRNG), not on a server.
The private key never leaves the device in plaintext and is never transmitted to the server unencrypted.
The server stores only encrypted blobs, including encrypted copies of the keys themselves.

Aspect	Standard encryption	Zero-knowledge architecture
Who generates the keys	Provider (server)	User's device (client)
Where keys live	Server, sometimes in reversible form	Encrypted, never in plaintext on the server
Can the provider read your data	Technically yes	Cryptographically no
What a breach exposes	Plaintext or weakly wrapped data	Ciphertext only

How the encryption chain works: a real example

Zero-knowledge encryption runs on a chain of key derivation and encryption steps, each one unlocking the next. In Passwork's cryptography model, a master password becomes a master key through PBKDF2. That master key decrypts a private RSA key, which decrypts vault keys, which decrypt the record keys protecting the actual passwords and secrets.

Here's the client-side chain, step by step:

Master password → master key. The user enters their master password. PBKDF2 (HMAC-SHA-256, 300,000 iterations) derives a 512-bit master key, and the server-side derivation runs at 600,000 iterations for an added layer. The high iteration count exists for one reason: it makes brute-forcing the password computationally expensive.
Master key → private RSA key. The master key decrypts the user's private RSA-2048 key (RSA-OAEP, SHA-256) with AES-256. That private key sits encrypted on the server. Without the master password, it's inert data.
Private key → vault key. The private RSA key decrypts a symmetric vault key (256-bit, roughly 596 bits of entropy). A vault holds a collection of records shared among team members, and each vault carries its own unique key.
Vault key → record key → record data. The vault key decrypts individual record keys, which in turn decrypt the actual passwords, secrets, and attached files, all through AES-256.
A second, independent layer. Separately from the client-side chain, a server key (256-bit, OpenSSL-generated) encrypts the database with AES-256. Two independent keys, two independent layers. Compromising one doesn't compromise the other.

What the server actually stores. Not the master password. Not the plaintext of anything. It stores: the encrypted master key hash for identity verification, the encrypted private key, encrypted vault and record keys, encrypted record data, and a verification hash used to confirm a login attempt without ever seeing the password itself.

Because the server never holds the client-side decryption key, a database breach yields only ciphertext. That's the payoff of the whole chain: anyone who steals the database, backups, or server-side key gets nothing usable.

That protection has a limit, though. It defends against infrastructure compromise, not against an attacker who obtains a valid master password and logs in as the user. IBM's 2025 Cost of a Data Breach Report notes that attackers increasingly rely on stolen credentials rather than exploiting infrastructure directly, a path zero-knowledge architecture doesn't cover. It's a reason to pair the architecture with MFA.

What zero-knowledge protects, and what it doesn't

Zero-knowledge is powerful, but it isn't magic. It defends the storage layer, not the endpoint, and understanding that boundary is what separates an informed buyer from someone repeating a vendor's tagline.

Protects against:

Server breaches. An attacker who dumps the database gets encrypted blobs, nothing more.
Insider access. Database administrators, backup operators, and support staff can't read plaintext, because none of them hold the client-side keys. This is what enforces separation of duties: the person who maintains the server doesn't automatically get to read the passwords stored inside it.
Subpoenas and legal orders. Whoever operates the infrastructure has nothing readable to hand over, since the decryption keys never leave the client.
Database leaks or stolen backups. Exposed records are ciphertext, useless without the client-side keys.

Does not protect against:

Phishing. If you hand your master password to an attacker, the architecture can't stop them.
Public sharing of decrypted data. Once you've decrypted something and pasted it somewhere insecure, encryption is no longer the relevant control.
Metadata leakage. The server typically knows when you accessed a vault, even if it doesn't know what you accessed.

Data security is usually described across three states: at rest, in transit, and in use. Zero-knowledge architecture is fundamentally about at rest: the server stores ciphertext it cannot decrypt, regardless of how it's accessed.

In transit, protection comes from TLS, a separate control. What zero-knowledge adds here is a side effect, not a substitute: data leaves the client already encrypted, so even a TLS failure wouldn't expose plaintext.

In use, when the vault is unlocked and a record gets decrypted, that decryption happens only inside the authenticated user's own client, for that one user. The server never receives or observes the plaintext at any point in that process.

What zero-knowledge means in a self-hosted environment

Self-hosting and zero-knowledge are independent properties. Self-hosting controls where the infrastructure lives. Zero-knowledge controls whether whoever operates that infrastructure can read the data.

In a self-hosted deployment, the entire chain, server, database, and encrypted keys, sits on the company's own hardware, with no outbound connection. What changes when that setup combines with zero-knowledge:

No external party in the loop. There's no vendor infrastructure, no vendor staff, and no outbound traffic carrying data or keys off-premises. Everything the encryption chain touches stays inside the company's network.
Residency and encryption become separate answers. Self-hosting settles where the data physically sits. Zero-knowledge settles who can read it even there. Together, they narrow the trust boundary down to the client device, inside infrastructure the company already controls end to end.
The cost shifts, it doesn't disappear. Patching, backups, and uptime move from vendor to internal IT. That's an operational trade-off, not a security one, and it belongs in the TCO conversation.

For regulated industries, this distinction maps directly onto compliance questions around data residency.

Reinforcing zero-knowledge in practice

Zero-knowledge encryption protects data, but it doesn't cover authentication habits or network exposure. Pairing it with MFA, master password hygiene, organizational controls, and air-gapped deployment closes the remaining gaps.

Security foundation:

Multi-factor authentication (MFA). An attacker who phishes the master password still needs the second factor to unlock the vault.
Master password hygiene. PBKDF2's iteration count slows brute-forcing, but it can't fix a weak or reused password. Length and uniqueness still matter more than the KDF around them.
Organizational controls. Role-based access, group permissions synced from AD/LDAP, and a full audit log limit how much damage one compromised account can do.

Air-gapped deployment: Running a self-hosted password manager with no outbound connection removes remote exploitation, cloud supply-chain compromise, and network interception as attack vectors entirely.

How to verify a zero-knowledge claim

Verifying a zero-knowledge claim without reading source code comes down to checking five things a legitimate vendor will readily document: a technical whitepaper, proof of client-side key generation, independent audits, an honest recovery flow, and open cryptography. Vague marketing pages that skip these details are a signal, not proof, of a problem.

Zero-knowledge verification checklist (5 points):

Confirm client-side encryption. Check whether encryption happens before data leaves the browser or app. If keys are generated on the server, it isn't zero-knowledge, regardless of what the marketing says.
Look for independent validation. Third-party penetration tests and certifications such as ISO/IEC 27001 or SOC 2 Type II provide external evidence, not self-reported claims.
Examine the recovery flow. True zero-knowledge means no "password reset" in the traditional sense. If support can reset your access, they hold a key somewhere. Legitimate recovery relies on a pre-generated recovery key that only the user stores.
Favor auditable cryptography. You don't need to read every line, but publicly documented algorithms and parameters is a meaningful trust signal.

Passwork's own documentation is a working example of what this checklist should turn up: an ISO/IEC 27001 certification, a HackerOne program for independent security testing, and a publicly documented cryptographic specification listing every algorithm and parameter used, and auditable source code that customers can review directly to verify the implementation matches the documentation.

The bottom line

Zero-knowledge encryption comes down to one design decision: the server stores only what it structurally cannot read. Everything else, the PBKDF2 iterations, the RSA key exchange, the two-level encryption, exists to enforce that one guarantee at every step of the chain.

For an enterprise team, this is about shrinking the blast radius of a breach. A stolen database, a compromised backup, a support agent with too much access: none of it matters if what leaks is ciphertext nobody can use.

FAQ

What's the difference between zero-knowledge and end-to-end encryption?

End-to-end encryption (E2EE) protects communication between two specific parties: only sender and recipient hold the keys, not any intermediary. Zero-knowledge describes a server's storage architecture: the provider structurally cannot decrypt what it stores, regardless of context. The two concepts overlap often, rather than sit opposed. A password manager can be zero-knowledge without any "two parties" exchanging messages at all.

What's the difference between zero trust and zero-knowledge?

Zero trust is a network security model: no user or device is trusted by default, every request gets verified regardless of origin. Zero-knowledge is a cryptographic property: the server structurally cannot read stored data. Zero trust governs access decisions; zero-knowledge governs what an attacker gets even after access is granted. The two work well together but solve different problems.

Can I recover my data if I forget my master password?

In a true zero-knowledge system, no. Not even a system admin can reset your password, because the decryption key was never available to reset. Some products offer recovery through a pre-generated recovery key stored separately by the user. Lose both the master password and the recovery key, and the data is cryptographically unreachable.

How do I verify a zero-knowledge claim without reading the source code?

Request the technical whitepaper and check it specifies the KDF, iteration counts, and key hierarchy. Confirm encryption happens client-side before transmission. Look for independent audits or certifications like ISO 27001. A vendor unwilling to provide any of this is the actual red flag, not the absence of open-source code.

Does zero-knowledge encryption work with SSO or SAML login?

SSO confirms who you are; it doesn't replace the master password used to derive client-side encryption keys. A zero-knowledge system paired with SAML SSO still requires that separate secret, because the identity provider was never given the decryption keys in the first place.