One word, two different jobs

"Is the data encrypted?" sounds like a yes/no question, and treating it that way is how teams end up with a false sense of safety. Encryption isn't one control — it's at least two, defending against threats that have almost nothing to do with each other. Encryption in transit protects data moving between systems. Encryption at rest protects data sitting still on a disk. Doing one perfectly while ignoring the other leaves a hole exactly the size of the threat you skipped.

Understanding which threat each one answers is the difference between encryption as a real control and encryption as a checkbox you tick on a compliance questionnaire without knowing what it buys you.

In transit: defending the wire

Encryption in transit protects data while it's moving — between a user's browser and your server, between two of your services, between your app and its database. The threat it defends against is interception: an attacker positioned on the network path who can read or tamper with traffic as it flows by.

  • The standard is TLS, and the details matter. A valid certificate, modern protocol versions (TLS 1.2 minimum, 1.3 preferred), and strong cipher suites. An expired or misconfigured cert is both a self-inflicted outage and a downgrade opportunity.
  • Enforce it, don't just offer it. Redirecting HTTP to HTTPS isn't enough; an attacker strips the redirect. The HSTS header is what forces every future connection over TLS and closes the downgrade gap.
  • Don't stop at the edge. Many teams encrypt browser-to-server traffic and then send data between internal services in plaintext, assuming the internal network is safe. It isn't — an attacker who gets a foothold inside reads everything. Encrypt service-to-service and app-to-database traffic too.

At rest: defending the disk

Encryption at rest protects data while it's stored — on a server's disk, in a database, in an object store, on a backup tape. The threat it defends against is physical or storage-layer compromise: a stolen laptop, a decommissioned drive that wasn't wiped, a cloud storage bucket whose underlying media is somehow accessed, a backup that falls into the wrong hands.

Here's the part that's easy to misread: at-rest encryption defends against someone stealing the storage. It does not defend against an attacker who has valid access to the application, because to a logged-in application the data is transparently decrypted. Full-disk or transparent database encryption stops the stolen-drive scenario; it does nothing against a compromised credential or a SQL injection bug. That's why at-rest encryption is necessary but never sufficient — it has to sit alongside identity hardening and access control, not instead of them.

For especially sensitive fields — payment tokens, health data, secrets — application-level encryption (encrypting specific fields before they hit the database, with keys the database itself never sees) raises the bar further, so that even a full database compromise yields ciphertext rather than plaintext.

Key management is the part that actually decides everything

This is the truth most encryption conversations skip: encryption only moves the problem from "protect the data" to "protect the key." A flawless cipher with a key sitting in a config file next to the data it protects is theater. The whole strength of the system collapses to how well you guard the key.

  • Keys live separately from the data they protect, in a dedicated key management service or vault — never hardcoded, never in the repo, never in the same dump as the database.
  • Keys rotate, and the system survives rotation. Some keys are effectively one-way commitments — rotating them can strand everything encrypted under the old key — so the rotation story has to be designed in, not bolted on.
  • Access to keys is itself a privileged, logged action, monitored the same way you'd watch any high-value access in your logs. The person or service that can decrypt everything is the highest-value target you have.

A scanner can tell you whether TLS is configured and whether a volume is encrypted. It can't tell you whether the key is sitting in a world-readable file — that's a design question, and it's the one that actually determines whether your encryption means anything.

Coverage and drift, not a one-time switch

Encryption fails quietly. A new database gets provisioned with at-rest encryption disabled. A backup job writes to an unencrypted bucket. A certificate expires. An internal service ships traffic in plaintext because someone disabled TLS to debug an issue and never turned it back on. None of these throw an error — the data flows fine, and the gap is invisible until a breach or an audit finds it.

So encryption is a coverage problem, not a yes/no one. The right questions are continuous: what fraction of our data stores are actually encrypted at rest? Is every service connection actually using TLS? When a new resource appears unencrypted, does it surface as a finding? That's drift detection, and it belongs in your security posture score as a tracked dimension — because "we encrypt our data" was true the day you turned it on and may not be true today.

Encryption at rest and in transit aren't redundant — they cover different threats, and key management decides whether either one is real. The honest version of "is it encrypted?" is three questions: in transit, at rest, and who holds the keys.