Two Distinct States Data Needs Protecting In
Data encryption protects information differently depending on whether it’s sitting in storage or actively moving across a network — “at rest” and “in transit” — and a genuinely complete security posture needs deliberate, explicit attention to both states. Missing either one leaves a real, exploitable gap regardless of how well you’ve secured the other.
Encryption in Transit: TLS as the Baseline
TLS (the successor to SSL) encrypts data moving between systems — a browser and a server, or between two internal microservices — protecting against eavesdropping and tampering during network transmission. HTTPS-everywhere is now a genuinely non-negotiable baseline for any web application, and internal service-to-service communication deserves the same serious treatment, not just external, public-facing traffic — a common and dangerous assumption is that internal networks are inherently trustworthy, which modern zero-trust thinking correctly rejects as a flawed premise.
Certificate Management
TLS certificates need to be properly issued by a trusted certificate authority, correctly configured, and renewed before they expire — an expired certificate causes an outage just as surely as any other infrastructure failure, and it’s an entirely preventable one with proper monitoring in place. Automated certificate management tools like Let’s Encrypt with automatic renewal have made this dramatically easier and less error-prone than in the past, removing much of the manual, error-prone process that historically caused so many entirely avoidable certificate-expiration outages.
Encryption at Rest: Protecting Stored Data
Data at rest — database contents, file storage, backups — should be encrypted so that unauthorized access to the underlying physical or virtual storage medium doesn’t automatically mean unauthorized access to the actual data itself. Most cloud providers offer encryption at rest as a straightforward, often default-enabled configuration option for storage services, though it’s genuinely worth explicitly verifying it’s actually enabled rather than simply assuming default settings cover you adequately across every service you actually use.
Database-Level vs Application-Level Encryption
Database-level encryption (transparent data encryption) protects against physical storage theft or unauthorized filesystem access but doesn’t protect against a compromised database credential being used to simply query data normally, since the database itself transparently decrypts data for any authorized query. Application-level encryption — where genuinely sensitive fields are encrypted before being stored, decrypted only in application code — provides an additional, meaningful layer of protection specifically against compromised database credentials, at the real cost of increased application complexity and typically the loss of the ability to query encrypted fields directly at the database level.
Key Management: The Part Most Often Done Poorly
Encryption is only as strong as the protection around its keys — keys stored alongside the data they encrypt, or embedded directly in application code or configuration, undermine the entire, considerable point of encrypting in the first place. Dedicated key management services (AWS KMS, Google Cloud KMS, HashiCorp Vault) handle key generation, rotation, and access control properly, and are worth using rather than attempting to build genuinely secure key management yourself from scratch, which is a notoriously difficult problem to get fully right.
Key Rotation
Encryption keys, like any other credential, should be rotated periodically, limiting the real impact if a key is ever compromised without your immediate knowledge. Modern key management services support this with minimal application disruption, re-encrypting data with new keys transparently or supporting multiple active key versions simultaneously during a gradual, non-disruptive transition period.
End-to-End Encryption: A Stronger, Narrower Guarantee
For genuinely the most sensitive use cases — messaging apps, specific compliance requirements — end-to-end encryption ensures data is encrypted on the sender’s device and only decrypted on the recipient’s device, meaning even the service provider itself cannot access the actual plaintext content. This is a meaningfully stronger guarantee than standard at-rest and in-transit encryption, but it’s also considerably more complex to implement correctly and genuinely limits certain server-side functionality (search, content moderation) that requires the server to actually access plaintext content to function at all.
Practical Recommendations
- Enforce TLS everywhere — external traffic and internal service-to-service communication alike, not just public-facing endpoints.
- Explicitly verify encryption at rest is enabled for every storage service you use, rather than assuming defaults cover you adequately.
- Use a dedicated key management service rather than building key management yourself — this is genuinely not a place to reinvent well-established, hard-won solutions.
- Consider application-level encryption for your most sensitive specific fields, accepting the real complexity trade-off deliberately where warranted.