Data Encryption at Rest: Standards and Implementation

Encryption at rest refers to cryptographic protection applied to stored data — on physical drives, database volumes, backup media, and cloud object storage — as distinct from data moving across networks. This page covers the definition and regulatory scope of at-rest encryption, the technical mechanisms through which it operates, the organizational scenarios where it applies, and the decision boundaries that govern algorithm selection and implementation architecture. Regulatory mandates from NIST, HIPAA, and PCI DSS make at-rest encryption a compliance requirement across federal systems, healthcare, and payment card environments, not merely a security best practice.

Definition and scope

Data encryption at rest is the application of cryptographic algorithms to data in a stored state — meaning data not actively traversing a network. The protected surface includes hard disk drives, solid-state drives, database files, backup tapes, removable media, and cloud storage volumes. When a disk is powered down, removed, lost, or stolen, encryption at rest ensures that the stored contents remain unintelligible without the corresponding decryption key.

NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices, establishes the foundational taxonomy for this domain, distinguishing full-disk encryption, volume encryption, file/folder encryption, and database encryption as discrete implementation layers. The regulatory mandate extends broadly: the HIPAA Security Rule (45 CFR § 164.312(a)(2)(iv)) identifies encryption of stored electronic protected health information (ePHI) as an addressable specification, while PCI DSS Requirement 3.5 mandates cryptographic protection of stored primary account numbers (PANs). Federal systems must conform to FIPS 140-3, the standard governing cryptographic module validation under NIST oversight.

The encryption providers on this network catalogue service providers whose offerings are scoped specifically to these regulatory environments.

How it works

At-rest encryption operates by applying a symmetric cipher — most commonly AES (Advanced Encryption Standard) — to data blocks, files, or entire volumes before they are written to storage media. AES-256, the 256-bit key variant, is the approved algorithm under FIPS 197 and is referenced throughout NIST guidance as the minimum-strength standard for protecting sensitive federal information.

The encryption process follows a discrete operational structure:

1. Key generation — A cryptographic key is generated using an approved random number generator, typically conforming to NIST SP 800-90A, which specifies deterministic random bit generators.
2. Key storage and management — The encryption key is stored separately from the encrypted data, either in a hardware security module (HSM), a key management service (KMS), or a trusted platform module (TPM). Storing the key alongside the ciphertext defeats the protection.
3. Encryption operation — The plaintext data is processed through the AES cipher in an approved mode. AES-GCM (Galois/Counter Mode) is preferred for authenticated encryption; AES-CBC (Cipher Block Chaining) remains in legacy deployments but lacks built-in integrity verification.
4. Storage write — The ciphertext is written to the storage medium. All subsequent reads require key access and decryption before the data is usable by an application.
5. Key rotation — Per NIST SP 800-57 Part 1 Rev 5, cryptographic keys have defined lifecycle stages, and rotation or re-keying is required on a schedule aligned with the sensitivity of the protected data.

The distinction between software-based encryption and hardware-based encryption is operationally significant. Software encryption (e.g., BitLocker, dm-crypt) runs at the OS layer and imposes CPU overhead. Hardware encryption, implemented in self-encrypting drives (SEDs) conforming to the Trusted Computing Group's OPAL standard, executes at the drive controller level and does not impose measurable performance degradation. SEDs are recognized in NIST SP 800-111 as an approved implementation path for end-user device storage protection.

Common scenarios

At-rest encryption applies across four primary organizational contexts, each with distinct regulatory and architectural characteristics:

Healthcare data stores — Covered entities under HIPAA must protect ePHI stored in electronic health record (EHR) databases, backup repositories, and removable media. While HIPAA classifies encryption as "addressable" rather than "required," the Office for Civil Rights (OCR) at HHS has consistently treated absence of encryption as a contributing factor in breach penalty determinations. The HHS Breach Notification Rule (45 CFR § 164.400–414) provides a safe harbor for breaches involving encrypted data that meets NIST standards.

Payment card environments — PCI DSS Requirement 3 governs the protection of stored cardholder data. Merchants and processors storing PANs must render them unreadable using strong cryptography, with AES-256 as the recognized standard. The PCI Security Standards Council publishes the current DSS version governing these requirements.

Federal information systems — Federal agencies operating systems under FISMA must apply encryption at rest per the controls defined in NIST SP 800-53 Rev 5, specifically control SC-28 (Protection of Information at Rest), which mandates cryptographic protection for classified and CUI (Controlled Unclassified Information) data stored on federal systems.

Cloud storage environments — Cloud-hosted data presents a shared-responsibility model. Infrastructure providers typically offer server-side encryption (SSE), but control over key material — whether managed by the provider or by the tenant via customer-managed keys (CMK) — determines the actual security boundary. The FedRAMP authorization program requires FIPS 140-validated encryption for cloud services serving federal agencies.

Further context on how these scenarios intersect with service provider qualifications is documented in the reference.

Decision boundaries

Selecting an at-rest encryption implementation requires resolving four structural decision points:

Algorithm and key length — AES-256 is the baseline for any regulated environment. AES-128 remains mathematically sound but is disfavored in high-sensitivity contexts. Triple-DES (3DES) was deprecated by NIST for new applications as of 2023 (NIST SP 800-131A Rev 2) and must not be used in new implementations. RSA and ECC are asymmetric algorithms relevant to key wrapping and exchange, not to bulk data encryption at rest.

Hardware vs. software encryption — SEDs eliminate CPU overhead and enforce encryption at a layer below the OS, providing stronger protection against software-layer attacks. However, SED key management is often tied to drive firmware, creating recovery complexity if the drive controller fails. Software encryption provides greater operational flexibility and portability across hardware but depends on OS integrity.

Key management architecture — Centralized KMS platforms (including cloud-native services like AWS KMS or on-premises HSMs conforming to FIPS 140-3 Level 3) separate key custody from data custody. This separation is the defining requirement that makes encryption at rest meaningful: if the attacker who obtains the disk also obtains the key, the encryption provides no protection.

Scope of encryption — Full-disk encryption (FDE) protects all data on a volume uniformly but does not prevent access by authenticated OS users. Transparent database encryption (TDE) operates at the database engine layer. File-level or column-level encryption provides granular control and is required in environments where different data classifications coexist on shared infrastructure. NIST SP 800-111 maps these layers explicitly to threat scenarios, distinguishing between offline threats (lost or stolen media) and online threats (authenticated but unauthorized access), with the latter requiring more granular controls.

The how to use this encryption resource page documents how these technical distinctions map to the service categories indexed across this network.