How To Encrypt Data At Rest | Lock Down Your Storage

To encrypt data at rest, use dm-crypt with LUKS on Linux or enable default AES-256 encryption in AWS, Azure, and Google Cloud.

A stolen hard drive handed to a stranger should yield nothing readable. A cloud storage bucket misconfigured to the public should expose no actual data. That is what encryption at rest delivers: stored data converted into ciphertext that only the right cryptographic key can unlock. Every major cloud provider now applies it by default, and Linux systems can match that protection with a single command-line tool. The methods differ by platform, but the principle stays the same — encryption at rest is the lock you set and forget, not something you toggle on per file.

What Does “Data at Rest” Encryption Actually Mean?

Data at rest covers everything stored physically — hard drives, SSDs, USB drives, database files, backups, and cloud storage volumes. Encryption at rest converts that data into unreadable ciphertext using an encryption algorithm (typically AES-256) and a cryptographic key, so that unauthorized physical access or theft of the storage media yields zero usable information.

This is different from encryption in transit, which protects data moving across a network. Data at rest encryption protects the files where they sit — whether that is a laptop in a coffee shop or a virtual disk in a data center. Without it, anyone with direct storage access can read everything.

How Does Encryption at Rest Work?

The system generates a unique data encryption key (DEK) for the volume or object, encrypts every block written to the storage medium, and decrypts it on read for authorized users only. The DEK itself is typically wrapped (encrypted) by a separate key encryption key (KEK) stored in a dedicated key management service like Azure Key Vault or AWS KMS, so the storage system never holds the raw unlock key.

For on-premise Linux volumes, the Linux Unified Key Setup (LUKS) format handles this wrapping automatically. The passphrase you enter unlocks the master key stored in the LUKS header, which then decrypts the volume. This layered approach means rotating a KEK re-wraps all DEKs without needing to re-encrypt the entire dataset.

Step-by-Step: Encrypt a Linux Volume With LUKS

The fastest method for Linux disk encryption is dm-crypt with LUKS using the cryptsetup tool. The process takes about five commands and works on any Linux distribution.

1. Install cryptsetup. On Debian or Ubuntu run sudo apt install cryptsetup. On RHEL or Rocky Linux run yum install cryptsetup-luks.
2. Format the target device. Run cryptsetup -y luksFormat /dev/xvda, replacing /dev/xvda with your actual partition path. The -y flag forces a double passphrase entry to catch typos. This command destroys all existing data on the device — verify the device name twice before proceeding.
3. Open the encrypted device. Run cryptsetup luksOpen /dev/xvda encrypted and enter the passphrase when prompted. This maps the encrypted device to /dev/mapper/encrypted.
4. Create a filesystem and mount it. Run mkfs.ext4 /dev/mapper/encrypted to format the decrypted volume, then mount /dev/mapper/encrypted /mnt/encrypted to attach it to the system.
5. Verify. Run df -h | grep mnt/encrypted to confirm the volume is mounted and accessible.

The volume now decrypts on the fly when mounted with the correct passphrase. Every bit written to it stays encrypted on disk.

How Cloud Providers Handle Encryption at Rest

AWS, Azure, and Google Cloud each encrypt stored data by default at no extra cost using platform-managed keys (PMKs) with AES-256. For production environments with compliance requirements, each provider offers customer-managed keys (CMKs) through their key management service — AWS KMS, Azure Key Vault, or Google Cloud KMS. CMKs give you rotation control, audit logging, and the ability to revoke access by disabling the key.

Azure best practices recommend enabling Encryption at host for Azure VMs, which encrypts temp disks and host caches end-to-end. For customer-managed keys in Azure, ensure RSA-OAEP-256 is used as the key-wrapping algorithm instead of the legacy RSA-OAEP with SHA-1, which is now considered insufficient. If a CMK is suspected compromised, rotate to a new key and reconfigure dependent services before disabling the old key to avoid data lockout.

Mistakes That Break Encryption at Rest

The most dangerous error is storing encryption keys on the same system as the encrypted data. If an attacker compromises the server, they grab both the encrypted files and their unlock key simultaneously. Keys must be isolated in a separate key management service like Azure Key Vault or AWS KMS.

Another 2026-era pitfall is applying a flat “annual rotation” policy to all datasets regardless of sensitivity. High-risk data needs faster rotation; low-risk data may not need rotation at all. Mapping where each key is used before setting rotation cadences prevents both over-rotation and under-rotation. A separate but common mistake is exposing keys in CI/CD logs as plain text — credential scanners in pipeline manifests catch this, but the practice persists.

Separation of duties also matters: the person who administers the encrypted data should not also administer the encryption keys. Combining both roles in one team erodes the value of encryption as a control boundary.

Encryption at Rest: Quick Deployment Checklist

A production-ready encryption plan covers four decisions before deployment. Start with the platform choice per workload — LUKS for Linux volumes, BitLocker for Windows, default cloud encryption for cloud storage. Configure key isolation in a dedicated key management service before encrypting any volume. Set rotation cadences by data sensitivity rather than calendar date — quarterly for high-risk datasets, annual or on-demand for everything else. Test full restore from immutable backups at least once per quarter, because encryption that outlives your recovery key is worse than no encryption at all.