TDE vs Always Encrypted in SQL Server: What Each One Actually Protects

Written by

in

TDE vs Always Encrypted in SQL Server: What Each One Actually Protects

Access control (previous lesson) governs who’s allowed to query what. Encryption is a completely different layer: what happens if someone gets to the raw data anyway — a stolen backup, a compromised disk, or even a DBA whose access exceeds what they should see. These get confused in interviews constantly, because both are “encryption,” but they solve genuinely different threats.

TDE vs Always Encrypted(two threats, two different guarantees)TDEprotects data AT REST —a stolen disk/backup stays lockedbut a live, authorized querystill sees plaintext 👁️Always Encrypted🔒server NEVER sees plaintext —decryption happens client-sideeven a sysadmin queryingdirectly sees ciphertext ✓same query, two tables:SELECT ssn FROM Employee — TDE only→ 555-12-3456 (plaintext)SELECT ssn FROM Employee — Always Enc.→ 0x9F3A… (ciphertext)layered, not either/or —sensitive columns can run both at onceTDE is free once configured —no reason not to run it as abaseline under everything 📌

The Key Distinction

TDE Protects data at rest (stolen files/backups) Authorized queries see plaintext Always Encrypted Server never sees plaintext Decryption happens client-side Protects even from DBAs

The Interview-Ready Answer

TDE protects against physical theft of files — a stolen backup tape, a compromised disk, a leaked VM snapshot — but a legitimate, authenticated query still sees plaintext once it’s running against the live, unlocked database. A DBA with query access sees everything, TDE or not. Always Encrypted protects against exactly that scenario: even someone with full server access querying the table directly sees only ciphertext for protected columns, because decryption happens in the client driver using a key the server itself never holds.

-- Even a sysadmin querying a table directly on the server sees ciphertext
-- for an Always Encrypted column — there's no server-side bypass:
SELECT ssn FROM dbo.Employee; -- returns encrypted binary garbage, not the real SSN,
-- UNLESS the querying client has the column master key configured

-- Contrast with TDE: the exact same query, on a TDE-protected database,
-- returns the real value — TDE is invisible to queries, only protects the files at rest

Which One for Which Data?

Sensitive columns like SSNs typically call for Always Encrypted — the goal there is usually protecting against insider visibility, not just physical theft. TDE is a reasonable baseline for the whole database regardless, since it’s essentially free once configured (transparent, as the name says — no query or application changes needed) and closes the physical-theft gap that Always Encrypted alone doesn’t address for unprotected columns. They’re complementary, not substitutes: a well-secured sensitive database often runs both simultaneously.

Common mistake: Assuming TDE alone is “encryption” in the complete sense and stopping there. TDE is genuinely valuable but answers a narrower question (“what if someone steals the physical files”) than most people assume when they hear “the database is encrypted.” If the threat model includes insider access or a compromised application account, TDE alone doesn’t address it.
Practice tip: Write out, in one sentence each, the specific attacker scenario TDE stops and the specific scenario Always Encrypted stops. If you can’t state both crisply without looking back at this lesson, that’s the gap most interview answers on this topic actually have — people memorize “TDE = at rest, AE = in use” without being able to explain why that maps to a real threat.

Enjoyed this?

Subscribe to get every new SQL Server lesson as soon as it’s published, and share it with a developer who’d find it useful.

📡 Subscribe via RSS  | 
Share on X  | 
Share on LinkedIn  | 
Share on Facebook

Want the full structured course with quizzes, projects, and 10+ exercises per chapter? Check out SQL Server for Developers & DBAs, coming soon on this site.