What’s the issue?
QL Server’s Transparent Data Encryption (TDE) protects data at rest by encrypting database files, log files, and backups using a database encryption key (DEK), which is itself protected by a certificate or asymmetric key stored in the master database. The encryption is transparent to applications, since SQL Server handles encryption and decryption automatically as data is read and written.This finding identifies one or more databases on the instance that are currently encrypted with TDE. It is not necessarily a problem, but it is worth noting in case the team is unaware that TDE is in use, or unaware of the operational considerations that come with it.
TDE is commonly enabled to meet compliance requirements (PCI DSS, HIPAA, GDPR), to protect data on shared or cloud storage, or as part of a defense in depth strategy against unauthorized access to physical files.
Why is this a problem?
TDE adds CPU overhead because every page must be encrypted on write and decrypted on read. The cost is usually small for most workloads but can become measurable on systems with very high I/O rates, particularly when combined with other CPU intensive features.Enabling TDE on any user database also automatically encrypts tempdb, which affects the entire instance regardless of which other databases are encrypted. Once tempdb is encrypted, it remains so until TDE is removed from every user database on the instance, which makes the decision effectively instance wide rather than database specific.
The most critical operational concern with TDE is certificate management. The certificate that protects the database encryption keys must be backed up and stored securely in a location separate from the database backups, since the loss of the certificate makes every encrypted database and every encrypted backup permanently unrecoverable. This single point of failure is by far the most common cause of unrecoverable TDE data loss.
TDE also interacts with several other features in ways that need to be planned. For instance, encrypted databases cannot be restored to instances that do not have the matching certificate, and Always On Availability Group failovers require certificates and keys to be present on every replica.
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 databases are encrypted by querying sys.dm_database_encryption_keys, and identify the certificate or asymmetric key protecting each database encryption key.Verify that the TDE certificate has been backed up using BACKUP CERTIFICATE, including both the certificate file and the private key file with a strong password, and that the backup is stored in a secure offsite location separate from the database backups themselves. Test the restore path periodically by restoring an encrypted backup to a different instance using the certificate backup, so the team has confidence the recovery procedure works under pressure.
Document the TDE configuration including which databases are encrypted, the certificate name and location, the password protecting the private key (stored in your secrets management system, not alongside the certificate), and the rotation schedule. Plan certificate rotation at appropriate intervals, since long lived certificates increase the impact of a certificate compromise and most compliance frameworks expect periodic rotation.