What’s the issue?
SQL Server’s Transparent Data Encryption (TDE) protects user databases by encrypting data at rest, including data files, log files, and backups. When TDE is enabled on any single user database on an instance, SQL Server automatically encrypts tempdb as well, since user data may flow through tempdb during query execution and would otherwise be exposed there.This finding identifies instances where tempdb is encrypted, which is always the result of TDE being enabled on at least one user database. The encryption of tempdb itself is not configurable independently and cannot be turned off while TDE is active on any database on the instance.
This is not necessarily a problem, but it is worth noting in case the team is unaware that encrypted user databases exist on the instance, or unaware of the performance implications that come with tempdb encryption.
Why is this a problem?
Encrypting tempdb has a measurable performance cost. Every page written to or read from tempdb must be encrypted and decrypted, which adds CPU overhead to operations that use tempdb heavily, including sorts, hash joins, spills, temporary tables, table variables, and version store activity for snapshot isolation or read committed snapshot. The performance impact is most noticeable on workloads with high tempdb activity. In some cases, the additional CPU cost can be significant enough to justify reviewing query patterns or workload distribution, particularly if tempdb performance was already a bottleneck.There is also a subtle operational consideration: once tempdb is encrypted, it stays encrypted until TDE is removed from every user database on the instance. Disabling TDE on a single database does not revert tempdb to an unencrypted state, so the decision to use TDE has lasting effects on the entire instance.
Also, the presence of TDE means certificate management is critical. The TDE certificate from the master database must be backed up and stored securely, since the loss of that certificate makes every encrypted database (and any backups of those databases) permanently unrecoverable.
What should you do about this?
No remediation is required if TDE is being used intentionally and the team is aware of it. Confirm which user databases have TDE enabled by querying sys.dm_database_encryption_keys, and verify that the TDE certificate has been backed up and stored in a secure offsite location separate from the database backups themselves.If tempdb encryption is causing measurable performance problems, review the workload for opportunities to reduce tempdb usage, such as tuning queries that spill to tempdb, reviewing isolation level choices, or scaling up CPU resources to absorb the additional encryption cost. Consider whether TDE is actually required for the databases that have it enabled, since removing TDE from all user databases is the only way to return tempdb to an unencrypted state (this requires a SQL Server service restart after the last database is decrypted).
If TDE was enabled inadvertently or is no longer needed for compliance reasons, plan a controlled decryption of the affected databases using ALTER DATABASE [DatabaseName] SET ENCRYPTION OFF;, monitor the progress through sys.dm_database_encryption_keys, and restart the SQL Server service after all databases are decrypted to return tempdb to its unencrypted state.