The basic idea
Encryption scrambles data using a mathematical process and a secret value called a key, so that only someone with the right key can turn it back into readable form. Anyone who captures or steals the scrambled version without the key sees something that looks like random noise, at least in theory.
Because data exists in different situations, people talk about protecting it in different states. Two of the most discussed are “at rest” and “in transit.” Some discussions add a third, “in use,” which refers to data being actively processed in memory. It is harder to protect and is mostly outside the scope of this article.
Encryption at rest
Data at rest is data sitting in storage: files on a laptop, records in a database, objects in cloud storage, backup tapes, a USB drive. Encrypting it means that if the storage medium falls into the wrong hands, the contents are not readable without the key.
Typical threats it addresses:
- A lost or stolen laptop, phone or removable drive.
- A discarded or resold disk that was not wiped properly.
- Someone gaining raw access to storage hardware or a backup copy.
- In some cloud scenarios, access to the underlying physical media.
At rest encryption comes at different levels:
- Full-disk encryption protects an entire device and is widely used on laptops and phones. It mainly helps when the device is powered off or locked.
- Volume or file-system encryption covers particular partitions or folders.
- Database encryption can cover whole databases or individual columns, such as those holding identification numbers.
- Application-level encryption is done by the software before data is stored, so even administrators of the storage layer cannot read it.
The important limitation is that once a system is running and the data has been unlocked for use, an authorized login can read it normally. If an attacker steals a valid user’s credentials, or malware runs with that user’s rights, encryption at rest does not stop them. That is why it complements, rather than replaces, access management, least privilege and multi-factor authentication.
Encryption in transit
Data in transit is data moving between places: a browser talking to a website, an app calling an API, email passing between servers, files syncing to cloud storage, staff connecting remotely. Encryption in transit makes it unreadable to anyone who can observe or intercept the traffic along the way, such as on shared Wi-Fi or across the internet.
The most familiar form is Transport Layer Security (TLS), which is what puts the padlock in the browser for HTTPS connections. Other common forms include secure versions of remote login and file transfer protocols, and virtual private networks that wrap traffic in an encrypted tunnel.
What it addresses:
- Eavesdropping on networks you do not control.
- Tampering with data on its way, since modern protocols also check that messages have not been altered.
- Impersonation, because certificates help a client verify that it is talking to the genuine server.
What it does not address: once data arrives, it is decrypted at the destination. If the destination is compromised, or if data is sent to the wrong recipient, transit encryption has done its job and still the data is exposed. Also, a VPN protects traffic only on the path it covers, and has other limits.
Side by side
| At rest | In transit | |
|---|---|---|
| Where the data is | Stored on disks, databases, backups | Moving across networks |
| Main risk addressed | Lost, stolen or improperly accessed storage | Interception or tampering on the network |
| Typical examples | Full-disk encryption, encrypted databases | TLS, secure remote access, encrypted email transport |
| Still exposed when | A valid user or process is compromised | Either endpoint is compromised |
The two are independent. Strong transit encryption does nothing for a stolen disk, and an encrypted disk does nothing for an unencrypted connection. Sensitive data generally calls for both.
Keys are the hard part
Encryption moves the problem from protecting the data to protecting the keys. Good key management is where many implementations succeed or fail.
- Storage. Keys should not sit next to the data they protect or in code, shared documents or chat messages. Dedicated key management services and hardware-based modules are common approaches.
- Access. Only a small number of people and systems should be able to use or manage keys. Service accounts that hold keys deserve extra attention.
- Rotation. Keys and certificates are often replaced on a schedule or after suspected exposure. Expired certificates cause outages, so track them.
- Recovery. If the only key is lost, the data is usually gone for good. Plan for secure backup of keys, and test restores as part of regular restore testing.
- Ownership in the cloud. Many cloud services encrypt storage by default, but who holds the keys varies. Under the shared responsibility model, the provider covers some pieces, while configuration and key choices often remain yours.
Practical checklist
- Know where sensitive data lives, using your data classification, and confirm it is encrypted at rest there, including laptops, phones and backups.
- Require encrypted connections for any service that handles logins or personal data, and turn off old insecure protocols where feasible.
- Keep software updated, since weaknesses in encryption software are fixed through patch management.
- Document who manages keys and what happens when they expire or are lost.
- Remember that encryption is one control. It lowers risk but does not make a breach impossible, and it does not remove duties under privacy laws.
Many privacy laws treat encryption as an appropriate safeguard, and some regimes treat a breach of properly encrypted data as less serious. That depends on the law and the facts, so check with those responsible for compliance.