Encryption at rest vs in transit: what each protects
In transit protects data on the network, at rest protects it in storage, and neither covers data in use. What each one stops, what cloud defaults cover and how to answer questionnaires.
On this page 8 sections
Encryption in transit protects data while it moves across a network, such as from a student's phone to your server, usually with TLS, the security layer behind HTTPS. Encryption at rest protects data while it is stored on disks, in databases and in backups, so a stolen drive or leaked backup file is unreadable without the key. You need both, and neither protects data while your application is using it.
The three states of data
Security teams describe data as being in one of three states. Each state faces different threats and needs a different protection.
| State | Example in an institute | Main threats | Main protection |
|---|---|---|---|
| In transit | A student logs in to your app over hostel Wi-Fi; your server calls the payment gateway; the app server queries the database | Eavesdropping, tampering, fake Wi-Fi hotspots | TLS (HTTPS), with certificates verified |
| At rest | The student database, video files in storage, nightly backups, a counsellor's laptop | Stolen or discarded disks, leaked backups and snapshots, lost laptops | Disk, database or field-level encryption, with keys stored separately |
| In use | The admin panel showing a student list; a lecture playing on a student's screen | Stolen admin logins, SQL injection, a compromised server, insiders, screen recording | Access control, logging, application security; specialised hardware in rare cases |
Encryption in transit
TLS gives three guarantees on a connection: nobody on the path can read the data, nobody can change it without detection, and the client knows it is talking to the real server, because the server proves its identity with a certificate. HTTPS is simply HTTP carried over TLS. If you want the mechanics, see how SSL/TLS works.
Public websites are usually covered. The gaps are the hops people forget:
- App server to database or cache. Many setups run these connections unencrypted on the assumption that the internal network is safe.
- Service to service. Internal APIs, video processing workers and admin tools that call each other over plain HTTP.
- Old endpoints. An API path still served over HTTP for an old app version.
- Certificate checks switched off. A connection that is encrypted but never verifies the certificate can still be intercepted by anyone who can sit in the middle.
Cloud providers help, but only partly. AWS encrypts traffic between its Regions and between Availability Zones, yet its own documentation says encrypting traffic between your clients and your servers is your job. Treat connections between your own services the same way.
A practical baseline: TLS 1.2 or later everywhere, TLS 1.3 where you can; HTTP redirected to HTTPS; HSTS (RFC 6797) so browsers refuse plain HTTP; and TLS with certificate verification between your application and its database. Check that database connection in particular: some database clients' default settings quietly fall back to an unencrypted connection when TLS isn't available, and a connection that encrypts without checking the certificate can still be intercepted.
Encryption at rest
Encryption at rest comes in layers, and each layer stops different things:
- Disk or volume encryption encrypts everything written to a disk, such as a cloud volume, a laptop drive or a phone.
- Storage service encryption encrypts objects in services like Amazon S3 or Azure Storage.
- Database encryption, often called transparent data encryption (TDE), encrypts the database's files. The database decrypts automatically for anyone who can log in.
- Field-level encryption encrypts specific columns, such as phone numbers or ID numbers, inside your application, with keys kept outside the database.
The catch is in the word "transparent". Disk and database encryption are transparent to legitimate users, and equally transparent to an attacker who gets in through your application or with a stolen database password.
| Threat | Disk or volume encryption | Database TDE | Field-level encryption |
|---|---|---|---|
| Stolen or discarded disk | Protected | Protected | Protected |
| Leaked backup or snapshot | Protected only if the backup is stored encrypted too | File-level backups usually protected; logical dumps, such as mysqldump or pg_dump output, are plain text | Protected: the fields stay encrypted in any backup |
| Attacker with a database password, or SQL injection | Not protected | Not protected | Protected, if the keys live outside the database |
| Compromised application server | Not protected | Not protected | Partly: the app can still decrypt |
| Staff member misusing the admin panel | Not protected | Not protected | Not protected: this needs access control |
So encryption at rest is necessary but narrow. It is only as good as the separation between the data and its keys, which is why teams use a key management service and envelope encryption rather than a key sitting in a config file next to the data. Encryption key management covers rotation and access to keys.
Encryption in use
To compute on data, a server normally has to decrypt it into memory. Confidential computing narrows that gap by running code inside hardware-based, attested trusted execution environments, so that even the host has a hard time reading the memory. Examples include Google Cloud's Confidential VMs (AMD SEV and Intel TDX), Azure confidential computing and AWS Nitro Enclaves, which are isolated environments with attestation. Homomorphic encryption, which computes on data while it stays encrypted, exists but remains specialised and slow.
For most institutes, protecting data in use means ordinary controls: individual logins with roles, multi-factor authentication for admins, a log of who viewed or exported what, and fast removal of former staff. For paid video, the in-use problem is the student's screen. A decrypted lecture can be screen-recorded or filmed, which is why video protection adds watermarking and recording detection on top of encryption.
What cloud defaults cover
Cloud platforms encrypt a lot at rest by default, but not everything, and the exceptions catch people out. As of September 2026:
| Service | Encrypted at rest by default? | Watch out for |
|---|---|---|
| Amazon S3 | Yes, every new object since 5 January 2023 | Objects stored unencrypted before then stay that way unless copied again |
| Amazon RDS | Only if chosen when the database is created | You can't switch it on in place; the fix is an encrypted snapshot copy and a restore |
| Amazon EBS volumes | Only if you turn on "encryption by default", Region by Region | Existing volumes are not changed |
| Amazon DynamoDB | Yes, always | You choose the type of key |
| Google Cloud | Yes, with AES-256 | In transit, VM traffic sent over external IP addresses isn't automatically encrypted |
| Azure Storage | Yes, and it can't be disabled | None for storage itself |
| Azure SQL Database | Yes, TDE for new databases | It can be turned off per database; older databases may be unencrypted |
| Self-managed PostgreSQL | No built-in TDE | Use disk encryption, and encrypt sensitive columns separately |
| Android and iPhone | Yes: file-based encryption on devices launched with Android 10 or later; Data Protection on iPhone once a passcode is set | Older Android devices vary |
Sources: Amazon S3 default encryption FAQ and Amazon RDS encryption. Provider defaults change, so check your own console rather than trusting a table, including this one.
Answering security questionnaires
Schools, universities and corporate partners often send security questionnaires before they sign up, and India's DPDP Rules, 2025 list encryption, obfuscation, masking and virtual tokens among the minimum safeguards for personal data, alongside access control and logs kept for a year. "Yes, we use encryption" is a weak answer. Specific answers are stronger, and they force you to check that they are true. For illustration, here is how an institute's own tech team might answer:
| Question | Weak answer | Stronger answer |
|---|---|---|
| Is data encrypted at rest? | Yes, it is encrypted. | Databases, file storage and backups are encrypted with AES-256 using cloud-managed keys. Phone and ID numbers are also encrypted at field level, with keys in a key management service. |
| Is data encrypted in transit? | Yes, we have SSL. | TLS 1.2 or later on every public endpoint, with HSTS. Connections from our servers to the database use TLS with certificate verification. No plain HTTP. |
| Who can use the keys? | Only our team. | Two named engineers administer keys; every use of a key is logged; keys are rotated on a schedule. |
| How is data protected in use? | (Often skipped) | Role-based access, multi-factor authentication for admins, and access logs kept for a year and reviewed monthly. |
For the legal side of these safeguards, see our DPDP Act compliance checklist.
Key takeaways
- In transit means on the network; at rest means in storage; in use means in memory or on screen.
- TLS covers transit only if every hop uses it and certificates are verified, including app-to-database connections.
- Disk and database encryption stop stolen disks and leaked backups, not attackers who log in through your application.
- Field-level encryption with keys outside the database protects the most sensitive columns even after a database leak.
- Cloud defaults cover a lot, with exceptions: RDS must be encrypted when the database is created, and EBS needs a per-Region setting. Check, don't assume.
Frequently asked questions
What is encryption at rest?
Encryption at rest means stored data is kept in encrypted form, so anyone who gets the storage without the key sees only unreadable ciphertext. It protects against stolen or discarded disks, lost laptops and leaked backup files. It does not stop someone who logs in through your application or database, because the system decrypts data automatically for authorised connections, and a stolen password looks authorised.
What is data encryption at rest?
It is the practice of encrypting data wherever it is stored, not just the main database. For an institute that list includes object storage for videos and PDFs, database volumes, backups and snapshots, log files, exported spreadsheets, staff laptops and phones. Backups and exports are the usual gaps: a well-encrypted database helps little if last month's backup sits unencrypted in a shared folder.
What is database encryption at rest?
It is encryption of a database's stored files. It comes in three forms: volume encryption underneath the database, transparent data encryption inside it, such as Azure SQL's TDE or MySQL InnoDB's tablespace encryption, and column-level encryption for sensitive fields. Community PostgreSQL has no built-in TDE, so teams rely on disk encryption plus separate encryption for sensitive columns.
What is encryption in transit?
Encryption in transit protects data while it travels between two systems, such as a student's browser and your website, or your app server and its database. It is usually done with TLS, which also verifies the server's identity and detects tampering. It protects data only on the wire: once data arrives, it is decrypted, so storage needs encryption at rest as well.