Encryption at Rest vs In Transit Explained

Encryption turns readable data into scrambled data that can only be read with the right key. Encryption at rest protects data while it is stored, for example on a laptop, in a database or in a backup, so a stolen disk or leaked file is useless without the key. Encryption in transit protects data while it travels across a network, for example between your browser and a website, so anyone watching the connection sees only noise. Most businesses need both, plus sensible handling of the keys, because each one covers a different way that data can be exposed.

How encryption works, briefly

Encryption uses an algorithm and a key. The algorithm is public and well studied; the key is secret. Two broad families matter in practice.

• Symmetric encryption uses the same key to encrypt and decrypt. It is fast and is used to protect bulk data, such as disks and database files. AES is the widely used standard.
• Asymmetric (public-key) encryption uses a pair of keys: a public key that anyone can use to encrypt or verify, and a private key that you keep secret. It is slower, so it is used for exchanging keys and proving identity, which is how your browser trusts a website.

Real systems combine both: public-key methods establish a shared secret, and symmetric encryption then protects the data. You do not need to implement any of this yourself, and you should not. Use well-tested libraries and platform features rather than inventing your own scheme.

Encryption at rest

Data at rest sits on devices and storage: laptops, phones, servers, databases, file shares, cloud storage buckets and backups. The risk is theft or exposure of the storage itself: a lost laptop, a discarded drive, a misconfigured storage bucket, or a stolen backup.

Layers at rest

• Full-disk encryption on laptops, desktops and phones. Built into mainstream operating systems and usually a settings change plus recovery-key management.
• Database and storage encryption in your cloud or hosting platform, often a toggle that encrypts volumes and snapshots with managed keys.
• Backup encryption, so that offsite or cloud copies are protected independently of the production system.
• Field-level or application-level encryption for especially sensitive values, so they stay protected even if someone gains access to the database itself.

An important limit: encryption at rest mostly protects against theft of storage. If an attacker logs in with valid credentials, or exploits your application, the system will happily decrypt data for them. That is why access control and authentication still matter.

Encryption in transit

Data in transit crosses networks you do not control: café Wi-Fi, the public internet, links between your offices and cloud services. Without encryption, someone on the path can read or alter it.

What to use

• TLS (shown as HTTPS) for all websites, web applications and APIs. Redirect HTTP to HTTPS and keep certificates renewed.
• TLS for email in transit between mail servers where supported.
• VPN or equivalent secure tunnels for remote access to internal systems.
• Encrypted database connections between your application and database, particularly when they are on different hosts.
• SSH or SFTP instead of unencrypted FTP or Telnet for administration and file transfer.

End-to-end encryption goes a step further: only the sender and recipient hold the keys, so even the service provider cannot read the content. It is valuable for some messaging and storage use cases but is not required for every business system.

Side-by-side comparison

	At rest	In transit
Protects	Stored data	Data moving across a network
Typical threat	Lost device, stolen disk or backup, exposed storage	Eavesdropping or tampering on the network
Common tools	Full-disk encryption, encrypted volumes, backup encryption	TLS/HTTPS, VPN, SSH, SFTP
Does not stop	Attacks using valid credentials or application flaws	Data being exposed once it arrives and is stored insecurely

Keys: the part that decides everything

Encryption is only as strong as the handling of its keys. Keep keys separate from the data they protect, restrict who and what can use them, and rotate them according to a defined schedule or after suspected exposure. Cloud platforms offer key management services that store keys in protected hardware and log their use; using one is usually safer than keeping keys in a config file next to the data. Always plan recovery: store recovery keys for disk encryption in a controlled place, and know how to restore encrypted backups. A key that nobody can find makes your own data permanently unreadable.

Hashing is not encryption

Passwords should not be encrypted for later retrieval. They should be hashed with a slow, purpose-built algorithm designed for password storage, with a unique salt per password, so that even you cannot recover the original. Examples include bcrypt, scrypt and Argon2. Encryption is reversible by design; password hashing is not. Confusing the two is a classic mistake in custom applications, and one we also touch on in our OWASP Top 10 explainer for business owners.

A practical enablement checklist

1. Turn on full-disk encryption on every laptop and phone that touches company data, and store recovery keys centrally.
2. Confirm every public website and API serves HTTPS only, with automatic certificate renewal.
3. Enable encryption on cloud storage, databases and snapshots.
4. Encrypt backups and restrict who can restore them.
5. Replace FTP, Telnet and unencrypted remote access with secure alternatives.
6. Document where keys live, who can use them, and how they are recovered.
7. Review the setup annually and whenever you add a new system.

Where to start if you are unsure

If you are not sure what is already encrypted, work through three questions. Where does sensitive data live, including copies in email attachments, exports and old backups? How does it move between those places and to third parties? Who holds the keys? Answer these on one page and the gaps become obvious. Often the biggest exposure is not the main database but a spreadsheet export on a shared drive or a laptop that was never encrypted. Prioritise by the sensitivity of the data and the likelihood of loss: portable devices and internet-facing connections come first because they are the most exposed.

Common mistakes

• Assuming a padlock icon means the site is safe. It means the connection is encrypted, not that the site is trustworthy or that data is protected after arrival.
• Encrypting without access control. Encrypted data that every employee can open protects little.
• Storing the key beside the data. Anyone who can reach one can reach the other.
• Disabling certificate checks in code to make an error go away. This quietly removes the protection.
• Inventing custom cryptography. Use standard, maintained libraries.
• Never testing recovery. Prove you can restore encrypted data and decrypt a lost laptop's recovery key before an emergency.

How this connects to data protection

Under GDPR, encryption is commonly mentioned as an example of an appropriate technical measure, and a lost encrypted device is generally treated very differently from a lost unencrypted one. But the regulation asks for measures appropriate to the risk, not a specific product. This is not legal advice; see our article on GDPR and security and the Data Protection Commission's guidance.

Next steps

Start with disks and HTTPS, then work through storage, backups and keys. If you would like help reviewing where your data is exposed and which protections to apply, our cybersecurity solutions include encryption, authentication, audits and threat monitoring, and we can discuss what suits your systems.