Client-Side vs “Zero-Access” Encryption: What Buyers Should Ask

If you’re buying a cloud product that promises privacy and security, you’ll quickly run into two phrases that sound similar but can mean different things in practice: client-side encryption and “zero-access” (often called “zero-knowledge”) encryption. Vendors may use these terms loosely, sometimes interchangeably, yet the choices behind them have deep implications for your threat model, key custody, compliance posture, and operational usability.

This guide gives you a pragmatic, buyer-oriented way to evaluate client-side encryption vs zero-access encryption, with a structured security model comparison, plain-English explanations of key custody patterns (BYOK, HYOK, DKE, EKM), a realistic threat model (what can actually go wrong), and a field-tested checklist of vendor claims to verify. Along the way, we’ll call out the exact questions you should put into your RFP or security questionnaire.

Quick definitions (grounded, not marketing)

• Client-side encryption (CSE) means data is encrypted on the client before it’s uploaded or transmitted. In many enterprise systems this can be implemented so that even the cloud provider can’t decrypt content, if the keys never leave customer control. Major vendors like Google describe Workspace CSE as a way for organizations to keep data private from Google and third parties, using external key services you control.
• End-to-end encryption (E2EE) is a specific case where only the endpoints (sender/recipient devices) hold the keys, not the servers in the middle. NIST defines E2EE as encryption where data remains encrypted between ends even as it traverses networks (routing/meta info may still be visible). In messaging, that typically means the provider cannot decrypt content on their servers.
• “Zero-access / zero-knowledge” encryption is a vendor promise that the provider cannot decrypt customer content because they do not have access to the keys. Some vendors use this term primarily for encryption at rest where vault/drive/mail content is stored in a way that the provider can’t read it. Proton’s description of zero-access makes this explicit: encryption so that only the user can access data, even if servers are breached.
• Server-side encryption (SSE) encrypts data after it reaches the cloud, with keys held by the provider (or by your KMS within the provider). It protects against disk theft and some internal boundary risks, but if the provider controls keys, they can technically decrypt. AWS’s documentation contrasts client-side and server-side encryption clearly.

These definitions overlap in practice. Client-side encryption can deliver a zero-access outcome (provider can’t decrypt) if the keys are truly customer-held and never shared with the provider. But CSE can also be implemented with external key requests that the provider can invoke; the provider still doesn’t hold the keys, yet could process data if your key service authorizes a request, an important nuance for governance and legal process.

Why the distinction matters

1. Legal exposure and compelled access: Where keys live determines how a provider can respond to lawful requests. The U.S. CLOUD Act enables mechanisms for providers to disclose data to law enforcement (including from overseas data centers) under specific conditions. If the provider holds decryption keys, they can technically comply by producing plaintext; if keys are exclusively customer-held, the provider cannot decrypt (though metadata may still be produced).
2. Insider and platform risk: If keys are accessible to a provider’s operations staff or services, you rely on their internal controls against insider abuse and misconfigurations. Insider threat is a well-studied risk in cloud contexts.
3. Feature trade-offs: Client-side/E2EE designs may limit server-side features (e.g., web search, server-side scanning, link-based sharing), unless the vendor builds special privacy-preserving mechanisms. That’s not a flaw; it’s a deliberate trade, security over convenience. Major platforms document which features work differently when CSE is enabled.
4. Metadata exposure: Even with true E2EE/zero-access, metadata (who, when, size, headers) often remains visible to the service for routing/billing/abuse prevention. That metadata can be sensitive on its own.

Security model comparison: Client-side vs “Zero-access”

1) Who has the keys? (Key custody)

• Provider-managed keys (SSE default): easiest operationally; provider can decrypt.
• Customer-managed keys in cloud KMS (BYOK/CMEK): keys are under your tenancy but still within provider’s boundary; provider services may use them via IAM policy.
• External key management (EKM) / Hold-Your-Own-Key (HYOK): keys live in your HSM or a third-party KMS, outside the provider; the provider must ask your service to use keys and can be blocked/revoked.
• Double-Key Encryption (DKE): content is encrypted with two keys, one you hold, one with the provider; access requires both, so unilateral provider access is impossible.

Google Cloud’s External Key Manager keeps key material outside Google; Microsoft’s Double Key Encryption explicitly requires both keys; Salesforce BYOK brings your own key material into their encryption workflow. These are concrete patterns you can evaluate. Buyer takeaway: “Zero-access” promises only hold if keys are not available to the provider in any way that lets them decrypt without you. If your design uses EKM/HYOK or DKE, and your policies actually deny unsolicited key usage, you’re much closer to true zero-access in practice.

2) What’s encrypted where?

• At rest only (provider side): protects against disk theft/snapshot leaks; provider can still see plaintext in app memory.
• In transit (TLS): protects against network interception; still not E2EE by itself. NIST recommends forward-secret ciphers for TLS.
• End-to-end (on the client): content decrypted only on endpoints; servers never see plaintext. NIST’s glossary captures this model at a high level.

3) What about metadata?

Most systems leave some metadata unencrypted to make the service usable; a handful attempt to minimize or encrypt more metadata but this is rare and complex. As a buyer, ask exactly which metadata fields remain visible.

4) What happens under legal compulsion?

With provider-held keys, providers can be compelled to produce plaintext. With CSE/HYOK/DKE, the provider cannot decrypt without your cooperation (or compromise of your key service). The DOJ’s CLOUD Act materials outline the cross-border access mechanisms and safeguards, an important legal backdrop for your policy.

Key custody patterns, decoded

BYOK / CMEK (Bring/Customer-Managed Key): You supply a key (often wrapped) to the provider’s KMS. Access to data is still mediated by the provider’s services, but you gain lifecycle control (rotation, revocation). It’s a step up from provider-managed keys, though still inside the provider’s boundary. (See Microsoft and Salesforce documentation for specifics.)

HYOK (Hold Your Own Key) / EKM (External Key Manager): Keys reside outside the provider; cryptographic operations are performed only with your external service’s consent. Google’s EKM keeps key material external and never exposed to Google. This strengthens separation of duties and enables default-deny for unsolicited access.

DKE (Double Key Encryption): Data is encrypted with two independent keys (one you hold, one the provider holds). Both must be available to decrypt, which makes unilateral provider access infeasible. Microsoft documents DKE for highly sensitive Microsoft 365 content.

HSM & Validation: If a vendor claims “HSM-backed keys” or “FIPS 140-3 validated modules,” verify it. FIPS 140-3 validation is published via NIST’s CMVP project listings.

Threat model: what you’re protecting against

1. External breaches of provider infrastructure
   Server-side encryption helps, but if plaintext transits the app layer, an attacker with sufficient access can still read it. Client-side/E2EE designs shrink this attack surface by ensuring servers never see plaintext. (NIST’s E2EE definition underscores that only endpoints hold decrypting capability.)
2. Insider threats and misconfiguration
   Most incidents are not “nation-state backdoors” but simple permission mistakes and admin tooling abuses. Externalizing keys (EKM/HYOK) and enforcing strong approvals/auditing for key usage materially reduce insider risk.
3. Legal and regulatory compulsion
   The CLOUD Act and similar frameworks establish lawful access pathways. Your best mitigation is architectural: ensure the provider cannot decrypt, and that your own key service requires policy-guarded approvals, ideally with tamper-evident logs.
4. Metadata intelligence
   Even with E2EE, traffic/usage patterns may remain visible. Treat metadata as sensitive; prefer designs that minimize or protect it where possible.
5. Crypto hygiene and key lifecycle
   Follow NIST SP 800-57 guidance on key generation, rotation, compromise-recovery planning, and life-cycle controls. Ask vendors how they align to it.
6. Protocol choices and forward secrecy
   For transport layers, insist on PFS (ephemeral Diffie-Hellman) so past sessions aren’t exposed if a long-term key is compromised. NIST’s TLS guidance is explicit here.
7. Quantum-resilience roadmap
   Ask about migration plans to NIST’s post-quantum standards. Even if not urgent for your use case, regulators and critical-infra sectors are already preparing.

Vendor claims: how to separate substance from slogans

Marketing often blurs lines. A high-profile lesson: Zoom settled with the FTC for misleading “end-to-end encryption” claims in 2020, the platform’s implementation at the time did not match the phrase’s common meaning. As a buyer, treat bold encryption claims as hypotheses to verify.

Verification tactics:

• Demand precise definitions in writing: Does “end-to-end” mean the provider never holds content decryption keys? For which features?

• Ask for architecture diagrams showing where encryption happens and where keys live.

• Check documentation against standards (NIST references for terms and key management).

• Look for externalized keys (EKM/HYOK/DKE) and clear admin controls.

• Confirm FIPS 140-3 validation where HSMs are claimed.

• Review feature matrices for CSE modes (what breaks/changes). Google’s Workspace CSE docs are a good example of the transparency you want.

Practical comparison table

Buyer’s checklist: the exact questions to ask

Copy these into your RFP or security questionnaire:

A. Security model & scope

1. Define terms: How do you define “client-side encryption,” “end-to-end encryption,” and “zero-access” in your product? Which data types and features are covered by each? Please include current documentation links. (Compare to NIST’s E2EE definition.)
2. Encryption boundaries: Where exactly does encryption occur (client, edge, server)? Provide a diagram.

B. Key custody & control

1. Key location: Are content decryption keys ever present in the provider’s infrastructure? If so, when and for how long?

2. External keys: Do you support EKM/HYOK so keys remain outside the provider boundary? List supported partners or APIs. (e.g., Google Cloud EKM / Workspace CSE).

3. DKE option: Do you support Double Key Encryption or equivalent split-knowledge schemes? Under what constraints? (See Microsoft DKE.)

4. HSM & validation: Are keys stored/used in FIPS 140-3 validated modules? Provide CMVP certificate numbers.

C. Access governance & audit

1. Key-use policy enforcement: How do we enforce default-deny for key usage and require explicit approvals?

2. Auditing: Will we receive tamper-evident logs of all key operations, including attempted/denied uses?

3. Revocation: Can we revoke keys to immediately halt provider access, even for running workloads?

D. Metadata & privacy

1. Metadata inventory: Exactly which metadata fields remain visible to your service (and to third parties) under CSE or zero-access modes? (Acknowledge that some metadata is typically visible.)

2. Minimization: What techniques do you use to minimize metadata retention?

E. Legal process & cross-border access

1. Lawful access posture: If compelled under the CLOUD Act or similar, can the provider decrypt our content? If not, what would be produced? Who controls the keys and under what legal jurisdiction? Provide your transparency policy.

F. Reliability, recovery & operations

1. Key loss scenarios: What happens if we lose access to our keys? Detail recovery mechanisms and your alignment with NIST SP 800-57 lifecycle guidance.

2. Feature impacts: List all features that change or are unavailable in CSE/zero-access modes (search, link sharing, malware scanning, collaboration). Provide docs.

G. Roadmap & cryptographic agility

1. PFS/TLS posture: Confirm PFS cipher suites for all transport paths; reference your TLS configuration policy (NIST 800-52r2 guidance).

2. Post-quantum plan: Share your migration roadmap to NIST-standardized PQC.

Real-world examples that clarify claims

• Google Workspace CSE: Encrypts on the client; keys are controlled by an external key service you choose or build. Google states its servers and third parties can’t decrypt CSE content. This is client-side and can achieve a zero-access posture depending on your key policy.

• Google Cloud EKM: Key material remains outside Google; KMS references an external key and must coordinate with your EKM for cryptographic operations, useful for separation of duties and revocation.

• Microsoft Double Key Encryption: Requires two keys (one customer-controlled) so Microsoft alone cannot decrypt protected content. Useful for “no unilateral decrypt” requirements.

• Salesforce Shield BYOK: Lets customers bring their own key material for platform encryption, stronger control than default SSE, though evaluate whether keys sit inside or outside the provider’s boundary for your risk appetite.

These illustrate that “client-side” is a mechanism; “zero-access” is an outcome you must verify, mainly by looking at key custody and policy enforcement.

Implementation pitfalls (and how to avoid them)

1. Assuming “encrypted” equals “zero-access.”
   If the provider controls the KMS or can silently request your key, content may be decryptable. Validate where keys live and who authorizes key usage (ideally you, via EKM/HYOK or DKE).

2. Ignoring metadata.
   Even perfect E2EE leaves traces in metadata. Inventory and minimize it; ask for retention schedules and whether any metadata can be protected or pseudonymized. [

3. Overlooking recovery.
   True zero-access can mean no recovery if keys are lost. NIST urges documented compromise-recovery plans: build split-knowledge (e.g., threshold schemes) and escrow processes you trust.

4. Trusting labels without evidence.
   The Zoom/FTC case shows why you verify claims, request third-party audits, formal threat models, and proofs (e.g., open architecture docs, pen test summaries).

5. Weak transport hygiene.
   CSE doesn’t excuse poor TLS; insist on modern TLS with perfect forward secrecy to limit damage if a long-term key leaks.

6. Single points of failure in key services.
   Distribute trust with threshold cryptography (multi-party control) so no single admin or system can decrypt alone; NIST is standardizing threshold approaches.

How to choose (decision framework)

1. Define your “cannot decrypt” requirement.
   If policy, regulation, or customer trust demands that the provider must not be able to read content, prefer client-side encryption with HYOK/EKM or DKE, configured so the provider cannot use keys without your explicit approval. That’s what most buyers mean by “zero-access.”

2. Map required features vs. security.
   If you need server-side search, link sharing to “anyone with the link,” malware scanning, or real-time collaboration, expect constraints under strict CSE/zero-access modes. Some vendors document exactly what changes in CSE, treat those docs as your source of truth.

3. Decide on key custody.

   • Good: CMEK/BYOK (provider KMS, your keys).

   • Better: EKM/HYOK (external KMS/HSM).

   • Best for “no unilateral decrypt”: DKE or schemes where decrypt requires both your key and provider key, and your key service enforces approvals.

4. Lock in governance.
   Require auditable approvals for every decrypt/sign operation; integrate with your change-management process; automate revocation paths for incident response.

5. Plan for the future.
   Ensure crypto agility (algorithm agility, PQC roadmap) and prepare to rotate keys or transition algorithms without service disruption.

The exact language to request in contracts and security addenda

• “Provider acknowledges that in Client-Side Encryption mode, content decryption keys are never available within the provider’s infrastructure, and that cryptographic operations require authorization from the Customer-controlled external key service (EKM/HYOK) or dual-control via Double Key Encryption.”

• “Provider will not build or request any mechanism to circumvent key-use policy and will maintain tamper-evident logs for all key-use requests, furnished to Customer on demand.”

• “Provider will disclose a list of metadata fields retained under CSE/zero-access modes, including retention periods and sharing practices.”

• “Provider confirms transport security conforms to NIST SP 800-52r2 recommendations (e.g., PFS with ECDHE or DHE).”

• “Provider confirms cryptographic modules used for key storage/operations are FIPS 140-3 validated, with CMVP certificate references.”

FAQ: common buyer questions

Q1: Is “zero-access” just marketing for client-side encryption?
Not exactly. Client-side describes where encryption happens. Zero-access describes an outcome (provider can’t decrypt). You can achieve zero-access with properly implemented CSE + externalized keys (EKM/HYOK) or DKE, but you must verify key custody and policy enforcement.

Q2: Can the provider still be forced to hand over data under the CLOUD Act?
Providers may still be compelled to disclose what they have. With zero-access architectures they can hand over ciphertext and metadata, but not plaintext, because they lack the keys. Compulsion could shift to you (your key service), depending on jurisdiction.

Q3: What about metadata, can it be encrypted too?
Some systems minimize or protect metadata, but most keep some metadata visible. Treat it as sensitive and ask vendors exactly which fields remain exposed.

Q4: Will CSE break collaboration features?
Often, yes or they’ll change. Vendors like Google document what works under CSE; review those specifics before rollout.

Q5: How do we avoid single-admin risk on our side?
Use threshold cryptography or split-knowledge processes so no single person can authorize key use; NIST is actively standardizing threshold approaches.

Bottom line

• If your requirement is “the provider must not be able to decrypt our content,” you’re looking for client-side encryption that results in a true zero-access posture. That typically means externalized keys (EKM/HYOK) or DKE, backed by strong key-use policy, auditable approvals, and revocation.

• Tie your evaluation to standards and evidence NIST definitions, SP 800-57 key management practices, TLS with PFS, FIPS 140-3 validation, rather than slogans.

• Be realistic about metadata and feature trade-offs, and ensure your legal/compliance teams understand how CLOUD Act and similar frameworks interact with your chosen key posture.

Build your RFP around the questions in this guide, and you’ll separate solid, implementable security from the marketing gloss.