Encryption at Rest vs In Transit vs In Use: What Each State Protects Against

Encryption at rest, in transit and in use protect the same data against three different attackers, and a control that is strong in one state does nothing for the other two. Encryption at rest protects stored data against someone who gets the disk, the backup or the storage bucket without the key. Encryption in transit protects data moving across a network against someone who can watch or alter the traffic. Encryption in use, delivered today mainly through confidential computing, protects data while it sits decrypted in memory against the host, the hypervisor and the operator. It is for architects, cloud and data security engineers and auditors who need to answer "is this data encrypted?" precisely. For algorithms and modes, see the Encryption Guide; this page does not repeat it.

Key takeaways

• Each state answers a different threat. At rest stops theft of media and storage, in transit stops interception and tampering on the wire, in use stops the platform itself from reading memory during processing.
• "Encrypted" is not a yes or no answer. Always ask which state, which keys, and which identities can use those keys: storage encryption with a key every workload role can use stops very little in a cloud breach.
• In transit should be universal, at rest is nearly universal, in use is selective. TLS 1.2 or 1.3 everywhere and default storage encryption are baseline hygiene; confidential computing is a targeted control for workloads where you must reduce trust in the operator.
• Keys and identities decide the real protection. Encryption moves the problem to key custody, so the strength of every state depends on KMS policy, separation of duties and the non-human identities allowed to decrypt.
• The frameworks now name all three. NIST CSF 2.0 has separate outcomes for data at rest (PR.DS-01), in transit (PR.DS-02) and in use (PR.DS-10), so auditors increasingly expect an answer for each.

The short answer

Use encryption in transit for every network hop that carries sensitive data, including internal service to service traffic. Use encryption at rest for every store that holds sensitive data, including backups, snapshots, logs and caches, and choose where the key lives based on who you need to keep out. Use encryption in use (confidential computing) when the threat you must address is the infrastructure itself: a cloud operator, a compromised hypervisor, a privileged administrator or a partner whose data you process but must not see. Most organisations need the first two everywhere and the third for a few high sensitivity workloads.

The Confidential Computing Consortium frames the gap clearly: data is commonly encrypted at rest in storage and in transit across the network, but not while in use in memory. Confidential computing, in the Consortium's definition, protects data in use by performing computation in a hardware-based, attested Trusted Execution Environment (TEE).

Side-by-side comparison

Encryption at rest: what it really protects

NIST SP 800-111 describes storage encryption as using encryption and authentication to limit who can access and use stored data, and groups end user device options into full disk encryption, volume and virtual disk encryption, and file or folder encryption. The same layering applies in data centres and clouds, and the layer you pick determines who the control keeps out.

• Media layer (full disk, self-encrypting drives, cloud volume encryption): protects against someone holding the physical disk or a raw copy of it. Once the system is booted and unlocked, every process with file access reads plaintext. See the Disk Encryption Guide: BitLocker and FileVault and the LUKS Disk Encryption Guide.
• Storage service layer (object storage, managed database encryption, transparent data encryption): protects against storage operators and stolen backups, but the service decrypts for any caller with read permission. The protection is therefore only as narrow as the key policy: if every workload role may call decrypt, storage encryption adds little against a stolen role credential. See the Database and Storage Encryption Guide.
• Application layer (field or record encryption, client-side encryption, tokenisation): the application encrypts before storage, so database administrators, analytics users and storage-layer attackers see ciphertext. This is the layer that survives a compromised database account. See Format Preserving Encryption.

Cipher choice differs by layer. XTS-AES, approved in NIST SP 800-38E for confidentiality on storage devices, provides confidentiality only and does not authenticate the data, which is acceptable for sector-level disk encryption but not for files or fields, where an authenticated mode such as AES-GCM is expected. Most cloud services use envelope encryption: a data key encrypts the data, and a key encryption key held in a KMS or HSM wraps the data key. See the Envelope Encryption and KMS Integration Patterns Guide.

Encryption in transit: what it really protects

Transport encryption protects the session between two endpoints. TLS 1.3 was published as RFC 8446 in 2018 and, in July 2026, re-issued as RFC 9846, which obsoletes RFC 8446. The protocol gives confidentiality and integrity for application data, always authenticates the server and optionally the client, and removed static RSA and static Diffie-Hellman key exchange so that public key exchanges provide forward secrecy. One exception matters in practice: 0-RTT early data is not forward secret and can be replayed, so it should be limited to idempotent requests. See the How TLS Works Guide.

For US federal systems, NIST SP 800-52 Rev. 2 requires servers and clients to support TLS 1.2 with FIPS-based cipher suites and required support for TLS 1.3 by 1 January 2024. NIST marked the publication as under review in May 2026, so check the current revision before relying on its detail.

• External traffic: TLS 1.2 minimum, TLS 1.3 preferred, HSTS on web properties, certificates with automated renewal. Shorter certificate lifetimes make automation mandatory; see the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
• Internal service to service traffic: the most common gap. TLS termination at a load balancer followed by plaintext to the backend leaves the internal hop open to anyone with a foothold. Mutual TLS, often provided by a service mesh, encrypts that hop and gives each workload an identity. See the mTLS Guide.
• Network layer: IPsec or WireGuard for site to site and cloud interconnects, MACsec for physical links you do not control. These protect everything on the link but authenticate devices, not applications.

Transit encryption ends at each endpoint. A TLS-protected upload lands in plaintext on the server unless storage encryption takes over, and a compromised endpoint sees everything.

Encryption in use: what it really protects

To compute on data, a normal system must decrypt it into memory, where the operating system, the hypervisor, the cloud operator and anyone who can dump memory can reach it. Confidential computing changes this by running the workload inside a TEE whose memory is encrypted and isolated by the processor, and by proving through remote attestation what code is running before any secret is released to it. Microsoft's documentation, using the Consortium definition, describes the goal as reducing the trust required in operators and other privileged actors while code and data run.

• Process enclaves: a small, partitioned part of an application runs in the enclave. Strong isolation, but code must be adapted.
• Confidential virtual machines and containers: the whole VM is protected from the host, which allows lift and shift with less code change and a larger trusted code base.
• Cloud enclaves: AWS documents Nitro Enclaves as hardened, highly constrained VMs with no persistent storage, no interactive access and no external networking, reachable only from the parent instance over a local socket. Their key feature for this comparison is attestation-gated key release: a KMS key policy can allow decryption only when the enclave's measurements match.
• Cryptographic approaches: homomorphic encryption and secure multi-party computation let parties compute on data that is never decrypted, at a large performance cost and for limited operations. See the Homomorphic Encryption Guide.

Attestation is what turns hardware isolation into a security control. Without a relying party that checks the measurement and releases keys only to the expected code, a TEE is just an encrypted VM. Code inside the TEE is still trusted: an injection flaw in an enclave application leaks data as freely as anywhere else. See the Confidential Computing Guide and, for model serving, the Confidential AI and GPU Enclaves Guide.

Threat to control mapping

How the three work together

A single record typically passes through all three states. A patient record submitted from a browser travels over TLS 1.3 (in transit), is written to a database with transparent data encryption and a field-level encrypted identifier (at rest), is replicated over mTLS to a reporting cluster (in transit), and is joined with a partner's data inside a confidential VM that only receives the decryption key after attestation (in use). If any hop is skipped, the strongest control elsewhere does not compensate: the data is exposed at the weakest state.

1. Classify the data and trace its path. List every store, every network hop and every processing location for each sensitive data class, including backups, logs, caches, queues and analytics copies.
2. Close transit gaps first. Enforce TLS 1.2 minimum externally, then add internal TLS or mTLS starting with hops that carry credentials and regulated data. Test with a pilot namespace or service in permissive mode before strict mode; roll back by returning the policy to permissive.
3. Confirm at-rest coverage and narrow key access. Verify default encryption on every store, then move high sensitivity data to customer managed keys whose policies name only the identities that must decrypt. Keep the previous key version enabled during re-encryption so you can roll back.
4. Add application-layer encryption where storage access is too broad. Encrypt identifiers and secrets before storage so database and analytics access does not equal plaintext access.
5. Pilot encryption in use for the workloads that need it. Start with one workload, wire attestation to key release, measure performance, and keep a non-confidential fallback path documented and approved before cut over.
6. Prove it continuously. Feed coverage checks into configuration monitoring so new stores and services inherit the controls.

Where identity fits

Every encryption state ends with an identity that is allowed to decrypt. At rest, it is the workload role, service account or database user that the KMS lets call decrypt. In transit, it is the certificate and private key that authenticate each endpoint, which in mTLS is the workload identity itself. In use, it is the attested measurement that a key policy trusts. Over-permissive non-human identities are the most common reason encryption fails in practice: an attacker with a stolen role credential reads plaintext through the front door, and no state of encryption notices. The Capital One breach shows the pattern: a firewall's cloud role credentials were enough to list and read many storage buckets of customer data. The Codefinger S3 ransomware case shows the reverse: leaked long-term keys with read and write permission let an attacker re-encrypt victims' objects with a key only the attacker held. See the Cryptographic Key Management Guide.

Decision guidance

• Small organisations: rely on default cloud storage encryption, managed TLS and certificate automation, and focus effort on key policies and identity hygiene. Encryption in use is rarely the next best investment.
• Large or regulated organisations: separate key administrators from data administrators, use customer managed or external keys for the most sensitive data, standardise internal mTLS, and run confidential computing where contracts, sovereignty rules or multi-party processing require reduced operator trust. See the BYOK, HYOK and External Key Management Guide.

Detection and measurement

• Log: KMS decrypt and key policy change events, storage encryption configuration changes, TLS handshake versions and cipher suites at load balancers and gateways, certificate issuance and expiry, attestation results and failed key release attempts.
• Alert on: encryption turned off or default encryption removed on a store, a key scheduled for deletion, a new principal added to a key policy, unusual decrypt volume by one identity, TLS 1.0 or 1.1 handshakes, and attestation failures followed by retries.

Common failure patterns

• Treating default storage encryption as data protection. Provider-managed keys usable by every role satisfy an audit checkbox but do not stop a credential-based breach. Narrow the key policy or add application-layer encryption.
• TLS at the edge only. Traffic is decrypted at the load balancer and travels in plaintext inside the network, where sniffing and mirroring expose credentials and tokens.
• Keys stored beside the data. Data keys in the same bucket, environment variables or configuration files as the ciphertext turn encryption into obfuscation. See the Encryption Key Compromise Playbook.
• Forgotten copies. Snapshots, exports, logs, message queues and analytics extracts often sit outside the encrypted primary store.
• Confidential computing without attestation checks. Running on confidential instances but delivering secrets through ordinary configuration means the host can still intercept them.
• Write permission overlooked. Encryption features can be turned against you: an identity that can rewrite objects can re-encrypt them with its own key, as the Codefinger case showed. Restrict who can choose encryption settings on write.

Framework mapping

Decision checklist

• For each sensitive data class, can you name every store, hop and processing location, and the encryption state that covers each?
• Is TLS 1.2 the minimum on every external endpoint, with TLS 1.3 enabled and legacy versions disabled?
• Do internal hops carrying credentials or regulated data use TLS or mTLS end to end, not only at the edge?
• Are backups, snapshots, logs and analytics copies encrypted at rest with the same rigour as the primary store?
• For each high sensitivity key, is the list of identities that can decrypt short, owned and reviewed?
• Have you identified workloads where the operator or host must be outside the trust boundary, and is encryption in use with attestation in place for them?

Practitioner checklist

• Build a data flow inventory that records the encryption state at each store, hop and processing step.
• Roll out internal mTLS in permissive then strict mode, starting with flows that carry secrets and regulated data.
• Move high sensitivity data to customer managed keys with key policies that name only required decrypt principals.
• Add field-level or client-side encryption for identifiers and secrets where storage access is broad.
• Restrict who can set or change encryption settings on write, including customer-supplied key options.
• Pilot confidential computing for one workload with attestation-gated key release before wider use.
• Alert on encryption disablement, key deletion scheduling, key policy changes and decrypt spikes.

Standards and references

• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-111, Guide to Storage Encryption Technologies for End User Devices
• NIST: SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of TLS Implementations
• NIST: SP 800-38E, The XTS-AES Mode for Confidentiality on Storage Devices
• IETF: RFC 9846, The Transport Layer Security (TLS) Protocol Version 1.3
• Confidential Computing Consortium: About Confidential Computing
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• AWS: What is Nitro Enclaves?

Related NHI Mgmt Group resources: Encryption Guide · Confidential Computing Guide · Envelope Encryption and KMS Integration Patterns Guide · How TLS Works Guide · Cloud key management service (KMS) health check