Encryption: At Rest, In Transit, and In Use
Concept
Data has three distinct states, and each needs a different encryption mechanism because each is exposed to a different attacker — "we encrypt our data" is meaningless without specifying which of the three is actually covered:
- At rest — data persisted in non-volatile storage: databases, object storage, disks, backups, archives. Protects against an attacker who gets physical or logical access to the storage medium itself (a stolen disk, a misconfigured public S3 bucket, a compromised backup). Implemented via storage-layer encryption (disk/volume encryption, database transparent data encryption, object-store server-side encryption), managed through a key management service (AWS KMS, Azure Key Vault, HashiCorp Vault) rather than application-hand-rolled crypto.
- In transit — data moving between components, services, or across a network. Protects against an attacker positioned on the network path (a compromised router, a man-in-the-middle, unencrypted traffic sniffed on a shared network). Implemented via TLS for any traffic crossing a trust boundary — public internet, but increasingly service-to-service traffic inside a cluster too, via mTLS in a service mesh.
- In use — data actively loaded in memory while a process computes on it. Protects against an attacker who has compromised the host or hypervisor itself and can read process memory directly — a threat model the other two states don't address at all, since at-rest and in-transit encryption both necessarily decrypt data before a CPU can operate on it. Implemented via confidential computing (hardware-backed trusted execution environments like Intel SGX, AMD SEV, or AWS Nitro Enclaves) that keep memory encrypted even from a privileged host OS or cloud provider.
Tradeoffs
| State | Threat addressed | Typical mechanism | Performance cost | Maturity |
|---|---|---|---|---|
| At rest | Stolen/leaked storage medium, misconfigured storage access | Disk/volume encryption, DB TDE, object-store SSE, KMS-managed keys | Low — largely offloaded to storage hardware/hypervisor | Mature, table stakes |
| In transit | Network-path interception, MITM | TLS (client-facing), mTLS (service-to-service) | Low-moderate — TLS handshake + ongoing encrypt/decrypt overhead | Mature, table stakes |
| In use | Compromised host/hypervisor reading live memory | Confidential computing / TEEs (SGX, SEV, Nitro Enclaves) | Meaningful — TEEs add real CPU/memory overhead and constrain what can run inside them | Emerging — far less commonly deployed, real operational friction |
The three states aren't substitutes for each other — they're additive coverage of an attacker's position (storage medium, network path, host memory), and the practical maturity gap is real: at-rest and in-transit are now close to default expectations in any serious system, while in-use protection is still the exception, reached for specifically when the threat model includes an untrusted host/hypervisor operator (a regulated workload on shared cloud infrastructure, a multi-party computation scenario) rather than applied by default.
When to use / when not to
- Encrypt at rest and in transit by default on essentially everything — the cost is low, the tooling is mature (KMS, TLS termination at the load balancer/gateway), and the absence of either is now a compliance red flag in most regulated contexts (PCI-DSS, HIPAA, SOC 2) rather than a defensible tradeoff.
- Reach for confidential computing / in-use encryption specifically when the threat model includes an untrusted infrastructure operator — multi-party data processing where no single party (including the cloud provider) should see plaintext, or regulated workloads where "the cloud provider's own employees" is explicitly in scope as a threat actor.
- Don't reach for in-use encryption as a default for ordinary application workloads — the performance overhead and operational complexity (constrained runtime inside a TEE, specialized tooling) is a real cost that only pays off against that specific host-compromise threat model.
- Layer key management correctly regardless of state: encryption is only as strong as key custody — at-rest encryption with keys stored next to the encrypted data, or TLS with a poorly managed certificate chain, both defeat the point structurally, independent of the algorithm's strength.
Common pitfall
Treating "encryption" as a single checkbox rather than three separate coverage claims — a system that encrypts data at rest and calls it "fully encrypted" can still leak plaintext over an internal, unencrypted service-to-service call, because at-rest encryption says nothing about what happens to the data once an application layer reads and forwards it. A security review needs "at rest: yes, in transit: yes/where, in use: yes/no" as three explicit answers, not one.
Engineering Lens
The Principal-level move in a security review is separating "which of the three states are covered" from "what threat actor does each one actually defend against" — encryption at rest is useless against a network attacker, and TLS in transit is useless against a stolen disk, so listing "we use encryption" without naming the state and the corresponding threat is a claim with no verifiable content. This maps directly onto defense in depth (Defense in Depth): each encryption state is one more layer that has to fail before an attacker gets plaintext, and a mature answer names exactly which layer is missing and why (usually in-use, and usually because the threat model doesn't yet include an untrusted infrastructure operator). In Fintech/Capital Markets specifically, in-use encryption is increasingly the differentiator conversation — multi-party settlement and confidential trading computations are exactly the scenario where "the cloud provider itself must not see plaintext" becomes a genuine, not theoretical, requirement.