This is the 3rd in a short FHE 101 series. Check out the first article if you haven’t already.
If you've worked in technology for any amount of time, you've heard some version of this phrase:
"Our data is encrypted at rest and in transit."
It's on vendor websites.
It's in security questionnaires.
It's in compliance reports.
It's become one of those statements that's both reassuring and oddly unquestioned.
The implication is simple:
The data is protected.
And to be fair, a lot of the time it is.
But there's a subtle problem hiding inside that sentence.
It describes two states of data.
Not three.
The Three States of Data
Most data lives in one of three states:
Data in Transit
Moving between systems.
Your browser talking to a website.
Your phone talking to a web application.
One service talking to another service.
This is where TLS shines.
The goal is straightforward:
Get the data from point A to point B without anyone reading it along the way.
Think armored transport.
The package gets where it's going safely.
Data at Rest
Sitting in storage.
Databases.
Backups.
Disks.
Cloud object storage.
This is where AES shines.
The goal here is different:
Protect the data while it's sitting still.
Think locked warehouse.
The package is safely stored until someone needs it.
And for many workloads, this is where the story effectively ends:
"The data is encrypted."
Which is true.
But there's an important nuance hiding inside that statement.
In many cloud environments, the cloud provider manages the encryption keys on your behalf. That's convenient, operationally simple, and often the default.
It also means the provider has access to both the encrypted data and the keys needed to decrypt it.
To be clear, this isn't necessarily a problem.
Cloud providers invest enormous resources into security, auditing, operational controls, and key management.
But it's a useful reminder that:
Encrypted doesn't automatically mean inaccessible.
In many cases, what we're really saying is:
The data is protected from unauthorized access.
That's different from saying:
Nobody can access it.
The difference between those two can be night and day when it comes to insider threats or poor understanding of, or discipline in, what it takes to manage keys to the data.
Some organizations choose to manage their own encryption keys. Most major cloud providers support customer-managed key workflows and even externally managed keys.
But in practice, convenience usually wins.
And that's understandable.
Managing encryption keys is one of those things everyone wants control over right up until they actually have to manage encryption keys.
Data in Use
And then there's the third state.
The one that doesn't fit neatly into the standard security slide.
Data being queried.
Data being analyzed.
Data being processed.
Data being used to make decisions.
Data in use.
Historically, this is where encryption stopped.
How We Got Here
To understand why "encrypted at rest and in transit" became the industry standard, it helps to understand the problems the industry was actually trying to solve.
The phrase didn't emerge from a marketing department.
It emerged from decades of practical engineering.
First, We Had to Secure the Internet
The early Internet was built on a surprising amount of trust.
Email often traveled in plain text.
FTP (File Transfer Protocol) moved files in plain text.
Telnet transmitted usernames and passwords in plain text.
In many environments, if you could see the network traffic, you could see the data.
The assumption was largely:
We're all on the same network.
We're all trusted.
What could possibly go wrong?
As it turns out...
quite a bit.
As the Internet became commercial, that assumption stopped working.
People wanted to:
- buy things online
- access banking services
- send sensitive information
- run businesses over the Internet
Suddenly, data moving across networks became a problem.
A big one.
This is where technologies like SSL—and eventually TLS—entered the picture.
Without encryption in transit, modern e-commerce doesn't happen.
Online banking doesn't happen.
SaaS doesn't happen.
Cloud computing probably doesn't happen.
Encryption in transit wasn't just a security feature.
It enabled entirely new ways of doing business.
At the time, encryption in transit wasn't universally embraced.
It added overhead.
It increased complexity.
It sometimes required specialized hardware.
There were real debates about whether the cost was worth it.
Today, of course, the idea of logging into your bank over an unencrypted connection sounds absurd.
That's the funny thing about successful security technologies.
Once they become normal, it's easy to forget there was ever a debate.
Then We Had to Protect Everything We Stored
The next challenge was different.
Storage became cheap.
Really cheap.
Organizations started collecting and retaining enormous amounts of data:
- customer information
- financial records
- healthcare data
- intellectual property
- application data
The problem was no longer data moving across networks.
The problem was data sitting somewhere.
On servers.
On disks.
On laptops.
On backup systems.
And occasionally those things got stolen, misplaced, or accessed by people who shouldn't have access.
This is where encryption at rest became essential.
The goal was simple:
If someone gets the storage, they shouldn't automatically get the data.
We Solved What We Could Solve
This is where things get interesting.
The industry successfully solved two very visible problems:
- Protect data while it moves
- Protect data while it sits
But there was a third state.
Data in use.
And that wasn't ignored.
It was unsolved.
The Physics Problem
What makes data in use different is that it wasn't merely a security problem.
It was a computing problem.
For decades, encryption and computation were fundamentally at odds with one another.
Encryption says:
Hide the information.
Computation says:
Show me the information so I can work on it.
Those goals don't naturally coexist.
A computer can't calculate a balance, search a database, train a model, or generate a report from information it can't understand.
Encrypted data is supposed to look like nonsense.
That's the whole point.
For years, computing had one simple rule:
If you wanted to use data, you had to expose it.
That wasn't negligence.
It wasn't a missing feature.
It was the practical reality of how computing worked.
And for a very long time, nobody had a better answer.
The Trade We Accepted
So the industry settled on a model that worked:
Encrypt while moving.
Encrypt while storing.
Decrypt while computing.
Not because it was perfect.
Because it was practical.
Over time, this became the standard trust model.
Protect the network.
Protect the storage.
Protect the keys.
And then...
Trust the environment performing the computation.
For years, "encrypted at rest and in transit" became the security equivalent of:
"Don't worry, we've got this."
And honestly?
Most of the time, they did.
The challenge wasn't that the statement was false.
The challenge was that it only described two of the three states data lives in.
The third state was still dependent on trust.
Not because anyone overlooked it.
Because nobody had a better answer.
Yet.
Why This Matters More Now
For a long time, this trade worked reasonably well.
Applications were smaller.
Datasets were smaller.
Systems were simpler.
And AI wasn't consuming everything in sight.
Today we have:
- cloud computing
- multi-party collaboration
- shared datasets
- machine learning
- large-scale analytics
- increasingly sensitive information
The amount of data being processed has exploded.
So has the value of that data.
Which means the moment when information becomes visible matters more than ever.
The old assumption was:
The system doing the work needs access to the data.
The new question is:
Does it?
We've Seen This Before
There's an interesting historical parallel here.
There was a time when encryption in transit was considered expensive, slow, and sometimes unnecessary.
SSL and early TLS added overhead.
Specialized hardware was often required.
Many organizations simply didn't bother.
Today?
The browser practically scolds you if a website doesn't use HTTPS.
What was once considered expensive eventually became expected.
Not because the idea changed.
Because the hardware, software, and economics changed around it.
FHE may be on a similar journey.
We're not there yet.
But the conversation sounds surprisingly familiar.
More Than Better Security
The historical parallel to TLS is interesting for another reason.
Encryption in transit didn't become important because it was more secure.
It became important because it enabled things that previously weren't practical.
Without SSL and TLS:
- e-commerce doesn't happen
- online banking doesn't happen
- SaaS doesn't happen
- cloud computing probably doesn't happen
The security was essential.
But it wasn't the end goal.
It was the enabler.
FHE may be on a similar path.
Today, we often talk about Fully Homomorphic Encryption as a security technology.
And it is.
But the more interesting question might be:
What becomes possible when data no longer has to be exposed to be useful?
If organizations can collaborate without sharing raw data...
If models can learn without revealing sensitive information...
If applications can operate without exposing underlying datasets...
Then FHE isn't just improving security.
It's enabling entirely new classes of privacy-preserving applications.
History suggests that's where things start to get interesting.
Enter Fully Homomorphic Encryption
This is where Fully Homomorphic Encryption starts getting interesting.
Not because TLS failed.
Not because AES failed.
Not because cloud providers failed.
Those technologies solved exactly the problems they were designed to solve.
FHE addresses the part they were never designed to handle.
The question isn't:
How do we protect data while moving it?
Or:
How do we protect data while storing it?
The question is:
How do we protect data while using it?
That's a very different problem.
And until recently, it wasn't one we could realistically solve.
The Short Version
"Encrypted at rest and in transit" isn't wrong.
It's just incomplete.
It describes two states of data.
Not three.
The third state—data in use—is where trust has traditionally entered the picture.
And it's where some of the most interesting work in computing is happening today.
What's Next
So far in this series we've talked about what FHE is, how it differs from the encryption you already know, and why the industry ended up with the trust model we have today.
Next, we'll start looking at what becomes possible when that model changes.
We'll explore practical applications of FHE, where it shows promise today, and where purpose-built hardware, cloud platforms, and a healthy amount of stubborn engineering are helping move it from theory into reality.
And yes, we'll eventually talk about ASICs.
To learn more about FHE, hardware acceleration, and Niobium’s encrypted cloud platform, The Fog™, contact us or sign up to join our Developer Partner Program!
