You’re right, the TempDB encryption is buried in the fine print when it should be circled in red. I try to draw attention to it every time I give an encryption presentation, along with the other “little things” that seem to fly under the radar with TDE–the things that can have a direct impact on your architecture decisions and performance.

Your post will definitely get people thinking about some of the “side effects” of TDE. And that’s exactly what they need to help them make better decisions about when and where to use this feature! Kudos!

good points Michael, thanks.

i don’t think many people are aware about the tempdb encryption. it’s not that it doesn’t make sense to need your tempdb to be encrypted; it’s that it isn’t well known, in my opinion. and it could also be the case that it might make more sense to have a tempdb for each database, rather than only one shared tempdb per instance. of course that will never happen, but we can all dream, right?

The reason Filestream is not encrypted is because TDE operates on SQL Server’s IO buffers. Filestream bypasses the IO buffers to give you performance enhancement. I suspect you could use Windows file encryption (EFS, BitLocker) facilities on Filestream data, although I have to admit I haven’t actually tried it yet.

For me the downside of TDE is that it only protects against file theft. Anyone who can get their hands on a login with appropriate rights can see all your data as if it were stored unencrypted. Cell-level encryption gives you fine-grained control (the trade-off being performance, of course).

Thanks for the heads up!