You have probably heard the phrase “your data is encrypted” so many times that it stopped meaning anything.
It is on privacy pages. It is in app store listings. It is buried somewhere in the terms of service that nobody reads. At this point, it sounds like a guarantee. Like a seal of safety.
But what most people imagine when they hear “encrypted” is not what is actually happening.
The Mental Model Problem
When people think about encryption, they picture a locked vault.
You put your data inside. You lock it. Only you can unlock it. Safe.
That model is not wrong. It is just incomplete.
Because encryption is not a single lock. It is a series of questions you need to ask at every stage of your data’s journey:
- Is the data encrypted while it is moving?
- Is it encrypted while it is stored?
- Who holds the key?
- Where is the key stored?
- Is the key itself protected?
Most people only think about the first one.
Your phone sends data to a server. It is encrypted during transfer. Great. Done.
Except the story does not end there.
Data Does Not Just Move. It Sits.
Data spends most of its life doing nothing.
It sits in databases. Sometimes for years.
And what happens to your data while it is just sitting there is a completely different problem. One that companies solve on their side, often without explaining how.
This is where the concept of encryption at rest comes in.
Encryption at rest means that data stored on disk is still encrypted even when nobody is accessing it. If someone gets direct access to the storage, they still cannot read anything without the key.
There are multiple ways to implement this:
- Full disk encryption protects the entire storage volume.
- Database encryption protects the database itself.
- Field level encryption protects specific sensitive data like passwords or card numbers.
All of these options exist. They have existed for years. They are not particularly hard or expensive to implement.
And yet, historically, many companies did not fully use them.
The Awkward Truth About “Encrypted Databases”
Here is where things get uncomfortable.
Some systems encrypt the data… and then store the encryption key right next to it.
That is the equivalent of locking your front door and leaving the key in the lock.
From a technical standpoint, yes, the data is encrypted.
From a practical standpoint, it changes almost nothing.
But it allows a company to say, truthfully, that your data is encrypted.
And that is often enough for marketing.
Why This Keeps Happening
Encryption at rest is not difficult, but it does introduce trade-offs:
- More complexity in the system
- Slight performance overhead in some cases
- Key management problems, including storage, rotation, and recovery
None of these are impossible to solve. They just require time and money.
And this is where incentives come into play.
Engineering time is a guaranteed cost today. A data breach is a possible cost in the future.
Companies that prioritize speed and growth tend to push future risks aside in favor of shipping faster.
The result is predictable.
The risk is carried by users. The savings are kept by the company.
Has Anything Improved?
Yes. To a degree.
Regulations like GDPR have forced more transparency. Cloud providers like Amazon Web Services, Google Cloud Platform, and Microsoft Azure now offer encryption at rest as a default option.
Often, it is just a checkbox.
And that has helped adoption more than most compliance frameworks ever did.
Because the easiest option is usually the one that gets used.
But “it is available” does not mean “it is always enabled” or “it is configured correctly.”
What You Should Actually Do
You cannot control how every company handles your data. But you can change how you think about it.
1. Stop assuming encryption means safety
If a company says your data is encrypted, that is a starting point, not a conclusion.
Ask what kind of encryption. Ask where the keys are stored. Ask if backups are encrypted too.
These are reasonable questions.
2. Control what you can control
If you run your own servers or store your own data, encryption at rest is something you can implement.
On Linux systems, tools like LUKS allow full disk encryption. Databases often support their own encryption layers as well.
It will not solve every security problem. It is not supposed to.
It protects one specific scenario: someone getting direct access to your storage.
3. Do not self-host unnecessarily
Every system you run becomes your responsibility to secure.
If you do not need that responsibility, do not take it.
The Reality Check
Your data might be encrypted.
It might even be sitting in an encrypted database right now.
Protected by a key.
Stored in a convenient place.
Possibly right next to the data itself.
And secured by a password that has not been rotated in years.
Perfectly safe.
