"All data is encrypted at rest with AES-256." It is on every security page, it is true, and it protects against approximately one thing: someone taking the physical disk.
Every other way your data gets read, an application bug, a stolen credential, an over-permissioned query, a compromised process, happens through a path where the data is already decrypted. The encryption is transparent by design, which means it is transparent to attackers too.
This post is what the control actually covers and where the meaningful decisions are. For whoever has to answer a questionnaire about it, and for whoever is deciding what to build.
What it protects against
Be precise, because the honest scope is narrow:
- A disk or backup medium leaving the building.
- A cloud provider decommissioning storage without wiping it.
- A snapshot copied somewhere it should not be, if the key does not travel with it.
That is roughly the list. It is a real list, it is largely why the control is mandated, and it is satisfied by a checkbox in every managed database service.
What it does not protect against
Everything that queries the data, because the storage layer decrypts for anyone who reaches it through the normal path:
- SQL injection.
- A stolen database credential.
- An application bug returning the wrong rows.
- A compromised process reading through its own connection.
- An engineer with production access.
- A backup restored into an environment that has the key.
If someone asks "does encryption at rest protect us from a breach", the answer is that it depends entirely on the breach, and for the ones that actually happen, no.
Where the decisions are
Who holds the key. Provider-managed keys are convenient and the provider can decrypt. Customer-managed keys in the provider's key service give you an audit trail and the ability to revoke, which is meaningful, and the provider still operates the service. Keys held entirely outside the provider are the strongest and the most operationally demanding. This is the choice that determines what the control is worth, and most teams never make it explicitly.
Whether the key is separable from the data. A snapshot copied to another account is only protected if the key does not come with it. Check that, because the default in several services is that a copy remains readable within the same account.
Who can use the key. The key policy is the real access control. A key that every role can use protects against the stolen disk and nothing else. Restricting which principals may decrypt is where the control starts doing work against realistic threats.
Whether key use is logged. Decrypt operations in an audit trail let you see access that the database's own logs may not show, and it is the part that helps during an investigation.
Field-level encryption is the one that changes the threat model
Encrypting specific fields in the application, with keys the database never has, is a genuinely different control. The database compromise, the injection, the over-broad query all return ciphertext.
The costs are real and worth stating: you cannot index or search the encrypted fields normally, range queries become impossible, key rotation means re-encrypting, and application complexity rises. Which is why it suits a small number of fields, the ones where disclosure is catastrophic, rather than everything.
The useful question is not "should we encrypt more" but "which three fields would hurt most", and then encrypt those properly.
Answering the questionnaire honestly
You will be asked, and there is a difference between a true answer and a useful one.
"Yes, AES-256 at rest" is true and tells the reviewer nothing they did not assume. A better answer names the key custody model, whether keys are customer-managed, whether key use is logged, and what is additionally encrypted at the field level.
A reviewer who reads that knows more about your posture than one who reads the standard sentence, and they stop asking, which is the outcome you wanted.
Do not let it substitute for the controls that matter
The risk in this area is not technical, it is rhetorical. "Encrypted at rest" is reassuring, and it gets offered in response to questions it does not answer: how do you prevent one tenant reading another's data, what stops a compromised credential, how do you limit what an engineer can see.
Those are answered by access control, tenant isolation, least privilege on the database connection, and audit logging. Encryption at rest is orthogonal to all of them, and a security page that leads with it is often a security page with less to say about the rest.
The concession
None of this is an argument against enabling it. It is free in every managed service, it satisfies a real requirement, it closes the physical-media case genuinely, and there is no reason not to.
The argument is against the weight it carries in conversations. It is a baseline, correctly mandated, and it should occupy about one line of your security documentation rather than the headline, because the headline should be the control that stops the incident you are actually likely to have.
The implication
Ask what would have to go wrong for encryption at rest to be the thing that saved you. The honest answer is a stolen disk, and for most organisations that is not in the top ten of realistic scenarios.
Then ask the same question about your database access controls, your tenant isolation and your audit logging. That is where the answer changes, and it is where the effort belongs.
