Cloud Data Encryption: At Rest, In Transit, and In Use

Cloud data encryption spans three operationally distinct states — data at rest, data in transit, and data in use — each governed by separate cryptographic mechanisms, regulatory obligations, and implementation requirements. This page maps the technical structure, classification boundaries, and compliance context of all three encryption domains as they apply to US-based cloud deployments. The distinctions among these states are foundational to cloud security architecture, and misclassifying them produces verifiable gaps in protection posture.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix
• References

Definition and scope

Cloud data encryption is the application of cryptographic algorithms to data stored, transmitted, or processed within cloud infrastructure, transforming plaintext into ciphertext that is unreadable without the corresponding decryption key. The practice is not a single control but a family of three functionally separate disciplines, each targeting a different phase of the data lifecycle.

NIST SP 800-111 defines storage encryption and documents baseline requirements for protecting data at rest on storage devices. NIST SP 800-52 governs the selection of Transport Layer Security (TLS) configurations for data in transit. Data in use — the most technically recent domain — is addressed under the broader confidential computing framework, which NIST examines in its NIST IR 8320 report on hardware-enabled security.

The regulatory scope for cloud encryption in the United States draws from at least four distinct frameworks: HIPAA's Security Rule (45 CFR § 164.312), which treats encryption as an addressable implementation specification for covered entities; the FedRAMP baseline controls, which mandate FIPS 140-2 validated cryptographic modules for federal systems; PCI DSS, published by the PCI Security Standards Council, which requires strong cryptography for cardholder data; and the NIST Cybersecurity Framework (CSF 2.0), which classifies encryption under the Protect function. Cloud compliance and regulations define which framework applies to a given deployment.

Core mechanics or structure

Encryption at rest protects data stored on physical or virtual media — block storage volumes, object stores, database files, and backup archives. The dominant algorithm for at-rest encryption is AES-256 (Advanced Encryption Standard with a 256-bit key), which NIST FIPS 197 standardized. Two architectural modes govern key management: server-side encryption (SSE), in which the cloud provider manages keys on the customer's behalf, and customer-managed keys (CMK), in which the customer controls key material through a dedicated key management service. A third variant, client-side encryption, encrypts data before it leaves the customer's environment entirely.

Encryption in transit protects data moving across networks — between a client and a cloud endpoint, between cloud services within a region, or across inter-region links. TLS 1.2 and TLS 1.3 are the operative standards; NIST SP 800-52 Rev. 2 explicitly deprecates TLS 1.0 and 1.1 for federal systems. The TLS handshake establishes cipher suites, authenticates the server (and optionally the client), and derives session keys. Mutual TLS (mTLS) extends this by requiring certificate-based authentication on both ends, a pattern common in microservices and cloud networking architectures.

Encryption in use (confidential computing) protects data while it is actively being processed in memory, preventing even a privileged cloud operator from reading workload data. This is achieved through hardware-enforced Trusted Execution Environments (TEEs) — Intel SGX, AMD SEV, and ARM TrustZone are the principal implementations. The Confidential Computing Consortium, a Linux Foundation project, maintains open specifications for TEE interoperability.

Key management infrastructure is the connective tissue across all three states. NIST SP 800-57 Part 1 establishes key lifecycle guidance covering generation, distribution, storage, rotation, revocation, and destruction.

Causal relationships or drivers

The three-state encryption model emerged as a response to specific, documented failure modes. Data-at-rest encryption became standard after physical media theft and improper decommissioning were identified as leading causes of regulated data exposure — a pattern reflected in HHS breach portal data covering HIPAA-regulated entities. Transit encryption accelerated after the 2013-era disclosures regarding mass interception of unencrypted backbone traffic, after which major cloud providers committed to encrypting all inter-datacenter traffic by default.

Confidential computing addresses a structural gap that at-rest and in-transit encryption cannot close: the processing environment itself. In a standard cloud VM, the hypervisor and cloud operator have theoretical visibility into memory contents during execution. TEE-based encryption in use eliminates this exposure vector, which is particularly relevant for regulated workloads in healthcare, financial services, and government sectors.

Regulatory escalation is a second driver. The HIPAA Security Rule's addressable encryption specification has been interpreted by HHS Office for Civil Rights (OCR) as a near-mandatory control given the ubiquity of threat vectors — a position reinforced by OCR enforcement actions. FedRAMP's FIPS 140-2 module requirement (now transitioning to FIPS 140-3) applies to all cryptographic operations in federal cloud systems, creating a de facto floor for commercial providers hosting government workloads.

The structure of cloud identity and access management is directly coupled to encryption effectiveness: key access controls determine whether cryptographic protections hold under insider-threat scenarios.

Classification boundaries

Cloud encryption variants are classified along four axes:

1. Data state: at rest / in transit / in use — mutually exclusive by definition; protecting one state does not protect the others.
2. Key custody: provider-managed / customer-managed / client-side — determines who can decrypt data and under what legal compulsion.
3. Cryptographic standard: symmetric (AES-256 dominant) vs. asymmetric (RSA-2048, ECC P-256) — asymmetric algorithms govern key exchange and certificate infrastructure rather than bulk data encryption.
4. Hardware vs. software implementation: FIPS 140-2/3 validated hardware security modules (HSMs) vs. software-only key management — the former required for FedRAMP High baselines.

These axes are independent: a system can use AES-256 for at-rest encryption with provider-managed keys in a software KMS (one configuration) or AES-256 for at-rest encryption with customer-managed keys in a dedicated HSM (a different configuration with different compliance posture). Cloud data management frameworks typically define data classification tiers that map to specific encryption configuration requirements.

Tradeoffs and tensions

Performance vs. security depth: Encryption adds computational overhead. AES-NI hardware acceleration on modern processors reduces this materially, but TEE-based confidential computing imposes measurable latency penalties — Intel SGX in particular introduces enclave context-switch overhead that affects throughput-sensitive workloads. Cloud performance optimization engineering must account for these costs explicitly.

Key control vs. operational convenience: Customer-managed keys give organizations cryptographic sovereignty but transfer the operational burden of key availability, rotation, and disaster recovery. A lost or inaccessible CMK renders the encrypted data permanently unrecoverable — a risk that provider-managed keys eliminate at the cost of reduced control. Cloud disaster recovery planning must treat key availability as a tier-1 dependency.

Encryption scope vs. auditability: End-to-end encryption and client-side encryption, while maximally protective, can impair the ability of cloud-native monitoring and logging tools to inspect traffic for threat detection. This creates a direct conflict between the Protect and Detect functions of the NIST Cybersecurity Framework. Cloud monitoring and observability architectures typically require decryption at inspection points, which must be governed by policy.

Algorithm longevity: NIST's post-quantum cryptography standardization effort — which in 2024 finalized CRYSTALS-Kyber (ML-KEM), CRYSTALS-Dilithium (ML-DSA), and SPHINCS+ (SLH-DSA) as FIPS 203, 204, and 205 — signals that current RSA and ECC-based key exchange mechanisms will require migration. Cloud providers and federal agencies are under active pressure to implement crypto-agile architectures that can transition algorithm suites without full system redesign.

Common misconceptions

Misconception: HTTPS on an endpoint means all data is encrypted at rest. TLS terminates at the cloud load balancer or API gateway. Without separate at-rest encryption configuration on the backing storage, data may sit in plaintext on disk behind the TLS boundary. These are independent controls.

Misconception: Provider-managed encryption is equivalent to customer-controlled encryption for compliance purposes. HIPAA OCR guidance and FedRAMP control baselines distinguish between encryption where the provider holds keys and encryption where the covered entity or agency holds keys. For HIPAA, provider access to keys can constitute a disclosure requiring a Business Associate Agreement; for FedRAMP High, SC-12 and SC-28 controls specify key ownership requirements.

Misconception: Encrypting a database means queries against it are also protected. Standard database encryption (transparent data encryption, or TDE) protects the physical files on disk — not the query processing layer. Querying an encrypted database decrypts data in memory for processing, which is precisely the gap that confidential computing addresses.

Misconception: TLS 1.2 and TLS 1.3 are interchangeable. TLS 1.3 eliminates RSA key exchange, removes cipher suite negotiation for obsolete algorithms, and reduces handshake round-trips from 2 to 1. NIST SP 800-52 Rev. 2 recommends TLS 1.3 as the preferred configuration for federal systems.

Misconception: Encryption alone satisfies data protection obligations. Encryption is one control within a broader cloud shared responsibility model. Access control, audit logging, key management, and incident response are co-equal requirements under frameworks such as NIST SP 800-53 Rev. 5.

Checklist or steps (non-advisory)

The following operational sequence represents the standard phases of cloud encryption implementation as documented in NIST SP 800-57 and FedRAMP control guidance:

1. Data classification — Assign sensitivity levels to data assets per organizational policy; map classifications to encryption requirements (e.g., PII → AES-256 at rest + TLS 1.2+ in transit minimum).
2. Key management architecture selection — Determine key custody model (provider-managed, customer-managed via cloud KMS, or HSM-backed CMK) based on regulatory baseline and risk tolerance.
3. Algorithm and protocol selection — Confirm algorithm selections against NIST FIPS 197 (AES), FIPS 186-5 (digital signatures), and SP 800-52 Rev. 2 (TLS configuration); align with FIPS 140-2/3 module requirements where applicable.
4. Storage encryption configuration — Enable server-side encryption on all block, object, and file storage resources; verify encryption-at-rest coverage via provider configuration audit tools.
5. Transit encryption enforcement — Configure TLS minimum version policies at load balancers, API gateways, and service mesh layers; disable TLS 1.0/1.1 at policy level.
6. Key lifecycle management — Define and enforce rotation schedules (NIST SP 800-57 recommends cryptoperiods based on algorithm and usage); document revocation procedures.
7. Confidential computing scope assessment — Identify workloads processing regulated data in memory; evaluate TEE suitability against performance and compatibility requirements.
8. Audit and logging — Enable key usage logs and cryptographic operation audit trails; integrate with centralized cloud monitoring and observability pipelines.
9. Compliance mapping — Cross-reference implemented controls against applicable framework baselines (FedRAMP, HIPAA, PCI DSS) using a control mapping matrix.
10. Crypto-agility planning — Document algorithm dependencies; establish migration pathway for post-quantum algorithm adoption per NIST FIPS 203/204/205.

The Cloud Encryption reference section of this domain provides further detail on algorithm selection and provider-specific implementation patterns. For broader infrastructure context, the site index maps all topic areas covered across this domain.

Reference table or matrix

Compliance applicability matrix: