Data at rest vs data in transit is the comparison between the two classic states of data — stored data and data moving across a network — and each state requires a different type of encryption. There is also a third state, data in use, which covers data being actively processed. Most organizations think of encryption as a binary: data is either encrypted or it is not. In practice, encryption is three distinct problems, and applying the wrong method to the wrong state creates false confidence without actually solving the problem.
TL;DR
- Data exists in three states: at rest (stored), in transit (moving), and in use (being processed). Each has its own attack surface and its own encryption standard.
- AES-256 protects data at rest. TLS 1.3 protects data in transit. Both are mature, cheap, and widely deployed.
- Data in use is the least protected state. Protecting it requires confidential computing technologies: TEEs, fully homomorphic encryption, or secure multi-party computation.
- Encryption alone is not security. Governance — who can compute what, on which data, with what audit trail – determines whether any of it works in practice.
What Is the Difference Between Data at Rest and Data in Transit?
Data at rest is data stored somewhere – a database, file system, data warehouse, or cloud storage. It is not moving and not being actively processed. The risk is that someone accesses the storage directly: steals a drive, reads a backup, or bypasses application controls with database access. We cover the storage state in more depth in our guide to data at rest.
Data in transit is data moving across a network – from client to server, between services, across the internet, or between data centers. The risk is interception: an attacker reads packets on the wire or modifies them in flight.
Data in use is data being actively processed. It exists in application memory, in a processor’s cache, or in a compute engine executing a query or training a model. Historically this state was treated as out of scope for encryption – the assumption was that if you controlled the application and the server, data in use was implicitly protected.
That assumption no longer holds. When data lives on a cloud provider’s infrastructure, or when partners need to analyze it together, the perimeter dissolves and data in use becomes an attack surface. This is why privacy-enhancing technologies have moved from research topic to enterprise requirement.
Encryption at Rest: AES and Storage Protection
Data at rest encryption protects stored data. The goal is simple: if someone gains access to the storage medium – a hard drive, a database backup, a cloud storage bucket – the data is unreadable without the key.
The standard is AES (Advanced Encryption Standard), typically at 256-bit strength. AES is fast, ubiquitous, and cryptographically strong. Most cloud providers offer it managed or customer-managed, and most databases support transparent encryption at write time.
Key management matters more than the encryption itself. If the key sits next to the encrypted data – same drive, same database – encryption provides no protection against someone stealing the whole system. The common patterns:
- Symmetric encryption – one key encrypts and decrypts; simple, but the key must be distributed securely
- Key derivation – keys derived from a passphrase; avoids storing keys directly
- Key management services (KMS) – cloud-provider services that separate keys from application code and simplify rotation
Encryption at rest is now standard and inexpensive, minimal latency, and the overhead is operational rather than computational. It breaks down when keys are stored alongside data, when multiple systems need simultaneous plaintext access, or when compliance requires that data never exist unencrypted, even during processing.
Encryption in Transit: TLS and Network Protection
Data in transit encryption protects data on the move. The standard is TLS (Transport Layer Security), the protocol underlying HTTPS. TLS does three jobs: it establishes an encrypted tunnel between client and server, authenticates the server’s identity, and ensures data is not modified in flight.
TLS is ubiquitous and transparent. Modern TLS 1.3 is cryptographically strong – in practice, failures come from expired certificates and weak cipher suites, not the algorithm.
TLS has one critical limitation: it only protects data in flight. The moment data arrives, TLS stops and the destination receives plaintext. If the destination is compromised, or simply isn’t yours, TLS does nothing. Data encrypted in transit can arrive at a cloud provider’s server or a partner’s system, decrypt, and become readable to anyone with system access. TLS solved the network problem, not the access problem.
Key Takeaway
Most organizations have already solved encryption at rest and in transit. The gap is the third state: data is protected on disk and on the wire, then fully exposed the moment an analyst queries it, a model trains on it, or a partner processes it. The next frontier of data security is protecting data in use.
How Do You Encrypt Data in Use?
Data in use protection means data remains encrypted or isolated even while an application or algorithm actively processes it. The plaintext never appears in the processor, application memory, or any intermediate state outside a protected boundary. Three approaches dominate:
Trusted Execution Environments (TEEs)
A trusted execution environment is a hardware-based security boundary. Code runs inside an isolated enclave; the processor guarantees that not even the hypervisor or operating system can read enclave memory. Data decrypts only inside the enclave, computation happens, and results are encrypted before leaving.
Examples include Intel SGX, AMD SEV, and ARM TrustZone. TEEs run at near-native speed with strong isolation. The trade-off is capacity: enclave memory is constrained, so TEEs suit bounded workloads – key processing, authentication, small defined algorithms – better than large-scale analytics or model training.
Fully Homomorphic Encryption (FHE)
Fully homomorphic encryption allows computation directly on encrypted data. You encrypt data, send it to a server, the server computes on the ciphertext without ever decrypting it, and returns an encrypted result only you can decrypt.
The advantage is complete protection: data never decrypts outside the owner’s control. FHE is production-ready today, deployed in financial services, healthcare, and government workloads. The practical consideration is latency – computation is slower than plaintext, but optimized implementations return results in seconds for the right query patterns, while heavier workloads suit batch analytics and periodic reporting. The key is matching the cryptographic approach to the workload.
Secure Multi-Party Computation (MPC)
Secure multi-party computation lets multiple parties compute over their combined data without any party seeing the others’ inputs. Party A holds X, Party B holds Y; they jointly compute a function over both without either learning what the other holds.
MPC is production-ready and widely used in financial services and research collaboration. It is faster than FHE for many collaborative workloads and excels at secure aggregation, matching, comparisons, and statistical analysis. The operational difference: all parties must be online and coordinated during computation.
Architecture Note:
No single technology solves every data in use challenge. Organizations typically combine TEEs, FHE, MPC, federated learning, and governance controls to balance security, performance, compliance, and collaboration. The orchestration layer – who can compute what, on which data, with what auditability – is where most deployments succeed or fail.
Data at Rest vs In Transit vs In Use: Side-by-Side Comparison
| Data at Rest | Data in Transit | Data in Use | |
| What it is | Stored data (databases, backups, cloud storage) | Data moving across networks | Data being actively processed |
| Standard protection | AES-256 | TLS 1.3 | TEEs, FHE, MPC |
| Threat model | Storage theft, direct DB access | Interception, man-in-the-middle | Insider access, compromised hosts, untrusted infrastructure |
| Maturity | Standard, decades old | Standard, decades old | Production-ready, rapidly maturing |
| Performance cost | Negligible | Negligible | Varies: TEEs near-native; FHE seconds-to-batch; MPC needs coordination |
| Where it stops | At retrieval — decrypted for use | At the endpoint — destination gets plaintext | Protected through processing |
The mistake most organizations make is assuming “encrypted” means “secure.” A bank with encrypted databases and TLS everywhere still exposes data the moment analysts query it. A hospital that encrypts records at rest and transfers them over TLS still hands plaintext to the ML pipeline at the destination – encryption at rest and in transit provided no real protection for the collaborative use case.
When Each Encryption Type Matters: A Decision Framework
Start from the state that creates the risk you are solving.
Use encryption at rest when:
- Data is stored long-term and must survive theft of the storage medium
- Access is mediated by an application that handles decryption
- Compliance requires encryption for stored data (most regulations do)
Use encryption in transit when:
- Data crosses untrusted networks
- You need to authenticate the receiving endpoint
- You cannot control every network hop
Use data in use protection when:
- Data must be processed by systems you do not fully control
- Multiple parties need to collaborate without exposing plaintext to each other
- Compliance demands true zero-trust – the service provider must never see the data – a model explored further in zero trust data protection
- Requirements like data sovereignty prevent data from leaving its jurisdiction, but analysis still has to happen
The three are not mutually exclusive. A production system uses all three: encrypt at rest, encrypt in transit, and protect in use wherever data crosses organizational boundaries.
Encryption Is Architectural, Not Just Cryptographic
The cryptography is the smallest part of the problem. The harder part is orchestration: who can compute what, on which data, for which purposes, with what auditability.
A bank using confidential computing to share trading signals needs to enforce: “Algorithm A can run on my portfolio data, for Partner B, and only the aggregated result leaves my system.” That enforcement lives in the governance layer, not in the encryption itself — the same discipline that an AI governance framework brings to model deployment.
In practice the weak points are operational: keys that never rotate, certificates that aren’t validated, and no answer to “what algorithm ran on this data last week?” Breaches tend to exploit the gaps between encrypted states – data protected at rest and in transit, but exposed during processing – rather than the encryption algorithms themselves.
This pattern repeats across regulated industries. Banks pursue secure financial analytics – pooled fraud signals and cross-institution analysis without sharing raw positions. Hospitals and pharma need healthcare AI collaboration – multi-institution research without moving patient data. Agencies need cross-domain collaboration that respects classification boundaries. In each case the cryptography exists; what decides success is the operational layer around it.
How Duality Helps Secure Data in Use
Duality Technologies provides the complete stack: the cryptographic boundary plus the orchestration and governance layer where most deployments fall short.
In practice: you define what data can be accessed, by whom, for what purpose, and Duality enforces it at computation time. Data stays where it lives. Only the authorized algorithm runs. Only the specified output leaves. Every computation is logged and auditable, permissions are revocable instantly, and cross-border collaboration is enforced cryptographically rather than contractually – the foundation of secure AI collaboration across organizations.
The hard part of data in use protection is not the math – the math works. The hard part is making governance real, audit verifiable, and policy enforceable. That is the complete solution Duality ships.
The Future of AI Depends on Protecting Data in Use
Data in use protection is one component of a broader secure AI architecture. Organizations also need governance, privacy-enhancing technologies, and secure collaboration models that allow sensitive data to be used safely. Continue exploring how these capabilities work together in modern AI environments.
