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.

One long-horizon question belongs on the same inventory: which of your encryption depends on algorithms that a future quantum computer would break. Quantum-safe cryptography migration planning covers what a lean team should actually do about that now, which is mostly knowing where your cryptography lives.

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.