Encryption: At Rest vs. In Transit
Encryption At Rest vs. In Transit: What Your Data Needs to Stay Safe
Why Encryption Is Non-Negotiable
In 2023, the average cost of a data breach reached $4.45 million, according to IBM’s Cost of a Data Breach Report. A significant portion of breaches involve data that was either unencrypted or inadequately protected. Encryption does not prevent attackers from reaching your data, but it makes the data they find completely useless without the decryption key.
Regulators understand this. GDPR, HIPAA, PCI DSS, and most modern compliance frameworks either require or strongly recommend encryption for sensitive data, both at rest and in transit. If your organization handles personal data, financial records, or health information, encryption is a legal expectation in most jurisdictions.
What Is Encryption at Rest?
Encryption at rest protects data that is stored on a device, server, database, or cloud storage system. When data is not actively being transmitted or processed, it sits in storage. Encryption at rest ensures that if an attacker gains physical or unauthorized digital access to that storage, the data they find is unreadable without the decryption key.
- Databases storing customer records or financial data
- Hard drives and SSDs on laptops, desktops, and servers
- Cloud storage buckets and blob storage
- Backup files and archives
- File servers and network-attached storage (NAS)
- AES-256 (Advanced Encryption Standard with 256-bit keys) is the current gold standard for symmetric encryption at rest
- AES-128 is used where performance is more critical than maximum security
- RSA is used for encrypting small amounts of data and for key exchange
What Is Encryption in Transit?
Where it applies:
- HTTPS connections between browsers and web servers
- API calls between applications and services
- Email transmission using TLS
- File transfers using SFTP or FTPS
- VPN tunnels between offices or remote workers and corporate networks
- Database connections using SSL/TLS
- TLS 1.2 and TLS 1.3 (the current standard; TLS 1.0 and 1.1 are deprecated)
- HTTPS (HTTP over TLS)
- SSH (Secure Shell) for secure remote connections
- SFTP and FTPS for secure file transfers
- IPsec for VPN tunnels
At Rest vs. In Transit: Key Differences
|
Factor |
Encryption at Rest |
Encryption in Transit |
|
When data is protected |
While stored |
While moving between systems |
|
Primary threat |
Physical theft, unauthorized storage access |
Eavesdropping, man-in-the-middle attacks |
|
Common technologies |
AES-256, full-disk encryption, database encryption |
TLS 1.3, HTTPS, SSH, VPN, SFTP |
|
Key storage risk |
Encryption keys must be securely managed |
Certificate management and key exchange |
|
Compliance relevance |
HIPAA, GDPR, PCI DSS |
GDPR, PCI DSS, SOC 2 |
A Third State: Encryption in Use
Some organizations now implement a third form of encryption: encryption in use, also called confidential computing. This protects data while it is actively being processed in memory. Technologies like Intel SGX and AMD SEV create hardware-protected execution environments where data remains encrypted even during computation.
While still emerging, encryption in use is becoming relevant for organizations processing highly sensitive data in cloud environments where they cannot fully trust the underlying infrastructure.
Common Encryption Mistakes to Avoid
- Using outdated encryption standards. Algorithms like MD5, SHA-1, and DES are no longer considered secure. Use AES-256 for data at rest and TLS 1.3 for data in transit.
- Encrypting data but mismanaging keys. Encryption is only as strong as your key management. If encryption keys are stored alongside the encrypted data or are inadequately protected, your encryption provides limited protection.
- Relying on encryption in transit alone. If your data is encrypted during transmission but stored in plaintext in your database, an attacker who breaches your database gets everything. Both layers are necessary.
- Not encrypting backup files. Backup files contain the same sensitive data as your live systems. They must be encrypted with the same rigor.