Encryption at Rest vs in Transit, in Plain English
What each type of encryption protects against, where the coverage gaps hide, and what an auditor is actually checking for.
A client called me once, completely confident that all their customer data was encrypted. When I asked which kind, they said both. When I pressed a little harder — how? — the call got quiet. They had TLS configured on the web application and HTTPS in the browser bar. But the database holding all the customer records sat on a cloud instance with volume encryption turned off. Username and password on the front door, unencrypted storage underneath. Two entirely different problems, and they had only solved one of them.
"Encryption" covers a lot of ground. "Encrypted at rest" and "encrypted in transit" sound interchangeable and often appear in the same row of a security questionnaire, but they protect against different threats, at different points in a data's lifetime. Treating them as a single control is how teams end up with partial coverage and still check both boxes.
Two different threat models
At rest and in transit encryption each address a specific attacker in a specific position.
In transit attacks target data while it's moving — from a browser to a web server, between microservices, from an application to a remote database. Without protection on the network path, someone positioned between the two endpoints could intercept traffic and read the content in plaintext. In cloud infrastructure that attacker position is more abstract than a physical wiretap, but the exposure is real.
At rest attacks target data when it's sitting still — on a disk, in a database file, in an object storage bucket, in a backup snapshot. The threat is physical or logical access to the storage medium: a drive removed from a decommissioned server, a misconfigured S3 bucket, a stolen backup device. Encryption in transit does nothing to protect data once it has landed somewhere. The data arrived intact, was decrypted at the TLS endpoint, and is now sitting on disk.
You need both because an attacker can gain access through either path. Encrypting one without the other is half a solution.
What encryption at rest actually covers
At rest encryption wraps the data stored on disk or in a database so that the raw bytes are unreadable without the corresponding decryption key. If someone obtains the underlying storage — a decommissioned cloud volume, a leaked database dump, a misconfigured storage bucket — they get ciphertext, not customer records.
In cloud environments, most providers offer this at the infrastructure layer. AWS can encrypt EBS volumes, S3 buckets, and RDS databases with AES-256, though whether it's enabled depends on how the resource was originally provisioned. The same applies to Google Cloud and Azure. Teams running older infrastructure often discover that resources created years ago, before encryption defaults changed, never had it turned on.
The mechanism for managing keys matters too. Provider-managed keys, where the cloud platform controls the key lifecycle, are the easiest to run and sufficient for most companies. Customer-managed keys through a service like AWS KMS give your team more control and visibility into key usage — useful if customers or regulators ask specifically about it. Managing your own key infrastructure is rarely worth the operational overhead unless you have a regulatory requirement pushing you there.
One thing at rest encryption does not protect against is a legitimate-looking attacker. If someone obtains valid database credentials, the database will decrypt and serve the data, because that is what it is designed to do. At rest encryption protects the physical or logical storage medium. It does not replace access controls and least privilege — it works alongside them.
What encryption in transit actually covers
In transit encryption wraps data while it is moving across a network so that an interceptor sees ciphertext instead of content. TLS — Transport Layer Security — is the protocol that handles this for most application traffic. HTTPS is TLS applied to HTTP.
TLS also applies beyond browsers: API calls between your application and third-party services, connections from your application server to a database on a separate host, internal traffic between microservices. Any network hop carries some exposure if it is unencrypted, even traffic that stays inside a private cloud network.
The version of TLS matters. RFC 8996 formally deprecated TLS 1.0 and TLS 1.1 in March 2021 — both had known weaknesses that made them unsafe for continued use. The baseline today is TLS 1.2 with strong cipher suites, with TLS 1.3 preferred where your infrastructure supports it. TLS 1.3, standardized in 2018, is faster, removes the weaker cipher options that TLS 1.2 permitted, and improves forward secrecy, meaning a server key compromise does not retroactively expose past sessions.
The standard you are expected to meet
For data at rest, AES-256 is the accepted baseline, and cloud providers use it by default on most newly created resources. The gap is almost never the algorithm — it is discovering that older storage resources were provisioned before defaults changed and never had encryption enabled.
For data in transit, NIST SP 800-52 Rev. 2 provides the reference guidance on TLS selection. TLS 1.2 configured with strong cipher suites is the minimum; TLS 1.3 is the current target. These requirements are mandatory for federal systems and, in practice, security-conscious commercial teams follow the same direction.
"Encrypted in transit" does not mean optional, or limited to external-facing traffic. Internal service-to-service connections carrying sensitive data should use TLS regardless of whether they traverse a public network. A private VPC reduces the likelihood of an attacker on the network path — it does not eliminate it. Auditors increasingly check internal traffic, and "we are in a private subnet" is not a satisfying answer.
What an auditor checks
In a SOC 2 audit, encryption at rest and in transit sit under the Common Criteria, specifically the controls governing how data is protected from unauthorized access and during transmission. If you want to see exactly where these map, the SOC 2 trust services criteria lays out the structure. In practice, the evidence an auditor wants is:
- Confirmation that encryption is enabled on production storage volumes, databases, and object storage buckets
- Configuration evidence showing TLS version and cipher suites on web servers and API endpoints
- Key management procedures covering who can access keys, how they are rotated, and who is alerted if a key is compromised
- Certificate inventory showing renewal processes and confirming no certificates have expired
That last point catches teams more often than expected. A system can be "encrypted in transit" on paper with a TLS certificate that expired months ago. An expired certificate means clients may reject the connection, fall back to less secure handling, or show warnings users learn to click past. Certificate expiration is a controls failure regardless of how good the underlying setup is, and auditors treat it as one.
The SOC 2 readiness checklist covers what to have documented before your audit window opens. For encryption specifically, the work is in the configuration and inventory — knowing what you have and confirming it is actually on.
The gaps that catch teams off guard
Teams tend to get the obvious surfaces: the main web application, the primary production database. The gaps are almost always elsewhere.
Backups. A backup stored in unencrypted form on an external medium negates the at rest encryption on your primary database. Backup encryption is a separate configuration step, often missed on older backup jobs, and auditors check it specifically.
Internal API traffic. Service-to-service calls within the same network often skip TLS because developers assume the private network is protection enough. This assumption is common and wrong, and it creates gaps that are easy to find if you look for them.
Third-party integrations. When your application sends data to an external API — a logging platform, an analytics service, a payment processor — the connection should use TLS. Most modern SaaS APIs enforce it, but older integrations are worth auditing. An integration your team set up three years ago may not reflect current standards.
Key rotation. Encryption keys need to be rotated on a documented schedule. A key that has not changed in years is not as strong a control as a policy document says it is. Auditors will ask when keys were last rotated, what the policy is, and whether there are records.
These are not unusual edge cases — they are the standard follow-up questions in a security assessment. Inventorying your encryption coverage before the audit starts means fewer surprises when it does.