Almost every service states that data is encrypted at rest. The claim is usually true and protects against a narrow scenario: somebody obtaining the physical medium. Against the threats people are actually worried about, it does approximately nothing, and understanding why clarifies what to look for instead.
What the claim means
Data written to storage is written as ciphertext, and the service decrypts it in order to use it.
The second half is the consequence worth holding onto. The running system must be able to decrypt on demand, or it could not show you your own files. So the key is present, reachable by the application, and available whenever the service is working — which is always.
It is not a wall keeping everyone out. It is a lock whose key is held by the thing standing next to it.
The threat it genuinely defends against
Real, and worth defending against.
A drive leaving a building. A decommissioned disk that was never wiped. A stolen server. A backup medium that went somewhere it should not have. In every one of those, possession of the hardware no longer means possession of the contents.
These have all happened, repeatedly, and this is why the practice is near-universal and correct. Nothing in this piece argues against doing it.
The threats it does not touch
An attacker inside the running system, who receives plaintext because the system decrypts on request and cannot distinguish requests.
A compromised credential, for the same reason — the system is behaving normally.
An insider, who is already on the correct side of the lock.
A legal demand, which is served on the party holding the key and answered with plaintext.
A flawed application, which is handed decrypted data by design and then mishandles it.
Those five cover most of what people are actually worried about when they look for the claim.
Why it appears so prominently
Not dishonesty. Three ordinary reasons.
It is easy to implement — often provided by the storage layer with a checkbox, which makes it cheap to have and cheap to mention.
It is easy to state truthfully, with no caveats needed and no legal review beyond confirming the checkbox.
And it contains the word encryption, which readers map onto a much stronger property than the one being asserted.
The claim is true and it answers a question nobody asked.
The question it is standing in for
Someone scanning for this line is nearly always trying to answer a different question: can the provider read my data?
Encryption at rest is compatible with every possible answer to that. The provider can hold the key, you can hold it, a third party can. The claim is silent on all of it, which is exactly why it feels informative and is not.
What to look for instead, in order
Can the provider restore your data after a full password reset? If yes, they hold a route to the key. One question, one minute.
Where are keys derived? On your device and never sent, or on their infrastructure.
Does support have a path to plaintext? If an agent can look at your files to help you, the answer to the earlier question is settled.
Is there a statement of what the service cannot do? Limitations cost something to publish, which is what makes them worth reading.
When it is genuinely the right answer
Often, and this matters.
For material the service must read to be useful at all — a search index, a document several people edit simultaneously, a record the system acts on automatically — encryption at rest with disciplined key management is the correct design. Demanding more is demanding a different product, and sometimes the different product would be worse at the job.
The honest version of the claim simply says what it covers: protected against loss of the medium, readable by the service, and here is why the service needs to read it.
Close
Not a weak practice. A weak claim, doing headline duty for a property it does not have, in the space where the interesting sentence could have gone.