"Is the data encrypted?" — "Yes, at rest and in transit." It's the most rehearsed exchange in security reviews, and both sides usually leave satisfied. They shouldn't. Encryption at rest defends against a narrow, mostly theoretical threat, while the breaches that actually happen walk straight past it.
Transparent encryption — full-disk, filesystem, or database-level TDE — protects data in exactly one scenario: someone obtains the physical or virtual storage without the keys. A stolen drive, a discarded disk, a snapshot copied out of band.
That threat is real, and in a modern cloud it is also the one your provider has most thoroughly engineered away. Meanwhile the encryption is, by design, transparent: any process with legitimate access to the running system sees plaintext. The database decrypts on read. The application queries and receives clear data. So does anything wearing the application's credentials.
Which is the point: almost every real-world breach path involves exactly that — legitimate access, used illegitimately.
Compromised application access. SQL injection, a leaked connection string, an exposed API, a stolen service credential — the attacker queries the database like the application does, and the database helpfully decrypts every row. TDE contributes nothing; from its perspective, this is normal operation.
Copies. Production data doesn't stay in production. It flows to replicas, warehouses, staging environments, developer laptops, log aggregators, error trackers, and backups stored under different rules. Encryption at rest applies per system; each copy needs its own story, and in practice several never get one. The plaintext staging dump is a cliché because it keeps happening.
Insiders and over-broad access. Any admin, any engineer with production access, any support tool with a generous role sees plaintext — because that's what transparent means. The control that actually matters here is fine-grained access to specific values, and disk-level encryption provides none of it.
Keys living next to data. When the database instance holds or can fetch its own keys — which is how transparent encryption has to work — compromising the instance compromises both at once. Encryption whose keys are reachable from the encrypted system reduces, in the breach scenario, to no encryption.
None of this means turn TDE off. It's cheap, it satisfies a baseline, it covers the stolen-disk case. The mistake is treating it as an answer to data breach risk, when it addresses almost none of the ways data is actually breached.
There's a different approach, and it's older than it looks: don't protect the data where it's used — remove it from where it's used.
Tokenization replaces sensitive values with references that have no mathematical relationship to the original. The real values live in one hardened system; everything else — applications, replicas, warehouses, logs, backups — carries tokens. Now walk the four paths again. SQL injection exfiltrates tokens. The staging dump contains tokens. The curious admin reads tokens. And the keys-next-to-data problem doesn't arise, because the data isn't next to anything — it's gone from those systems entirely.
The security perimeter collapses from "every system that touches personal data" to one system, built for exactly one job. Access becomes an explicit, per-value, auditable operation instead of an ambient property of having database credentials. That's not a higher wall; it's a smaller thing to defend.
The trade-off is real: a detokenization call has a cost, and the vault becomes critical infrastructure that must be engineered accordingly. But the question every architecture review should ask is rarely asked at all: of all the systems that can read your customers' personal data today — how many actually need to?