Encryption at Rest and in Transit: What 'Encrypted' Really Means

Ask whether a system is secure and someone will tell you it is encrypted, as though that settles it. It rarely does. Encryption is real and necessary, but "encrypted" answers a specific, narrow question — who holds the key, and against which threat? — and most breaches walk straight past the encryption because they were never the threat it defended.

Cloud encryption comes in two broad flavours, defending against two different attackers. Encryption at rest protects data written to disk — block volumes, object storage, database files, snapshots — against someone who obtains the physical or raw storage. Encryption in transit protects data moving across a network, using TLS, against someone who can intercept the traffic. They are complementary, and neither substitutes for the other.

What at-rest encryption does and does not stop

Here is the part that surprises people. In the cloud, at-rest encryption is usually transparent: the platform decrypts data automatically for any identity authorised to read it. That is the whole point — your application does not manage keys. But it also means at-rest encryption does nothing against an attacker using valid credentials. A leaked access key that can read a bucket reads the plaintext, because the service decrypts on the authorised request. At-rest encryption defends against lost drives and raw-storage access, not against the credential theft that causes most cloud breaches.

Who holds the key

The security of encryption reduces to key management, and the cloud offers a spectrum. Provider-managed keys are convenient and invisible but give you no control over key access. Customer-managed keys — in AWS KMS, Azure Key Vault, or Cloud KMS — let you write key policies, audit every use, and revoke access, which is what turns encryption from a checkbox into a control. Customer-supplied keys and external key stores go further, keeping key material outside the provider entirely, at real operational cost. The right point on that spectrum depends on your threat model, not on which sounds strongest.

• Provider-managed keys. Zero effort, zero control, no per-request authorisation you can revoke. Fine for low-sensitivity data.
• Customer-managed keys. You control the key policy and see every Decrypt in the audit log — the practical default for sensitive data.
• External / customer-supplied keys. Key material never lives with the provider; maximum control, maximum operational burden.

In transit: encrypted is not the same as verified

TLS protects data in transit, but only if it is enforced and the endpoint is authenticated. Downgrade to plaintext, an unvalidated certificate, or internal "east-west" traffic left unencrypted all defeat it. In a zero-trust cloud network you cannot assume the internal network is safe, so in-transit encryption belongs on service-to-service calls too, not just at the public edge.

Encryption is a floor, not a ceiling. Turn it on everywhere — at rest and in transit, enforced not optional — but do not let the word do more work than it can. The data an attacker reads with stolen credentials was encrypted the whole time. What actually protects it is knowing where it lives and who can decrypt it, which brings you back to the same starting line: you can't defend what you haven't discovered.