Most data breaches don’t happen because attackers broke an advanced algorithm. They happen because data was sitting somewhere, unencrypted, and the wrong person got to it.
That’s the core problem with data at rest. It’s everywhere, databases, backup drives, file servers, cloud storage buckets, and it’s stationary, which makes it an easy target. Unlike data moving through a network, stored data doesn’t disappear after a transaction. It sits. And if it’s not properly protected, it waits for whoever finds it.
We’ve spent years working with organizations that hold some of the world’s most sensitive data, healthcare records, financial transactions, and government intelligence. The security mistakes we see most often aren’t exotic.
They’re basic: unencrypted databases, overly permissive access controls, and a vague understanding of what “encrypted at rest” actually means.
This guide cuts through the noise. You’ll get a clear explanation of what data at rest is, how encryption actually works, which standards you need to comply with, and the specific practices that separate organizations that get breached from those that don’t.
Quick Take:
- Data at rest means any stored data that isn’t actively moving, databases, file servers, backups, and cloud storage are the main targets.
- AES-256 is the encryption standard that effectively protects data at rest; anything weaker leaves you exposed.
- Encryption alone isn’t enough, access controls, key management, and regular audits are equally important.
- Regulations like GDPR, HIPAA, and PCI-DSS all require encryption at rest, with real financial penalties for non-compliance.
What Is Data at Rest, Exactly?
Data at rest refers to any data that is stored on a physical or virtual medium and is not actively moving between systems. It’s the digital equivalent of a file sitting in a locked cabinet, except without the right security controls, that cabinet might have no lock at all.
This includes:
- Databases, relational databases (SQL), NoSQL stores, data warehouses
- File systems, on-premises servers, NAS drives, employee workstations
- Cloud storage, S3 buckets, Azure Blob Storage, Google Cloud Storage
- Backup and archive media, tape drives, cold storage, disaster recovery copies
- Endpoints, laptops, mobile devices, USB drives
The reason data at rest gets so much attention in security circles is simple: volume and permanence. Data sitting in storage doesn’t have the natural time limit that data in transit has.
A packet moving across a network is there and gone. A database record containing customer PII might sit untouched for years, and if it’s breached at any point during that time, the damage is the same.
It’s also worth noting that data at rest includes data you might not immediately think of: database transaction logs, temporary files created by applications, cached data, and shadow copies. A surprisingly common oversight is securing the primary database but leaving logs or backups unencrypted.
What Is the Difference Between Data at Rest and Data in Transit?
Understanding this distinction matters because each state requires different security controls, and the risks are different too.
Data in transit (also called data in motion) is data actively moving between locations, from a user’s browser to a web server, between microservices in an application, or over a corporate VPN.
The standard protection here is TLS (Transport Layer Security), which encrypts the connection so that anyone intercepting the traffic sees only scrambled data.
Data at rest is the opposite: stored, stationary, waiting. TLS does nothing for it. The protection mechanisms are entirely different.
Here’s a simple comparison:
| Data at Rest | Data in Transit | |
|---|---|---|
| State | Stored on disk or cloud | Moving across a network |
| Main threats | Physical theft, insider access, storage breaches | Interception, man-in-the-middle attacks |
| Primary protection | Encryption at rest, access controls | TLS/SSL, VPN |
| Standards | AES-256, TDE | TLS 1.2 or higher |
| Example | Customer database on a cloud server | Login credentials sent over HTTPS |
There’s also a third state worth knowing: data in use, which refers to data being actively processed in memory.
This is increasingly relevant as organizations look to perform analytics on sensitive data without exposing the underlying records. Privacy-enhancing technologies like fully homomorphic encryption address this specific challenge, allowing computation on encrypted data without ever decrypting it.
Key Tip
Many security policies focus heavily on data in transit but underinvest in data at rest. The irony is that stored data represents a larger, more permanent attack surface, and it’s where the most sensitive records tend to accumulate.
Is Data at Rest More Vulnerable Than Data in Transit?
In practice, yes, for a few reasons that are worth understanding.
First, data in transit has a short window of exposure. An attacker needs to intercept the data during the exact moment it’s moving, which requires either being on the same network or staging a sophisticated man-in-the-middle attack. Modern TLS implementations make this extremely difficult.
Data at rest, by contrast, sits in place indefinitely. If an attacker gains access to a database, through a compromised credential, a misconfigured cloud storage bucket, a physical device theft, or a malicious insider, they have unrestricted time to extract data. There’s no clock ticking.
Second, the attack surface for stored data is larger. Organizations often have multiple copies of sensitive data spread across production databases, dev environments, backups, and archives, not all of which receive the same level of security attention. It’s common to see production data properly protected while a backup from 18 months ago sits unencrypted on a forgotten network share.
Third, insider threats disproportionately target data at rest. A malicious or negligent employee is far more likely to exfiltrate records from a database they have legitimate access to than to intercept network traffic.
That said, both states deserve serious protection. The right approach isn’t to decide which is “more” vulnerable, it’s to apply appropriate controls to both, and extend that thinking to data in use as well.
How Do You Encrypt Data at Rest?
Encryption at rest works by transforming readable data (plaintext) into an unreadable format (ciphertext) using an encryption algorithm and a key. Without the correct key, the ciphertext is computationally useless to anyone who gets their hands on it.
There are three main approaches organizations use:
Full Disk Encryption (FDE)
Full disk encryption protects everything on a physical drive. If a laptop is stolen or a hard drive is pulled from a server, the attacker gets an unreadable disk. Common implementations include BitLocker (Windows), FileVault (macOS), and dm-crypt (Linux).
FDE is an essential baseline for endpoints and on-premises servers. Its limitation is that it only protects against physical theft, once the system is running and the disk is unlocked, the protection isn’t active at the application layer.
File-Level and Volume Encryption
This approach encrypts individual files or logical volumes rather than the entire disk. It gives finer-grained control, you can encrypt specific folders containing sensitive data without encrypting every system file. Cloud storage services typically offer this at the object or bucket level.
Database Encryption and Transparent Data Encryption (TDE)
For databases specifically, Transparent Data Encryption is the most widely used mechanism. TDE encrypts data at the database engine level, the encryption and decryption happen automatically as data is written to and read from disk, which is why it’s “transparent” to the application.
Microsoft SQL Server, Oracle Database, and MySQL all support TDE natively.
The advantage of TDE is that it protects the physical database files without requiring any changes to the application code.
The limitation is that it typically doesn’t protect data that’s already been read into memory or protect against threats from users who have legitimate database access.
Important
Encryption is only as strong as your key management. Storing encryption keys alongside the data they protect, a surprisingly common mistake, is equivalent to leaving your house key under the doormat. Keys should be managed in a dedicated key management service (KMS), such as AWS KMS, Azure Key Vault, or HashiCorp Vault.
What Is AES-256 Encryption for Data at Rest?
AES-256 is the encryption standard you’ll see referenced in virtually every data security framework, compliance requirement, and enterprise vendor’s security documentation.
Understanding what it actually means (and why it matters) helps you make better decisions about your own security posture.
AES stands for Advanced Encryption Standard. The “256” refers to the key length, 256 bits. The key length is important because it determines how many possible keys exist: a 256-bit key has 2^256 possible combinations.
To put that in perspective, that’s more combinations than there are atoms in the observable universe. No brute-force attack against AES-256 is computationally feasible with any technology that currently exists or is theoretically near-term possible.
AES-256 is a symmetric encryption algorithm, meaning the same key is used to encrypt and decrypt data. It operates in blocks, processing 128 bits of data at a time and applying multiple rounds of mathematical transformations. The result is ciphertext that looks completely random, and without the key, it stays that way.
For encryption at rest, AES-256 is typically used in one of several operating modes:
- CBC (Cipher Block Chaining), common in database encryption
- GCM (Galois/Counter Mode), preferred for modern implementations because it also provides authentication (verifying data hasn’t been tampered with)
- XTS, specifically designed for disk encryption
If a vendor or cloud provider tells you data is “encrypted at rest” without specifying AES-256 or an equivalent standard, ask. AES-128 is still considered secure, but AES-256 is the recommended baseline for sensitive data and is required by many compliance frameworks. Anything weaker than AES-128 is not acceptable for sensitive data.
Explore how privacy-enhancing technologies extend beyond encryption. → Duality’s technology overview
What Are the Best Practices for Securing Data at Rest in the Cloud?
Cloud storage adds a layer of complexity to data at rest security. The shared responsibility model means your cloud provider (AWS, Azure, GCP) secures the underlying infrastructure, but you’re responsible for configuring it correctly and protecting the data itself.
Here are the practices that make a real difference:
1. Enable encryption by default, everywhere
Most cloud providers offer server-side encryption (SSE) at no additional cost. There’s no reason not to enable it on every storage bucket, database, and volume.
For highly sensitive data, use customer-managed keys (CMK) rather than provider-managed keys, this gives you full control over the encryption key lifecycle, including the ability to revoke access immediately.
2. Classify your data before you protect it
Not all data deserves the same level of protection, and treating everything identically is inefficient. A mature data classification policy typically has four levels: public, internal, confidential, and restricted.
Restricted data (PII, health records, financial data) should receive the strongest controls: AES-256 encryption, strict access policies, and regular auditing.
3. Apply the principle of least privilege
Every user, service account, and application should have access only to the specific data they need for their specific function, and nothing more.
Overly permissive access policies are one of the most common causes of data exposure, particularly in cloud environments where misconfigured IAM policies can inadvertently expose entire storage buckets.
4. Rotate encryption keys regularly
Key rotation limits the damage if a key is ever compromised. Industry guidance typically recommends rotating keys at least annually, with more frequent rotation for highly sensitive data. Automate this wherever possible, manual key rotation is error-prone.
5. Audit access and monitor for anomalies
Implement logging for all access to sensitive stored data. Use SIEM tools or cloud-native monitoring (AWS CloudTrail, Azure Monitor) to alert on unusual access patterns, large data exports, access from unexpected locations, off-hours activity.
Encryption protects data from external attackers; monitoring protects it from insider threats.
6. Don’t forget backups and replicas
Every backup and read replica of sensitive data needs the same encryption treatment as the primary. Attackers looking for the path of least resistance will often target backup systems that receive less security attention.
Did you know?
The Ponemon Institute found that organizations with fully deployed security automation experience breach costs nearly 40% lower than those without. A big part of that gap comes from faster detection and response enabled by automated monitoring of data at rest.
For organizations that need to go further, particularly those collaborating across organizational boundaries on sensitive datasets, confidential computing provides an additional layer of protection by isolating data processing in hardware-secured enclaves.
What Compliance Standards Require Data at Rest Encryption?
If you operate in any regulated industry, encryption at rest isn’t optional, it’s a legal requirement. Here’s a practical breakdown of what the major frameworks actually require:
GDPR (European Union)
GDPR Article 32 requires organizations to implement “appropriate technical measures” to protect personal data.
Encryption is explicitly cited as one of those measures. While GDPR doesn’t mandate a specific algorithm, AES-256 is the accepted standard for compliance purposes. Non-compliance carries fines of up to 4% of global annual turnover or €20 million, whichever is higher.
HIPAA (United States, Healthcare)
HIPAA’s Security Rule requires “addressable” encryption for electronic Protected Health Information (ePHI) at rest.
In practice, the regulatory expectation is that organizations implement encryption unless they can document a compelling reason not to, and that reason is difficult to justify. Breaches involving unencrypted ePHI carry significantly higher penalties.
PCI-DSS (Payment Card Industry)
PCI-DSS Requirement 3.5 mandates encryption of stored cardholder data using strong cryptography. AES-256 is specifically listed as an acceptable algorithm. This applies to any organization that stores, processes, or transmits payment card data.
NIST SP 800-111 and FIPS 140-2
For US federal agencies and their contractors, NIST SP 800-111 provides explicit guidance on storage encryption technologies. FIPS 140-2 (and its successor, FIPS 140-3) mandates validated cryptographic modules, only AES-128 and AES-256 are approved for protecting sensitive government data.
ISO 27001
ISO 27001 Annex A Control 8.24 requires policies on cryptographic key use and management. AES-256 encryption for data at rest aligns with its requirements for protecting sensitive information assets.
Understanding these requirements matters not just for avoiding fines, it shapes how you architect your security controls. Organizations in financial services, healthcare, and government face the most stringent and overlapping requirements.
Key Tip
Don’t treat compliance as a ceiling, it’s a floor. GDPR, HIPAA, and PCI-DSS represent minimum acceptable security. Sophisticated threat actors don’t care whether you’re compliant; they care whether they can get to your data.
What Is Transparent Data Encryption (TDE)?
Transparent Data Encryption (TDE) is a database-level encryption technology that automatically encrypts data before it’s written to disk and decrypts it when it’s read back, all without any changes to the application layer.
The process is “transparent” because applications interact with the database exactly as they would without encryption.
Here’s how TDE works in practice:
- When a row of data is written to the database, the database engine encrypts it using a database encryption key (DEK).
- The DEK itself is encrypted by a master key (or certificate), which is typically managed by a Key Management Service.
- The physical database files (.mdf, .ldf in SQL Server; datafiles in Oracle) are stored in encrypted form on disk.
- When the application queries data, the database engine decrypts it in memory before returning results.
The practical result is that even if an attacker copies the raw database files, they get encrypted data they can’t read. This protects against physical media theft, unauthorized backup access, and certain types of infrastructure compromise.
Where TDE has limits:
TDE doesn’t protect data once it’s in memory (it’s decrypted for active queries), doesn’t protect against users with legitimate database access, and typically doesn’t protect database transaction logs unless configured to do so.
For these gaps, additional controls, like column-level encryption for the most sensitive fields, and row-level security policies, complement TDE effectively.
Major database platforms that support TDE natively include Microsoft SQL Server, Oracle Database, MySQL Enterprise Edition, and PostgreSQL (via pgcrypto or extensions).
Key Takeaways for Securing Data at Rest
Data at rest is one of the largest and most persistent attack surfaces in any organization. The good news is that the tools to secure it, AES-256 encryption, TDE, robust key management, and least-privilege access controls, are well-understood and widely available.
The gap between organizations that get breached and those that don’t usually isn’t about technology. It’s about implementation: applying encryption consistently, managing keys properly, auditing access, and not treating compliance as the finish line.
For organizations that need to go further, protecting data not just when it’s stored, but when it’s being used and shared, modern privacy-enhancing technologies have made it possible to compute on encrypted data directly. That’s a meaningful step change from traditional encryption at rest alone.
If you’re building or reviewing a data security strategy, start with the fundamentals in this guide, then ask the harder question: when data needs to leave the vault to be useful, how does your protection hold up?
How Can Duality Help You Protect Data at Rest (and Beyond)?
Encrypting data at rest is a good foundation, but it leaves a significant problem unsolved: how do you use sensitive data without decrypting it?
The moment data is decrypted for analysis, collaboration, or AI model training, it’s exposed. Traditional encryption protects data when it’s sitting still, but the moment an organization needs to do something useful with it, the protection comes off.
That’s exactly the gap Duality Technologies was built to close.
Duality’s platform uses fully homomorphic encryption (FHE), a technology that lets organizations run queries and analytics on encrypted data without ever decrypting it.
The data stays encrypted throughout the entire computation. Only the result is returned, and it can be configured so even the result is privacy-protected.
This matters enormously for:
- Healthcare organizations running collaborative research on patient records across institutions, where the data never has to leave its encrypted state to generate insights
- Financial institutions performing fraud detection and AML screening across datasets from multiple banks, without any party exposing their raw data
- Government agencies running cross-agency analytics on classified or sensitive data, maintaining zero-footprint operations
Combined with confidential computing and federated learning, Duality provides a complete stack for organizations that need to protect data at rest, in transit, and critically, in use.
If your organization handles sensitive data and needs to collaborate without compromising privacy, explore the Duality platform to see how encryption can work beyond the storage layer.
