encryption at rest vs in transit: what to claim

encryption at rest vs in transit: what to claim

TL;DR

At rest means stored data is encrypted; in transit means data moving over the network is encrypted. Claim each one only where you have verified it, and never claim end-to-end encryption unless the server truly cannot read the data. Customers can tell the difference, and so can auditors.

encryption at rest vs in transit: what to claim

Use this when

• A questionnaire asks what encryption you use and you want an honest answer
• You are writing your security page or a DPA exhibit
• Someone on the team says "we use military-grade encryption" and you need better words
• You are verifying a vendor's encryption claims

Not for this skill when

• You are choosing algorithms or key management (that is a cryptography design task)
• You need client-side or end-to-end encryption architecture (bigger project, different skill)
• The question is about hashing passwords (hashing is not encryption; use a proper password hash)

Steps

1. Say what each term means, plainly.

Encryption at rest: data on disk, in the database, and in backups is encrypted, so stolen drives or snapshots are unreadable. Encryption in transit: data moving between systems is encrypted, so network eavesdroppers see ciphertext. Two different problems, two different claims.

Expected: you can explain both in one sentence each without hand-waving.

2. Verify encryption at rest where your data actually lives.

Check the database storage, the file volumes, and the backups. Cloud-managed encryption counts if it is actually enabled; "the cloud handles it" without checking does not.

lsblk -o NAME,TYPE,FSTYPE | grep crypto

Expected: encrypted volume types on every disk holding customer data, confirmed not assumed.

3. Verify encryption in transit on every hop.

TLS on all public endpoints, TLS between your services, no plaintext protocols carrying sensitive data. Check the certificate is valid and old TLS versions are off.

echo | openssl s_client -connect example.com:443 | grep "Verification"

Expected: verification OK, and only modern TLS versions offered.

4. Check key management, not just the algorithm.

AES-256 with the key sitting in a config file next to the data is theater. Keys belong in a managed key service with rotation and access logging. This is the question auditors ask right after "what algorithm."

Expected: keys stored in a KMS or equivalent, with rotation enabled and access logged.

5. Write claims you can prove, and nothing more.

"We encrypt customer data at rest with AES-256 and in transit with TLS 1.2 or higher; keys are managed in a KMS with rotation." Every clause maps to something you verified above. Delete any adjective you cannot demonstrate.

Expected: a claims paragraph where each claim has a verification step behind it.

6. Never claim end-to-end unless it is true.

End-to-end means your servers cannot read the data, only the endpoints can. If your server decrypts it, you do not have end-to-end encryption, you have transit plus rest. Misclaiming this one destroys trust fast.

Expected: the phrase end-to-end appears nowhere in your materials unless the architecture earns it.

Variant: is TLS enough for encryption in transit

For most web traffic, yes, if it is modern TLS everywhere with valid certificates and no plaintext fallbacks. It is not enough for data that must stay secret from your own servers; that needs end-to-end.

Variant: how to prove encryption at rest

Show the volume and database encryption settings, the backup encryption config, and the KMS key policies. Screenshots of the console plus a restore test go further than a paragraph of claims.

Variant: "military grade encryption" what to say instead

Say the algorithm, the key length, and where the keys live: "AES-256, keys in a managed KMS with rotation." Specifics persuade; marketing adjectives invite follow-up questions.

Variant: database encryption checklist

Storage encrypted, backups encrypted, connections require TLS, credentials rotated, key access logged. Five checks, and most teams are missing at least one.

Why this happens

Encryption is easy to claim and annoying to verify, so marketing got there first and set the vocabulary: "bank-level," "military-grade," "end-to-end" used loosely. Security reviewers learned to ignore adjectives and ask for specifics. The teams that answer in specifics pass; the teams that answer in adjectives get a second round of questions.

Edge cases and pitfalls

• Managed services with encryption you did not enable: many cloud services encrypt by default now, but defaults change and not all services are covered. Verify per service, per region.
• Backups and replicas: the database is encrypted but the nightly backup to object storage is not. Check every copy, not just the primary.
• Internal traffic without TLS: "it is inside our VPC" is not encryption in transit. Either encrypt service-to-service traffic or be honest that you do not.
• Certificate expiry: valid today is not valid forever. Monitor expiry and automate renewal, or your transit claim breaks on a random Tuesday.
• Key rotation breaking restores: test that rotated keys still decrypt old backups before you need it in a real incident.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ybfXA-rp2So89MTP9ux2DQ