Auth controls who can ask. Encryption controls what's readable if someone walks past auth (stolen disk, compromised host, rogue cloud admin, badly-permissioned backup).
The three tiers
| Tier | What it protects against | Effort |
|---|---|---|
| Disk-level (FileVault, LUKS) | Physical theft of the powered-off device | One-time, free, on by default on most modern OSes |
| Database-level (SQLCipher, Postgres TDE) | Adversary with file access but no app access | Library swap; ~1 day |
| Field-level (encrypt sensitive columns) | Rogue DBA, leaked backup, app-level XSS-extracted dumps | Most work; key management becomes the new problem |
The key-management reality
Encryption pushes the security problem from "the data" to "the key". The new questions:
- Where does the key live? (OS keychain, KMS, HSM, env var)
- What happens during deploy / restart? (the service must fetch it on startup)
- What happens if you lose the key? (the data is gone — forever; back up the key separately)
- How do you rotate? (re-encrypt all data with the new key; non-trivial at scale)
What's worth encrypting at field level
Not everything. Encrypting indexes/foreign keys breaks query patterns. The pragmatic list: API keys / tokens stored on behalf of the user; personal notes / journal entries; health / financial data; session tokens (one-way hash is often fine here); anything covered by a compliance regime (HIPAA, GDPR special categories).