Client-Side vs Server-Side Encryption: Who Holds the Keys

Server-side encryption and client-side encryption both turn stored data into ciphertext, but they answer different questions: server-side encryption protects data from people who steal the disks, while client-side encryption protects it from the service that stores it. The deciding factor is who can use the key, and when. This guide compares the two by threat model (provider insider, compromised application, stolen media), key custody, the processing and search features you give up, the risk of losing keys, and what each lets you claim to auditors and regulators. Cloud examples come from Amazon Web Services, Google and Microsoft, listed alphabetically; the order is not a ranking. It is written for security architects, data protection leads and engineers choosing an encryption model for cloud storage, SaaS and application data. For the wider picture of data states, see the Encryption at Rest vs In Transit vs In Use; for building encryption into your own code, see the Application Layer Encryption Guide.

Key takeaways

Server-side encryption trusts the service. The provider encrypts on write and decrypts on read for any authorised request, so anyone who can make an authorised request, including a compromised application identity, gets plaintext.
Client-side encryption removes the service from the trust boundary. Data is encrypted before it leaves your environment, so the storage service only ever holds ciphertext and cannot decrypt it without your key.
Customer-managed keys sit in between. SSE with a customer managed key in a cloud KMS gives you control and audit of key use, but the service still decrypts on your behalf.
Client-side encryption costs features. Server-side search, indexing, malware scanning, DLP, previews and co-authoring generally stop working on content the service cannot read.
Key loss is permanent. With client-side encryption there is no provider recovery path: lose the key, or the metadata that wraps it, and the data is gone.

The short answer

Use server-side encryption everywhere as the baseline. It is on by default in the major clouds, costs little or nothing, and protects against lost and stolen media and many storage-layer exposures.
Add customer managed keys where you need control of key rotation, deletion and access policy, a key usage audit trail, or crypto-shredding by disabling a key.
Use client-side encryption for the small set of data where the provider itself, or a provider's legal exposure, is in your threat model, or where a regulation or contract requires that keys and plaintext never leave your control. Accept the feature and operational cost knowingly.

Side-by-side comparison

Attribute	Server-side, provider-managed key	Server-side, customer managed key (KMS)	Client-side encryption
Where encryption happens	In the service, on write	In the service, using a key in your KMS	In your application or client, before upload
Who can decrypt	The service, for any authorised request	The service, when the KMS key policy allows it	Only holders of your key
What the provider stores	Ciphertext plus keys it controls	Ciphertext; key in KMS under your policy	Ciphertext only, plus a wrapped data key in metadata
Stolen disk or media	Protected	Protected	Protected
Storage misconfiguration, such as public bucket	Not protected: the service decrypts for permitted readers	Partly: readers also need KMS permission	Protected: readers get ciphertext
Compromised application identity	Not protected	Not protected if the identity has KMS decrypt	Not protected if the application holds or can use the key
Provider insider or legal compulsion of the provider	Relies on provider controls	Relies on provider controls and KMS separation	Strongest: provider has no key
Server-side search, indexing, scanning	Full	Full	Generally lost for encrypted content
Key loss impact	Provider handles	Deleting the key makes data unrecoverable	Losing the key or wrapped key makes data unrecoverable
Operational effort	Minimal	Moderate: key policy, rotation, monitoring	High: SDKs, key distribution, metadata, recovery

Threat model per option

Encryption choices are only as good as the threat they are chosen for. Work through these three scenarios for each data set.

Stolen disk or decommissioned media

All three models defeat this. Google states that its default encryption means an attacker who obtains storage devices cannot read the data without the keys, and that it uses AES-256 at the storage layer with a hierarchy of data encryption keys per chunk wrapped by key encryption keys. Amazon S3 applies SSE-S3 to every new object upload automatically, and has done since 5 January 2023. If physical media is your only concern, the default is enough and client-side encryption adds cost without adding protection.

Compromised application or cloud identity

This is the threat that most often matters, and the one encryption at the storage layer does least about. An attacker with valid credentials for a role that can read a bucket (ATT&CK T1078.004 Cloud Accounts, followed by T1530 Data from Cloud Storage) receives plaintext from a server-side encrypted store, because the service decrypts for any authorised request. A customer managed key helps only if the stolen identity lacks KMS decrypt permission, which is why separating "can read the object" from "can use the key" is one of the most valuable controls in this space. Client-side encryption helps only if the compromised component does not hold the key. If the application that encrypts also decrypts, and the attacker controls that application, they get plaintext too. See the Cryptographic Key Management Guide for separating key use from data access.

Provider insider, provider compromise or legal compulsion

Server-side encryption with provider-managed keys relies entirely on the provider's internal controls; Google's documentation, for example, states that it owns and manages the keys used in default encryption at rest and that customers cannot view key metadata or control rotation for them. Customer managed keys add a policy and audit layer you control, but the service still decrypts. Client-side encryption is the only model of the three where the provider holds no usable key: AWS describes client-side encrypted objects as not exposed to any third party, including AWS, and Google describes Workspace client-side encryption as encryption that Google servers and third parties cannot decrypt.

Key custody: the real difference

The custody spectrum runs from provider-owned keys, through customer managed keys in a provider KMS, to keys held in an external key manager or HSM, to keys that never leave your clients. The BYOK, HYOK and External Key Management Guide covers the middle of that spectrum in depth. The questions to ask of any model:

Who can call decrypt? With server-side encryption, the service calls decrypt on your behalf. With client-side encryption, only code you run can.
Where does plaintext exist? Server-side: in the provider's service at read time. Client-side: only on your endpoints and servers.
Who logs key use? Provider-managed keys give you no key usage log. A KMS gives you a per-call audit trail. Client-side encryption gives you whatever your key service logs.
Who can destroy the key? Disabling or scheduling deletion of a customer managed key renders data unreadable, which is useful for crypto-shredding and dangerous if done by mistake or by an attacker.

How the major platforms implement each model

Platforms are listed alphabetically. Each describes customer-side settings; confirm current options in the vendor's documentation.

Amazon Web Services

Server-side: Amazon S3 offers SSE-S3 (S3 managed keys, each object encrypted with a unique key, AES-256), SSE-KMS (keys in AWS KMS, customer managed or AWS managed), DSSE-KMS (two independent AES-256 layers, one from a KMS data key and one from an S3 managed key) and SSE-C (you supply the key on each request, S3 performs the encryption). Only one applies to a given object. Changing a bucket's default to SSE-KMS does not re-encrypt existing objects; S3 Batch Operations is the documented route for that. As of the April 2026 update, SSE-C is disabled for new write requests on new general purpose buckets and on existing buckets in accounts that hold no SSE-C encrypted objects, and must be turned on with PutBucketEncryption where an application needs it.

Client-side: the Amazon S3 Encryption Client encrypts and decrypts automatically during PutObject and GetObject, using a unique data key per object and optionally a KMS key as the wrapping key. S3 sees an ordinary object and plays no role in encryption. Client-side and server-side encryption can be combined. See the AWS KMS Security Guide.

Google

Server-side: Google Cloud encrypts all customer content at rest by default with AES-256, using per-chunk data encryption keys wrapped by key encryption keys that are set per service. For customer control, Cloud KMS customer managed encryption keys (CMEK) let you create, rotate, track and delete keys, with audit logging and CMEK organisation policies. See the Cloud KMS and Cloud HSM Guide.

Client-side: Google Workspace client-side encryption (CSE) adds a layer on top of Workspace's default encryption for files and email, using keys from a key service you control and an identity provider for user authentication. Google documents it for Frontline Plus, Enterprise Plus, and Education Standard and Education Plus editions, with admin audit logs and user activity reports for encrypted files, and a documented process to decrypt exports from the Data Export tool or Google Vault. Google's CSE guides list the supported apps and file types. See the Google Workspace Security Guide.

Microsoft

Server-side: Azure Storage service-side encryption is on for every storage account, cannot be turned off, and uses 256-bit AES at no extra cost. Key options are Microsoft-managed keys (the default), customer-managed keys in Azure Key Vault or Key Vault Managed HSM, and customer-provided keys sent with each Blob Storage request; encryption scopes apply separate keys per container or blob. Optional infrastructure encryption adds a second AES-256 layer with a separate Microsoft-managed key. Microsoft recommends service-side encryption for most scenarios. See the Database and Storage Encryption Guide.

Client-side: the Azure Blob Storage client libraries implement envelope encryption: a one-time 32-byte content encryption key encrypts the blob, a key encryption key you manage locally or in Azure Key Vault wraps it, and the wrapped key and metadata are stored with the blob. Use version 2 (AES-GCM); Microsoft recommends against version 1 (AES-CBC) following a vulnerability in its CBC implementation, and documents a migration path of decrypting and re-encrypting v1 data. For Microsoft 365, Purview Double Key Encryption (DKE) protects content with two keys, one held in a DKE service you run and one in Azure, so viewing requires both; Microsoft positions it for a small share of the most sensitive data and documents it as included with Microsoft 365 E5.

Availability: Google Workspace CSE and Microsoft Purview DKE are tied to specific editions as stated above; AWS S3 server-side encryption options are available per bucket, with KMS usage billed separately.

Search, processing and feature limits

Client-side encryption works because the service cannot read the data, and every server-side feature that needs to read it stops working. Microsoft's DKE documentation is a clear worked example: it lists eDiscovery, content search and indexing, co-authoring and AutoSave, Office for the web, DLP, mail flow malware and spam scanning of attachments, and Copilot as unavailable for DKE-protected content. Expect similar trade-offs from any client-side scheme, and check each vendor's list for the apps you use.

Capability	Server-side encryption	Client-side encryption	Mitigation if you need both
Full-text search and indexing	Works	Lost for encrypted content	Encrypt only the sensitive subset; index non-sensitive metadata; consider deterministic or searchable encryption in your own application, accepting leakage
Malware and DLP scanning	Works	Lost in the service	Scan on the endpoint before encryption
eDiscovery and legal hold	Works	Needs your key for review	Document a decrypt-for-review process with legal
AI assistants and analytics	Works, subject to access policy	Cannot process the content	Decide deliberately which data AI tools should not see
Partial updates and range writes	Works	Often restricted (Azure client-side encryption supports whole-blob uploads only)	Design objects for whole-object writes
Database queries on encrypted fields	Works (encryption below the query engine)	Equality only with deterministic encryption; no range queries without specialised schemes	See the Application Layer Encryption Guide

Key loss risk

With server-side encryption under provider-managed keys, key loss is the provider's problem. Every step towards customer custody moves that risk to you.

Deleted or disabled KMS keys: data encrypted under a customer managed key becomes unreadable if the key is deleted. Use deletion waiting periods, alert on disable and schedule-deletion events, and restrict who can perform them.
Lost wrapped keys: client-side schemes store the wrapped data key with the object. Microsoft warns that calling Set Blob Metadata without preserving the encryption metadata loses the content encryption key and IV, leaving the blob undecryptable.
Unavailable key services: if your CSE or DKE key service is down, users cannot open protected content. Treat it as a tier-one service with redundancy and tested recovery.
Escrow and recovery: back up key material under dual control, store backups separately from the data, and test a full restore at least yearly.

The Encryption Key Compromise Playbook covers response when a key is exposed rather than lost.

Compliance claims: what each lets you say

Breach notification: GDPR Article 34(3)(a) removes the duty to tell data subjects about a breach where the controller applied measures, such as encryption, that render the data unintelligible to anyone not authorised to access it. HHS treats electronic PHI as secured under HIPAA breach notification when encryption is consistent with NIST SP 800-111 for data at rest, and only if the decryption key has not been breached; HHS advises keeping keys on a device or at a location separate from the data. Server-side encryption meets the "stolen disk" case, but if the attacker accessed data through an authorised path, the service decrypted it and the encryption does not make it unintelligible to them.
Data residency and sovereignty: client-side encryption and DKE-style models let you show that keys stay within your control or jurisdiction. Microsoft cites regulatory requirements to hold keys within a geographic boundary as a DKE use case.
Audit evidence: customer managed keys produce key usage logs you can hand to auditors; provider-managed keys do not.
Careful wording: "encrypted at rest" is true of nearly every cloud service by default and says little. State the model: provider key, customer managed key, or client-side with customer-held key.

See the Encryption and Key Management Requirements Map for regulation-by-regulation requirements.

Where identity fits

Every model above reduces to an identity question: which human or workload identity can cause decryption. For server-side encryption with KMS, the decisive control is the key policy that allows a role to call decrypt; a service account with both storage read and KMS decrypt defeats the separation. For client-side encryption, the application identity that fetches or unwraps keys becomes the highest value non-human identity in the system. Scope it narrowly, keep its credentials out of code (ATT&CK T1552 Unsecured Credentials), and monitor its key calls. See the Secrets Management Guide.

Decision guidance and worked scenarios

General object storage for logs and backups: server-side encryption with a customer managed key, separate key administrators from data readers, block public access. Client-side adds cost without reducing the main risk.
Healthcare documents in a SaaS suite: server-side by default; client-side (Workspace CSE or Purview DKE) for the subset with contractual or regulatory key-custody requirements, accepting lost search and co-authoring on that subset.
Application storing national identifiers: application-layer, client-side field encryption with keys in a KMS or HSM, a separate decrypt service, and tokenisation where only matching is needed.
Small organisation: default server-side encryption plus strong identity controls usually gives more protection per hour of effort than client-side encryption. Choose client-side only where a customer or regulator requires it.
Large regulated enterprise: a tiered policy: provider default for everything, customer managed keys for regulated data, client-side for a defined crown-jewel class, each tier documented in the Encryption Policy Template.

Implementation: a phased approach

Classify and decide per data class. Record the threat (media, identity compromise, provider) and choose the lowest model that addresses it.
Baseline server-side encryption. Confirm defaults are on, enforce encryption settings with organisation policies or bucket policies, and plan re-encryption of existing objects where a default changed.
Move regulated data to customer managed keys. Separate key administration from data access; enable key usage logging.
Pilot client-side encryption with one team. Measure broken workflows (search, previews, sharing, eDiscovery) before wider rollout.
Build key recovery first. Back up and test restore of client-side keys before production data is encrypted with them.
Roll out in rings. Expand by group; keep a rollback path that re-labels or re-encrypts content with server-side keys if the business impact is unacceptable.

Detection and measurement

Coverage: percentage of storage resources using the encryption model their data class requires.
Key separation: number of identities holding both data read and key decrypt permission on regulated stores (target: only the designated application roles).
Key events: alerts on key disable, schedule deletion and key policy changes, with time to triage.
Decrypt anomalies: decrypt call volume per identity against baseline; a spike from one role often signals bulk exfiltration.
Recovery readiness: date of last successful key restore test for each client-side key service.

Common failure patterns

Treating "encrypted at rest" as protection against identity compromise. The service decrypts for any authorised caller.
Granting KMS decrypt broadly. A wildcard key policy turns a customer managed key into a provider-managed key with extra cost.
Encrypting client-side without a recovery plan. One deleted key or overwritten metadata field destroys the data permanently.
Applying client-side encryption to everything. Search, DLP and malware scanning stop, and users route around the control.
Leaving legacy modes in place. Running deprecated client library versions, such as Azure client-side encryption v1, after the vendor's guidance to migrate.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	PR.DS-01	Confidentiality, integrity and availability of data at rest are protected
NIST SP 800-53 Rev. 5	SC-28, SC-28(1)	Protection of information at rest; cryptographic protection
NIST SP 800-53 Rev. 5	SC-12	Cryptographic key establishment and management: custody, separation, recovery
NIST SP 800-53 Rev. 5	SC-13	Cryptographic protection: approved algorithms and modes
ISO/IEC 27001:2022	Annex A 8.24	Use of cryptography, including key management
MITRE ATT&CK	T1078.004, T1530, T1552	Cloud account abuse leading to data from cloud storage; unsecured credentials that expose keys

Practitioner checklist

Write down the threat each data class must resist before choosing a model.
Confirm server-side encryption defaults and enforce them with policy.
Use customer managed keys for regulated data and log every key call.
Separate data read permission from key decrypt permission.
Reserve client-side encryption for a defined, documented data class.
Test key backup and restore before encrypting production data client-side.
List the features each client-side scheme disables and agree them with the business.
Alert on key disable, deletion and policy changes.
Describe your encryption model precisely in contracts and audit responses.

Client-Side vs Server-Side Encryption: Threat Models, Key Custody and Trade-offs