“We encrypt everything” is not a decision. Who holds the keys is. For document storage, the practical split is client-side encryption versus server-side encryption—and the features each model unlocks or forbids.
This article is written for security, legal, and procurement readers who need to map vendor claims to a threat model—not for cryptography contests.
Server-side encryption (SSE) in plain language
With server-side encryption, your app or object store encrypts objects before writing them to disk. TLS protects data in transit. Providers may offer customer-managed keys (CMEK) or key vaults. Those options improve control—but the service still typically needs access to plaintext or decryptable material to power preview, full-text search, antivirus, and collaborative editing.
SSE is the right default for productivity suites. It is not the same as “the vendor cannot read this file.”
Client-side encryption (CSE) in plain language
With client-side encryption, the browser or device encrypts the document before upload. The server receives ciphertext. Decryption requires a secret that never arrives at the server in usable form—often a master password stretched with PBKDF2 or a similar KDF.
Compliance Locker is built on this model: AES-256-GCM in the browser, sealed uploads, and vault unlock that stays local. That is why we can say—under normal operation—we store sealed blobs rather than readable document contents. Details live on our Security page.
Side-by-side comparison
| Dimension | Client-side | Server-side |
|---|---|---|
| Where encryption runs | Browser / device | Provider infrastructure |
| Operator plaintext access | Designed to be unavailable | Often required for features |
| Search / preview | Limited unless ciphertext-aware | Rich, server-powered |
| Password loss | High risk of data loss | Vendor recovery paths common |
| Share key path | Often client-delivered (e.g. URL hash) | Server ACL after auth |
| Best for | Sealed sensitive packets | Day-to-day collaboration |
Share links: a telling difference
In many zero-knowledge designs, a share creates a server token while the file key rides in the URL hash fragment—which browsers do not send to servers in normal HTTP requests. That pattern keeps the decryption secret off the operator’s request logs. Classic cloud shares often grant access via server-side ACLs after authentication.
Neither model is “secure by slogan.” Both need expiry, least privilege, and human process. But the key delivery path changes what a breach of the storage operator can expose. For playbooks, see sharing without shared passwords.
Common misconceptions
“TLS is enough”
TLS protects the pipe. It does not decide whether the storage service can open the object after arrival.
“AES-256 means zero-knowledge”
Algorithm choice matters; key custody matters more. AES-256 with operator-held keys is still operator-decryptable.
“If we have SSO, files are safe”
SSO gates who can open an account session. It is not a substitute for client-held document keys unless the product explicitly designs it that way—and you understand the recovery implications.
How to choose for your team
Prefer client-side when
- Vendor-read access is an explicit risk in your threat model
- Documents are “final sealed packets,” not live collaborative drafts
- You need cryptographic evidence of access events
Prefer server-side (or hybrid) when
- You need full-text search, OCR, and rich preview at scale
- Co-authoring is the primary job
- IT recovery workflows require vendor-assisted unlock
A procurement checklist you can paste into RFPs
- Describe where encryption and key derivation execute
- State whether support can decrypt customer files
- Explain share-link key delivery
- List visible metadata fields
- Document recovery / escrow options and who controls them
- Separate account MFA from document decryption secrets in the answer
FAQ
Is server-side encryption insecure?
No. Server-side encryption is standard and valuable against disk theft and many infrastructure risks. It does not, by itself, prevent the service operator from accessing plaintext when providing features like search or preview.
Can I use both models?
Yes. Many organizations keep collaborative content in server-side encrypted drives and store sealed packets in a client-side encrypted vault.
Where does key management sit in client-side encryption?
Keys are derived or unwrapped on the client from a secret the user controls (often a master password). The server stores ciphertext and encrypted key blobs it cannot unwrap without that secret.
Does CMEK make cloud storage zero-knowledge?
Customer-managed keys improve control and audit of key use, but the application often still decrypts content to deliver features. CMEK is not the same as client-side encryption before upload.
What should RFPs ask for?
Ask where encryption runs, who can unwrap keys, how share keys are delivered, what metadata is visible, and what recovery implies about escrow—not only whether AES-256 is used.
Related: Zero-knowledge for business documents, product comparisons.