Field guide: zero-knowledge vs server-side encryption for regulated workloads

“End-to-end encrypted” is a phrase that appears in the marketing materials of almost every file-transfer vendor, and it means different things in almost every context it appears in. The more consequential distinction for regulated workloads isn’t whether encryption is present — it almost always is — it’s where the keys live and who can access them. Two architectures dominate: zero-knowledge encryption, where the vendor never holds the plaintext keys, and server-side encryption, where the vendor manages keys on the customer’s behalf. Both can be correct; both can be wrong. The difference is in the operational consequences.

Definitions

Server-side encryption means the vendor’s infrastructure encrypts and decrypts data using keys that the vendor generates, stores, and manages. The data is encrypted at rest and in transit. From the customer’s perspective, this is transparent — they don’t manage keys, don’t need to provision key material, and don’t risk losing access through key loss. The vendor controls the encryption, which means the vendor could decrypt the data if compelled to or if their systems were compromised.

Most enterprise SaaS file-transfer products default to server-side encryption. It’s operationally simple and covers the baseline requirement that data is encrypted at rest and in transit, which is what most compliance frameworks minimally require.

Zero-knowledge encryption (sometimes called client-side encryption or customer-managed keys, though these terms are not identical) means the keys never leave the customer’s control. Data is encrypted before it reaches the vendor’s infrastructure, or the vendor’s infrastructure uses key material that only the customer can provide. The vendor sees ciphertext. They cannot decrypt it regardless of legal process, internal policy, or security compromise.

True zero-knowledge requires that key generation, storage, and management happen outside the vendor’s environment. In practice, implementations vary: some vendors call “customer-managed keys stored in a vendor-adjacent HSM” zero-knowledge, which it isn’t. Genuine zero-knowledge means the vendor is architecturally incapable of accessing plaintext, not merely contractually prohibited.

Envelope encryption is the pattern underlying most server-side implementations worth using. Each file (or each transfer) is encrypted with a unique data encryption key (DEK) generated for that object. The DEK is itself encrypted with a key-encryption key (KEK) that lives in a key management service. The ciphertext bundle stored in object storage contains the encrypted DEK alongside the encrypted content. This means a single KEK compromise doesn’t automatically expose all data — only the files whose DEKs were wrapped by that KEK. In server-side implementations, the vendor holds the KEK. In customer-managed-key implementations, the customer holds the KEK (typically in AWS KMS, Azure Key Vault, or a similar service), and the vendor is granted temporary decryption permission to unwrap DEKs when serving authorized requests.

AES-GCM (AES in Galois/Counter Mode) is the dominant cipher for at-rest encryption in both architectures. It provides authenticated encryption — the receiver can verify the ciphertext hasn’t been tampered with — which satisfies the integrity requirements in HIPAA §164.312(c) and NIST 800-171 3.13 without separate MAC computation.

Trade-offs: key management, support, and indexing

The operational differences between these architectures are not abstract.

Key management overhead. Server-side encryption requires no key management from the customer. Zero-knowledge or customer-managed-key implementations require the customer to provision a KMS, configure key policies, grant the vendor appropriate access, monitor for key rotation, and handle key revocation. For organizations with mature cloud key management operations, this overhead is modest. For organizations without that operational muscle, it’s a recurring burden.

Support access. Server-side encryption allows the vendor’s support team to inspect file metadata, diagnose delivery failures, and troubleshoot transfer problems by examining actual content when necessary. Zero-knowledge architectures eliminate this. If a zero-knowledge customer has a delivery problem, the vendor’s ability to diagnose it is limited to metadata and log records — they cannot examine the file content. This matters less than it used to (log-based diagnostics are highly capable), but it remains a real operational difference.

Search and indexing. Server-side encryption allows the vendor to build search indexes over file content — full-text search, content classification, DLP scanning. Zero-knowledge architectures make content-aware features very difficult or impossible without client-side processing. If your use case requires that the vendor scan file content for sensitive data patterns, server-side encryption is generally required. If scanning is done before files leave the customer’s environment, zero-knowledge is compatible.

Key revocation and data destruction. Zero-knowledge and customer-managed-key architectures provide a powerful destruction primitive: revoke or destroy the KEK, and all associated data becomes cryptographically inaccessible without recovering the encrypted ciphertext blobs. This is valuable for data portability and right-to-erasure scenarios where you need provable data destruction without depending on the vendor to delete storage objects. Server-side encryption can support data destruction, but it depends on the vendor executing the deletion.

Audit and compliance posture. For HIPAA, both architectures can satisfy technical safeguard requirements if implemented correctly. For NIST 800-171 control 3.13.10 (establish and manage cryptographic keys for required cryptography), customer-managed keys provide a stronger story when the assessor is evaluating who controls the cryptographic root of trust. For FedRAMP, the authorization package will specify key management requirements; customer-managed keys are frequently required for high-impact systems.

Where each fits regulated workloads

Server-side encryption fits best when:

• The primary concern is encryption at rest and in transit with minimal operational overhead
• The use case requires content inspection, DLP, or search features
• The compliance framework requires encryption but doesn’t specify customer key custody
• The organization doesn’t have mature cloud KMS operations
• Support escalations involving file-content inspection are common

Zero-knowledge or customer-managed-key encryption fits best when:

• The compliance framework or contractual requirements specify that the vendor cannot access plaintext content
• The use case involves particularly sensitive data where vendor-side access is a business risk independent of compliance (e.g., M&A documents, executive communications, legal privileged material)
• The organization has the operational capability to manage a KMS
• Data destruction guarantees with third-party verifiability are required
• The organization is pursuing FedRAMP High authorization where key custody requirements are specified

There is a middle path that covers most regulated enterprise use cases: server-side encryption with customer-managed keys. In this model, the vendor’s infrastructure handles encryption operations, but the KEK lives in a KMS that the customer controls. The vendor cannot access plaintext without the customer’s KMS granting access; the customer can audit all KMS calls; and the customer can revoke access by rotating or revoking the KEK. Search and content features work normally. Support access to metadata is retained. Most of the operational convenience of server-side encryption is preserved, with meaningful improvement in the key-custody story.

Decision matrix

Requirement	Server-side	Customer-managed KEK	True zero-knowledge
Minimal operational overhead	Best	Moderate	Most complex
Content search / DLP	Yes	Yes	No
Vendor cannot access plaintext	No	Effectively yes	Yes
Provable data destruction	Vendor-dependent	Yes (revoke KEK)	Yes
FedRAMP High key custody	Review requirement	Typically satisfies	Satisfies
Support diagnostics	Full	Metadata only	Metadata only
HIPAA baseline	Yes	Yes	Yes

For most mid-market regulated organizations — healthcare, financial services, professional services — the customer-managed KEK model hits the right point on the curve. It provides a defensible key-custody story for auditors, supports content features, and doesn’t require building a custom KMS operation. True zero-knowledge is the right answer for a narrower set of use cases where the operational cost is justified by the sensitivity profile or contractual requirements.

The single most important question to ask a vendor: “Where are the key-encryption keys for my data, and can you show me the key management policy that governs them?” The answer to that question tells you more about the actual encryption posture than any marketing copy about “end-to-end encryption.”