Data Encryption at Rest: Standards and Implementation

Data encryption at rest refers to the cryptographic protection of stored data — files, databases, backups, and disk volumes — when that data is not actively moving across a network. Federal agencies including NIST, HHS, and the PCI Security Standards Council each impose specific requirements on how organizations must protect stored data, making compliance with at-rest encryption standards a structural obligation across healthcare, finance, and government contracting. This page covers the technical definition, operational mechanisms, deployment scenarios, and the criteria that determine which encryption approach applies in a given context.

Definition and scope

Encryption at rest protects data that resides on a physical or virtual storage medium: hard drives, SSDs, NAS arrays, cloud object storage buckets, and database tables. The mechanism renders stored data unreadable without possession of the appropriate cryptographic key, regardless of whether the storage medium is stolen, improperly decommissioned, or accessed by an unauthorized system process.

The scope of at-rest encryption spans three primary storage layers:

  1. Full disk or volume encryption — protects an entire storage volume at the block level, transparent to the operating system above it.
  2. Database encryption — applied at the database engine level, either to entire tablespaces or individual columns containing sensitive fields.
  3. File-level and object-level encryption — applied to specific files or objects, leaving non-sensitive data unencrypted and reducing performance overhead.

NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices, defines these layers and provides the technical basis for selecting among them. The scope is distinct from data encryption in transit, which addresses data moving between systems over networks, and from end-to-end encryption architectures, though the two are frequently deployed in combination.

How it works

At-rest encryption operates through a symmetric cipher applied to data before it is written to a storage medium, with decryption occurring when an authorized process reads the data back. The dominant algorithm in enterprise and government deployments is AES (Advanced Encryption Standard) with a 256-bit key, standardized by NIST in FIPS 197 (Federal Information Processing Standard 197). AES-256 provides 2²⁵⁶ possible key combinations, a keyspace considered computationally intractable under classical computing assumptions.

The operational sequence follows these discrete phases:

  1. Key generation — a cryptographically random key is created, typically by a hardware or software random number generator meeting NIST SP 800-90A standards.
  2. Key storage — the key is stored separately from the data it protects, commonly in a Hardware Security Module (HSM) or a dedicated key management service.
  3. Encryption at write time — data is encrypted before or during the write operation to the storage medium; this can occur at the application layer, the database engine, the filesystem, or the hardware controller.
  4. Authentication and access control — access to the decryption key is gated by identity verification, ensuring that only authorized processes or users retrieve plaintext.
  5. Decryption at read time — when an authorized entity requests data, the key management system releases the key, and the cipher decrypts the ciphertext to plaintext in memory.
  6. Key rotation and lifecycle management — keys are rotated on a scheduled or event-triggered basis; retired keys are revoked and archived per the cryptographic key lifecycle policy in effect.

The encryption key management layer is operationally the most consequential phase. Encryption is only as strong as the protection and governance of the keys themselves; a well-implemented AES-256 cipher broken by poor key custody represents a complete protection failure.

Common scenarios

Healthcare (HIPAA) — The HHS Office for Civil Rights identifies encryption of electronic protected health information (ePHI) stored on workstations, servers, and portable devices as an addressable implementation specification under 45 CFR §164.312(a)(2)(iv) (HHS HIPAA Security Rule). In practice, covered entities treat at-rest encryption as a de facto requirement given enforcement patterns in breach investigations.

Payment Card Industry — PCI DSS Requirement 3.5 mandates that primary account numbers (PANs) stored in any form must be rendered unreadable using strong cryptography. The PCI Security Standards Council specifies AES-256, Triple-DES 112-bit minimum, or RSA with 2048-bit keys as acceptable options.

Federal government systems — FIPS 140-2 and its successor FIPS 140-3 establish validation requirements for cryptographic modules used in federal information systems (NIST CMVP). Agencies operating under FedRAMP must implement FIPS 140-validated encryption for data at rest in cloud environments.

Cloud object storage — Major cloud providers offer server-side encryption (SSE) using either provider-managed keys (SSE-S3, SSE-KMS) or customer-managed keys under a Bring Your Own Key (BYOK) model. BYOK shifts key custody to the organization but also shifts operational responsibility for key availability.

Backup and archival data — Backup datasets frequently contain the same sensitive records as production systems and require equivalent protection. Encryption for backup and recovery involves encrypting backup streams before writing to tape or cloud storage, with key management procedures that guarantee recovery without depending on the encrypted backup itself.

Decision boundaries

Selecting an at-rest encryption approach depends on four classifiable factors:

Granularity vs. performance trade-off — Full-disk encryption imposes lower per-operation overhead but provides no protection against authorized-user abuse at the application layer. Column-level database encryption protects individual sensitive fields even from database administrators but adds query complexity and latency. Organizations protecting a narrow set of fields (Social Security numbers, PANs, health record numbers) typically favor column-level or tokenization over full-disk approaches.

Key management model — Provider-managed keys reduce operational burden but mean the storage provider can technically access plaintext. Customer-managed keys via an HSM or external KMS restore organizational control at the cost of operational complexity. Regulated industries handling classified or highly sensitive data generally require customer-controlled key management.

FIPS validation requirement — Federal contractors and agencies must use FIPS 140-2 or FIPS 140-3 validated modules. Non-validated implementations of AES-256, even if technically identical in algorithm, do not satisfy this requirement under FIPS 140 standards.

Data classification scope — Not all stored data carries equal regulatory exposure. An encryption policy that applies the same cipher and key management overhead to public documents as to ePHI or cardholder data wastes resources. A tiered approach — applying stronger controls to classified or regulated data subsets — aligns protection cost with actual risk exposure.

The distinction between at-rest and full-disk encryption implementations matters at the architecture level: full-disk encryption protects against physical theft of media but does not protect data from a logged-in, authenticated attacker. Application-layer or database-layer encryption addresses that threat model at the cost of greater implementation complexity.

References

Explore This Site

Regulations & Safety Regulatory References