Data at Rest Encryption: How It Works and Best Practices
A laptop full of customer files is stolen from a car. If it was encrypted, the thief has hardware. If not, you have a breach. Data at rest encryption scrambles stored data on disks, databases, backups and cloud storage so it is unreadable without the key. It stops that theft. It does not stop a logged-in attacker.
What Is Data at Rest?
Data at rest is information that is stored rather than moving or being processed. It sits on laptop drives, servers, databases, USB drives, backup tapes and cloud storage until someone opens it. Because it stays in one place for a long time and often in large volumes, data at rest is a prime target for theft, loss and unauthorized access.
Examples of Data at Rest
- Files on laptops, desktops and file servers
- Customer and finance databases
- Email archives
- Backups, snapshots and archive storage
- Objects in cloud storage such as Amazon S3 or Azure Blob Storage
- USB drives and retired hard drives
Why Data at Rest Is a High-Value Target
Stored data is where the volume is. One database or backup can hold every customer record you have, while data in transit usually exposes a small piece at a time. IBM’s Cost of a Data Breach Report 2025 found customer personally identifiable information (PII) was the data type most often compromised, in 53% of breaches studied.
Data at Rest vs Data in Transit vs Data in Use
| State | What it means | Example | Main protection |
|---|---|---|---|
| At rest | Stored on a device or service | A database file on a server | Storage encryption, access control |
| In transit | Moving across a network | A file uploaded to a cloud app | TLS, VPNs (IPsec), SSH |
| In use | Open in memory while being processed | A spreadsheet being edited | Access control, MFA, confidential computing |
Data moves between all three states constantly. A file is at rest on a server, in transit when downloaded, in use when opened, then at rest again on the laptop. Each state needs its own control.
What Is Data at Rest Encryption?
Data at rest encryption converts stored data into ciphertext using an algorithm and a key, so anyone who gets the storage without the key sees only scrambled bytes. Authorized users and applications decrypt it automatically when they open it. It protects against lost or stolen devices, discarded drives, stolen backups and some cloud storage mistakes.
The Contrarian Truth: What Encryption at Rest Does Not Protect Against
Here is the point most guides bury. Encryption at rest protects data when the storage is taken away from its system. It does almost nothing when the attacker comes in through the system.
If someone logs in with a stolen password, the operating system or database decrypts files for them, just as it does for you. Ransomware running under a user’s account reads decrypted files and encrypts them again with its own key. An application with a SQL injection flaw returns decrypted rows. A misconfigured cloud bucket that grants public read access can serve objects that are encrypted at rest, because the service decrypts them for any request it allows.
That leads to a decision rule worth writing into your policy:
- Encryption at rest answers “what if the disk, backup or device leaves our control?”
- Access control and MFA answer “what if someone logs in who should not?”
- Monitoring answers “how fast will we notice?”
If a control plan answers only the first question, it is not a data protection plan. Fund all three. When a vendor or auditor says “the data is encrypted,” ask the follow-up: “Encrypted against whom?”
How Does Encryption at Rest Work?
Symmetric Encryption and AES-256
Storage encryption uses symmetric encryption, where the same key encrypts and decrypts. It is fast enough to protect whole disks without users noticing. The Advanced Encryption Standard (AES), published by NIST as FIPS 197, is the standard choice, usually with 256-bit keys.
Envelope Encryption: DEKs and KEKs
Large systems use envelope encryption. A data encryption key (DEK) encrypts the data. A second key, the key encryption key (KEK), encrypts the DEK. The KEK stays in a protected key store and never sits next to the data. Rotating the KEK does not require re-encrypting every file, which makes key changes practical.
Where Keys Live: KMS, HSM and BYOK
A key management service (KMS), such as AWS KMS, Azure Key Vault or Google Cloud KMS, stores and controls keys and logs every use. A hardware security module (HSM) holds keys inside tamper-resistant hardware. Bring your own key (BYOK) lets you create keys yourself and import them into a cloud provider, while hold your own key (HYOK) keeps keys entirely outside the provider. NIST SP 800-57 is the main guidance on managing key lifecycles.
Types of Data at Rest Encryption
Full-Disk Encryption (BitLocker, FileVault, LUKS)
Full-disk encryption protects the entire drive of a laptop or server. BitLocker (Windows), FileVault (macOS) and LUKS with dm-crypt (Linux) are built in. NIST SP 800-111 (2007) covers storage encryption for end-user devices. This is the first control for any laptop that leaves the office.
File- and Folder-Level Encryption
File-level encryption protects individual files or folders, so they stay encrypted when copied or shared. It suits highly sensitive documents on shared servers.
Database Encryption at Rest (TDE and Column-Level)
Transparent data encryption (TDE), available in SQL Server, Oracle and other major databases, encrypts database and log files on disk without changing applications. Column-level or field-level encryption protects specific fields, such as card or Social Security numbers, so even database administrators cannot read them in plain text.
Cloud Storage Encryption (AWS, Azure, Google Cloud)
Major cloud providers now encrypt stored data by default. Since January 2023, Amazon S3 encrypts all new objects by default. Azure Storage encrypts data automatically, and Google Cloud encrypts customer data at rest by default. The choice left to you is who controls the keys and who can access the data.
Self-Encrypting Drives and Hardware Encryption
Self-encrypting drives (SEDs), often built to the Trusted Computing Group (TCG) Opal specification, encrypt data in the drive hardware. They have little performance cost but depend on firmware quality and correct setup.
Best Practices for Securing Data at Rest
Discover and Classify Sensitive Data First
Find where sensitive data is stored, including forgotten exports and test copies, and label it. Encryption choices follow classification.
Encrypt Every Storage Layer, Including Backups and Snapshots
Backups and snapshots often hold more data than production and get less attention. Encrypt them with the same standard and keys managed the same way.
Separate and Rotate Encryption Keys
Never store keys on the same server or in the same backup as the data. Keep them in a KMS or HSM, limit who can use them and rotate on a set schedule.
Enforce Least-Privilege Access and MFA
Because decryption happens for any authorized user, access control is your main defense against logged-in attackers. Require MFA for every account that can reach sensitive stores.
Use FIPS 140-3 Validated Modules
FIPS 140-3 is the current US and Canadian standard for validating cryptographic modules. US federal agencies and many regulated buyers require it, so check vendor validation certificates.
Monitor, Log and Audit Access
Log key use and bulk data access. A sudden spike in reads from a file server or database is often the earliest sign of data theft.
Securely Dispose of Retired Media
Use NIST SP 800-88 guidance on media sanitization. For encrypted drives, destroying the keys (cryptographic erase) is one recognized method.
Compliance Requirements for Data at Rest in the US and UK
US: HIPAA, PCI DSS and NIST
The HIPAA Security Rule treats encryption as an “addressable” safeguard: implement it, or document why an equivalent measure is reasonable. HHS breach guidance states that PHI encrypted in line with NIST guidance is not “unsecured,” so losing it may not trigger breach notification. PCI DSS Requirement 3 requires stored card numbers to be rendered unreadable, for example with strong cryptography. Obligations vary by sector and state, so confirm with counsel.
UK: UK GDPR Article 32, ICO Guidance and NCSC Advice
UK GDPR Article 32 names encryption as an example of appropriate security. Under Article 34, you may not need to tell affected people about a breach if the data was unintelligible to anyone without access, such as through encryption. The ICO’s guidance on encryption recommends it for personal data, and the National Cyber Security Centre (NCSC) device guidance recommends encrypting devices.
Data at Rest Encryption Checklist for SMBs
- Turn on BitLocker or FileVault on every laptop and confirm recovery keys are stored centrally.
- Encrypt servers, databases and backups, including offsite and cloud copies.
- Move keys to a KMS or HSM and record who can use them.
- Enable MFA on every account that can reach sensitive data.
- Turn on logging for key use and bulk data access.
- Set a disposal process for old drives and devices.
Your Next Move: Encrypt the Storage, Then Lock the Door
Data at rest encryption is the right answer to lost laptops, stolen backups and retired drives, and most regulators expect it. It is only half the answer to the attacker who logs in. Start this week by checking that every company laptop reports encryption as on and that your backups are encrypted, then review who holds the keys. If you want an independent check, Cyber Security Solutions Ltd offers a free data security assessment through our contact page.
FAQs
Usually not by name, but it is often expected. The UK GDPR Article 32 lists encryption as an example of appropriate security, HIPAA treats it as an addressable safeguard and PCI DSS requires stored card numbers to be unreadable. Encryption can also reduce breach notification duties. Confirm the rules for your sector with counsel.
AES is the standard algorithm for data at rest, usually with 256-bit keys. It powers BitLocker, FileVault, database transparent data encryption and cloud storage encryption. Keys are best kept in a key management service or hardware security module, and regulated buyers often require FIPS 140-3 validated modules for the encryption itself.
For most business workloads, the impact is small. Modern processors include hardware acceleration for AES, so full-disk and database encryption run with little visible slowdown. Heavy database workloads may need testing, especially with column-level encryption. The risk of an unencrypted lost laptop or backup is far greater than the performance cost for most organizations.
HTTPS protects data only while it moves between systems. Once it lands on a server, laptop or backup, HTTPS no longer applies. Encryption at rest protects that stored copy if the device or storage is lost, stolen or discarded. Use both: TLS for data in transit and storage encryption for data at rest.
Yes. Database files, logs and backups stored on disk are data at rest, and transparent data encryption protects them there. When an application queries the database, the returned records are data in use and then data in transit. Each state needs its own protection, so database encryption should be paired with access control and TLS.
On the major platforms, yes. Amazon S3 has encrypted all new objects by default since January 2023, and Azure Storage and Google Cloud encrypt stored data by default. Default encryption does not stop access by anyone with valid permissions, so review access policies and decide whether you need customer-managed keys.
