Stiamo aprendo un design partner program. Scopra il programma

Explainers

Encrypted at rest does not mean private.

5 ago 2026

Pubblicato in inglese, la lingua in cui è stato scritto. Il suo browser può tradurlo.

Nearly everything stored in the cloud today is encrypted. Almost none of it is private: the provider holds the keys, and its systems decrypt on demand. This article walks through who can actually read your data, what the providers already offer against that, and why those offers stop where they stop.

1. The misunderstanding

“Encrypted at rest” is a default, not a feature. Amazon S3 has encrypted every new object since 5 January 2023 and states that this can no longer be turned off. Google says Cloud Storage “always encrypts your data on the server side, before it is written to disk”. Microsoft says “Azure Storage encryption can’t be disabled”.

Read those three sentences as one statement about the industry: on the platforms holding most of the world’s commercial data, every object is encrypted, nobody can switch it off, and the party performing the encryption is the party operating the service. Which is why the checkbox carries so little information. A control nobody can disable cannot distinguish a careful system from a careless one, and it does not answer the question most people think it answers, who is able to read this.

The answer is on the same pages: Google’s documentation for default keys says the data “is automatically decrypted when read by an authorized user”. Decryption is automatic and it happens inside the provider. Everything below is about who counts as authorised.

2. What encryption at rest is actually designed to stop

Microsoft states the threat model plainly:

“Attacks against data at rest include attempts to obtain physical access to the hardware … a server’s hard drive might be mishandled during maintenance, which allows an attacker to remove the hard drive.”

(Azure data encryption at rest.) Google frames it identically: “Even if attackers obtain the storage devices … they won’t be able to understand or decrypt it”.

That is a real protection, against a stolen disk, not against a logged-in party. The same Microsoft page gives the reason: the key that “encrypts data as it’s written to storage” is the one that “decrypts that data as it’s prepared for use in memory.” NIST made the general point two decades ago, that once authentication occurs “any process … with access to the user’s files can get the decrypted information”. Encryption at rest raises the cost of reading a drive, and does nothing about anyone the system considers authorised.

3. Who holds the keys, mode by mode

All three use the same two-tier construction: a data encryption key encrypts the bulk data, and a key encryption key in a key management service wraps it (envelope encryption at AWS, the same hierarchy at Google). Which layer an option touches is the whole exercise.

Provider-managed keys (the default)

The provider generates, stores, rotates and uses the keys. Of its own service-owned keys AWS says “you cannot change their policies, you cannot audit activities on these keys, and you cannot delete them”.

Does not protect against: anything except physical media loss.

Customer-managed keys (KMS, CMEK, Key Vault)

This is where most regulated buyers land. With Cloud KMS, Google says, “you control and manage these keys”; Microsoft is equally candid that what changes is “the protection of the root encryption key”, not the data path. AWS publishes the read workflow: S3 sends the wrapped data key to KMS, “AWS KMS decrypts the encrypted data key … and returns the plaintext data key to Amazon S3”, and S3 decrypts the object. What you gain is a veto, not custody: disable the key in Azure Key Vault and “clients can’t call operations that read from or write to a resource or its metadata”.

Does not protect against: any read that happens while the key is enabled, which is all of them.

Customer-provided keys (SSE-C, CSEK, CPK)

You send the key with each request and the provider promises not to retain it: “S3 never stores the encryption key when you use SSE-C”, and Google keeps only a hash of it. The cryptography is still theirs: in Microsoft’s published table, “Encryption/decryption operations” read Azure in all three key-management models, customer-provided keys included. Your key crosses their TLS terminator and lands in their memory on every request. The mode is narrowing too, with CSEK removed from Compute Engine in 2027.

Does not protect against: compromise of the running service, and it never covered metadata: S3 “encrypts only the object data, not the object metadata”, and standard Cloud Storage encryption covers “the object’s name”.

4. Four paths from ciphertext to plaintext

Path one: internal access

Provider staff read customer content under defined justifications. That is documented, not alleged: Google’s Access Transparency logs what its personnel do when they access customer data, and Key Access Justifications enumerates why its systems ask to use your key, including to “Decrypt your data to fulfill the contractual obligation of providing support”.

That access can also be bought: Coinbase told the SEC that an attacker obtained customer data “by paying multiple contractors or employees working in support roles outside the United States”, and the FTC found that Ring let staff watch thousands of customer videos unnoticed. Verizon’s 2026 DBIR puts privilege misuse just under 4% of breaches: not frequent, but encryption at rest does not sit on the path.

Path two: compromised credentials

The mechanical consequence of automatic decryption. AWS states the rule: “To download an object encrypted with an AWS KMS key, you need kms:Decrypt permissions for the key”. Steal the credential, inherit the decryption. The DBIR finds credential abuse in 39% of breaches, and in the 2024 Snowflake customer campaign Mandiant found no vendor breach at all: every incident “was traced back to compromised customer credentials”.

Keys are stolen too: a stolen Microsoft signing key let an actor read mailboxes at 22 organisations, and LastPass wrote the cleanest sentence on the failure mode, “This database was encrypted, but the separately-stored decryption key was included in the secrets stolen”. In the same breach customer vaults survived, because they “can only be decrypted with a unique encryption key derived from each user’s master password”. One incident, both halves of the argument.

Path three: misconfiguration and over-permission

In the Capital One breach, data encrypted at rest in S3 was read through an over-permissioned role reached by server-side request forgery. The ICO’s Marriott penalty notice records the most literal version: among the exfiltrated tables was one containing “the passport number record specific decryption key”. Ciphertext and key travelled together. Third parties widen the surface, and the DBIR puts them in 48% of breaches: Google’s threat intelligence group documented bulk exports from Salesforce customer instances via compromised third-party application credentials, with no flaw in the platform itself.

Path four: lawful compulsion

The CLOUD Act added 18 U.S.C. § 2713: a provider must disclose content within its “possession, custody, or control”, “regardless of whether” it sits inside or outside the United States. Control, not location, is the trigger, and data a provider can decrypt is data in its control.

Microsoft’s transparency report for the second half of 2025 records 190 enterprise requests, in 94 of which it was “compelled to provide responsive information”, disclosing customer content in 45, including for “3 non-U.S. enterprise customers whose data was stored outside the U.S.” It also states, correctly, that it “does not provide any government with our encryption keys.” True, and beside the point: nobody asks for the key when they can ask for the plaintext. Asked under oath by the French Senate whether French citizens’ data would never reach US authorities without French agreement, Microsoft France’s director of public and legal affairs answered “Non, je ne peux pas le garantir”.

Compulsion can also reach key material, which the EDPB notes “may extend to any cryptographic keys necessary to render the data intelligible”, and gag orders mean you may not be told: AWS’s notification commitment is qualified by “unless AWS is legally prohibited from doing so”.

5. The partial answers, and why they stay partial

Every major provider has already built something that closes those paths. None ships it by default, all attach conditions, and each publishes an accurate list of what it costs.

Microsoft Double Key Encryption uses two keys, one in Azure and one in a service the customer builds from source files on GitHub and hosts “in a location of your choice”. The perimeter is desktop Office on Windows, since “you can’t view encrypted documents and files online”, and it stays tied to the vendor, because “the service requires access to Microsoft Azure”. Microsoft recommends aiming it at the “about 5% of data” it calls the crown jewels.

Google Workspace client-side encryption requires an external key management service, from a named partner or built against Google’s key access API, so that “Google servers can’t access your encryption keys and, therefore, can’t decrypt your data”. The perimeter is partial by design: in Gmail the body is covered while “the header of the email, including subject, timestamps, and recipients, will not” be.

The AWS S3 Encryption Client is a library rather than a service, one that “enables you to encrypt an object locally” so that “Amazon S3 doesn’t recognize the objects as being encrypted”. It “protects the data keys that encrypt your objects by encrypting them under a wrapping key” that you pass in. Choosing the wrapping key is yours, and so is its recovery: the client accepts a KMS key, in which case AWS still holds the wrapping key, or a key you hold, in which case nothing about it crosses the boundary.

Apple Advanced Data Protection is opt-in and off until enabled, raising the count of end-to-end encrypted iCloud categories from 14 to 23. Mail, Contacts and Calendar stay out permanently, “because of the need to interoperate with the global email, contacts, and calendar systems”.

Each vendor also publishes what its own option turns off, and the four inventories are one inventory. Microsoft names the “services that you can’t use with DKE encrypted content”: eDiscovery, content search and indexing, coauthoring in Office Web Apps, and Copilot. Google’s client-side encrypted files and email “aren’t scanned for phishing and malware”, data loss prevention “scans can’t access” them, and Amazon Macie “can’t decrypt the object” and reports metadata only. Turning Apple’s setting on means “web access to their data at iCloud.com is automatically turned off”, off by default and re-enabled only with the participation of a trusted device.

Why the line falls where it does

Four vendors, no coordination between them, one list. Search, indexing, previews, scanning, collaborative editing, discovery and assistants all need a server that can read the bytes, and those are the capabilities the platforms are sold on. Microsoft describes the index behind its assistant as “an organization-wide index generated from text-based SharePoint Online files” that “can’t be disabled”, though individual SharePoint sites can be excluded from it. Google presents client-side encryption as the way to withhold data from its assistant, “because no Google system or Google employee have the technical means to access CSE content”. Both statements are accurate, and together they describe arithmetic rather than intent: a provider whose product reads the data can offer encryption it cannot break only where reading the data was not the product.

One further boundary follows from the same logic: none of them offers to spread a customer’s data across its competitors. “Amazon S3 Cross-Region Replication (CRR) is used to copy objects across S3 buckets in different AWS Regions”; an Azure account’s secondary region “is determined based on the primary region, and can’t be changed”. The nearest thing to a multi-provider storage offer is a billing concession, Google zero-rating “qualifying multicloud traffic” in the UK and EU. The Data Act changes the price of leaving, not who could read the data while it was there.

So the partial answers are real and they point the right way. What keeps them partial is that finishing the job means operating above several providers at once, which is the one thing none of them sells.

6. What the regulation says, and the asymmetry that matters

The GDPR names encryption first in its list of appropriate measures, at Article 32(1)(a). The decisive provision is elsewhere. Article 34(3)(a) removes the obligation to tell affected individuals about a breach where the controller has applied measures “that render the personal data unintelligible to any person who is not authorised to access it, such as encryption.” That is the asymmetry: the same incident is either a mass notification exercise or an internal record, depending on whether the exposed data was intelligible.

The conditions are strict. The EDPB reads Article 34(3)(a) as requiring a state-of-the-art algorithm, a key that “was not compromised in any security breach”, a key that cannot be ascertained by available technical means, and adequate backups. Test that second condition against the four paths above: in each of them, the party that obtained the data also held, or obtained, the means to read it.

Three limits. The discharge covers the communication to individuals, not the report to the regulator: the ICO states that even where encryption makes data unintelligible, “you must still check whether you need to tell us about the personal data breach”, and every breach must still be documented internally under Article 33(5). Neither NIS2 nor DORA offers an equivalent carve-out. In the US the discharge is broader: under the HITECH breach notification guidance, properly encrypted health information is not “unsecured”, so covered entities “are not required to provide notifications in the event of a breach of such information”, provided the key “has not been breached.”

On whether provider-held encryption qualifies where the provider needs the data in the clear, the EDPB has already answered, in a formal adopted opinion:

“In the given scenarios, where unencrypted personal data is technically necessary for the provision of the service by the processor, transport encryption and data-at-rest encryption even taken together, do not constitute a supplementary measure that ensures an essentially equivalent level of protection if the data importer is in possession of the cryptographic keys.”

(Recommendations 01/2020, paragraph 95.) In the same document, the condition that makes encryption effective is that “the keys are retained solely under the control of the data exporter”, or of a trusted entity in an adequate jurisdiction.

7. What changes when the keys never leave you, and what does not

The definition is narrow: data is encrypted before it crosses the boundary, and the provider never receives key material. AWS describes its client-side path as protection that is “never exposed to any third party, including AWS”. Google states that with client-side encryption “Google has no possible access to the unencrypted data”. Apple, describing what happens when Advanced Data Protection deletes its server-held keys, says “Apple can no longer access any of the data protected by the user’s service keys”.

That closes the four paths above with respect to content, and an empirical control exists: Signal publishes the legal requests it receives with its answers, which amount to a registration date and a last-connection date, because “we simply don’t have access to things like messages, calls, profile information, group information, contacts, stories, call logs”. Same jurisdiction, same statutes, different architecture, different output.

Now the honest part. Client-side keys do not solve the following.

8. Five questions to put to your provider

  1. Who can decrypt my data without my involvement? The decisive test. Not “is it encrypted”, not “who owns the key”, but which systems and which human roles can produce plaintext with no action on my side. Ask for the list.
  2. Where does decryption happen, and with which key? Microsoft answers this in a published table: encryption and decryption operations are performed by Azure in all three key-management models. Expect an equally specific answer.
  3. What exactly is not encrypted? Object names, sizes, timestamps, checksums, tags, access logs. Get it in writing. This is what a compulsion order or a compromised index reaches regardless of key custody.
  4. What happens when a lawful order arrives? Will you notify me, what is the exception to that commitment, and what is technically producible if you are gagged? “We never hand over our keys” is not an answer.
  5. If the answer is client-side encryption, who wrote the client and how is key material authenticated? Key replacement by a malicious server was the most common flaw in the ETH Zurich study. Ask how a substituted key would be detected, and how you would verify a new build.

Conclusion: four criteria, and how to use them

Encryption at rest is universal, and it defends against one thing: someone taking the disk. Every other path arrives holding something the system treats as authorisation, and for that party the platform decrypts by design. A complete answer satisfies four conditions at once, each a property of a mechanism rather than a promise, and so each checkable before signing anything.

  1. Key material never crosses the boundary. Not in escrow, not recoverable by support, not present in the operator’s memory during a request. The EDPB states the same condition, that “the keys are retained solely under the control of the data exporter”. Ask for the technical path by which the operator could produce plaintext; the criterion is met when none can be described.
  2. No single provider holds a complete record. A whole ciphertext object in one estate is a single address for an order under 18 U.S.C. § 2713 and a single target for an intrusion. Ask what one provider would hand over if compelled, and what could be reconstructed from it.
  3. Integrity is provable by a third party, without trusting the operator. The ETH Zurich study found unauthenticated key material and metadata a malicious server could substitute (ACM CCS 2024). The criterion is met when a client can detect substitution from evidence it verifies itself, rather than from a report produced by the party being checked.
  4. It runs above the providers already in use, without replacing them. In every offer in section 5 the data itself stays in one estate, even when the key service sits outside it, and none of the incumbents distributes that data to a rival. A control that works only for customers of a single platform reinstates the dependency it was meant to remove, and sits badly with the right the Data Act grants to “use several services at the same time”. Ask whether existing storage contracts survive the change.

Four criteria, to be put alongside the five questions in section 8. Applied to the incumbents, they explain why the partial answers stay partial. Applied to anyone claiming to have gone further, they are the shortest route to finding out whether a mechanism sits behind the claim.

Where the publisher of this article stands

This article is published by DataPrism, and the gap described above is the reason it exists. The four criteria are not a description of the product, they are the specification it was built against, so the fair thing is to answer them in the same order.

Keys are derived on the client and are never transmitted, so there is no technical path by which the platform produces plaintext. Files are encrypted before they leave, then split into fragments with built-in redundancy and dispersed across independent providers, so no single estate holds a complete record and no single order reaches one. A constant-size proof of integrity is anchored on a public ledger, which is what makes tampering detectable by a third party rather than reportable by the operator. And the whole thing is an overlay on the object storage already in use, reached through a client library, so existing provider contracts stay in place.

The incumbents could each build the first criterion, and three of them already have, within the limits set out in section 5. What none of them will build is the second and the fourth, because both require operating above several providers at once and treating each of them as interchangeable. That is not a technical obstacle. It is a description of what they sell.

Two things should be said plainly. The limits in section 7 apply here as much as anywhere: metadata remains visible, key custody becomes a real operational responsibility, and server-side features that need to read the bytes do not come back. And the five questions in section 8 are the right ones to put to this vendor too, which is the point of publishing them. How the architecture answers them.

Sources

Provider documentation, encryption at rest and key management

Provider documentation, client-side encryption offerings and their limits

Replication scope and multi-provider operation

Standards

Law and regulators

Incidents, enforcement and transparency reports

Research