A managed store reports that encryption at rest is enabled by default - which risk does that remove, and which does it leave?

## What the default actually does Large providers commonly enable **encryption at rest** on storage and managed-database services without being asked, and the setting that reports it is telling you something narrow and real: the bytes are ciphertext on the media the provider owns. The usual construction is **envelope encryption**. The service generates a symmetric **data key**, encrypts your blocks or objects with it, and stores that data key **wrapped** under a longer-lived key held in the platform's key service. Every authorized read is decrypted on the way out, transparently - no client change, no key ever reaching your application. That retires a specific, physical class of exposure: - a drive that fails, is pulled from a rack, resold, or handed to a disposal contractor; - staff with hands on hardware but no route through the service API; - raw blocks recovered from the storage layer beneath the service; - an audit requirement that no customer data sits in plaintext on disk. These are genuine risks, and the default retires them at almost no cost to the provider, which is exactly why it is a default: it is the one guarantee that scales to every tenant identically. ## The boundary it does not cross Decryption happens **inside the service, on behalf of whoever the service admits**. Once a request passes the access check, the answer is plaintext. So an enabled at-rest setting tells you nothing about: - **who may call the store** - an over-broad permission reads exactly as much plaintext as a correct one; - **the provider's own reach** - under a provider-held key, the party operating the key is also the party able to use it; - **what leaves** - an export, a copy restored into another system, or a feed into a data pipeline is plaintext at the moment it is produced, and is protected by whatever the destination does; - **whether the data could ever be made unreadable** - that follows from holding the key, not from using encryption. A sentence worth carrying into an interview: at-rest encryption answers *where the bytes are ciphertext*; it never answers *who can turn them back into plaintext*. ## The custody question the setting hides Custody is the axis the checkbox does not report, and there are three honest positions on it. | Custody posture | Who holds the key | What it gives you | What it costs | |---|---|---|---| | Provider-held default | the provider, usually per service or per account | encryption with no work and no new failure mode | no revocation switch, no key-level record, no say in scope | | A key you control in the platform's key service | you, under your own account and key policy | key revocation, a record of key use, key policy separate from store policy | the key service is on the read path, and a key you can lose | | Key material in a store you operate | you, entirely | custody that survives the provider relationship | every read depends on a system your team runs and is paged for | The default silently picks row one, and with it three things you did not choose: the **scope** of the key (often one key for a whole service or account, so there is one switch for everything under it), its **lifecycle** (rotation cadence, version retention, destruction are the provider's), and the absence of a key-use record distinct from the store's own access logs. ## How to interrogate the setting When someone shows you the enabled checkbox as evidence, ask in this order: 1. **Which key is it** - the service default the provider holds, or one you control? 2. **What is its scope** - the whole store, an account, or something narrower such as a key per tenant? 3. **If you had to make this data unreadable tomorrow, which switch would you pull** - and does that switch belong to you? 4. **Does the answer still hold for copies** - replicas, service-taken backups, and anything already exported in plaintext? Question four is where the claim usually breaks. Replication copies ciphertext faithfully and a retention-bound backup is a separate copy with its own lifetime, while an export is plaintext the moment it is produced and has left the key's protection entirely. ## What the default is genuinely good for None of this makes the default worthless. It is the right posture for the large majority of workloads: it costs nothing, it removes a class of physical exposure that you cannot otherwise address on rented hardware, and it satisfies a common control requirement honestly. The defect is not turning it on - it is treating it as an answer to a question it was never asked, and then discovering during an incident or a contract review that nobody on the team holds a key.