Detent PointTDE encrypts the database with a database encryption key, and that key is itself protected by a server certificate in master. The backup file carries the encrypted data; it does not carry the certificate. To restore it anywhere — a DR server, a new instance, a colleague’s machine for a repro — that server needs the same certificate first. Without it, SQL Server refuses the restore with a message naming a thumbprint it cannot find.
The failure mode that hurts is the quiet one: TDE gets enabled, the backups run green for months, and nobody notices the certificate was never backed up. The gap only shows up the day someone tries to restore on another box — which is exactly the day they can least afford to find out.
Backing up the database does not back up the certificate. That is a separate BACKUP CERTIFICATE statement that writes two files — the certificate and its private key — protected by a password you choose and keep somewhere the database backups are not. Do it once when TDE goes on, and again whenever the certificate is rotated.
The private-key file lands with a restrictive ACL — readable only by the SQL Server service account and administrators — so moving it to another server is a deliberate act, not an accident. That is the safe default; it also means a cross-server restore has a permission step that is easy to miss by hand.
The check you want is read-only and needs no licence. test_sql_tde_configuration reports the database master key, the TDE server certificate, whether that certificate’s private key has been backed up, and which databases are encrypted. get_sql_cert_inventory puts the TDE certificate alongside every other certificate surface on the instance with its expiry, so a certificate quietly approaching its expiry date shows up before it becomes an outage.
Neither changes anything, so both are safe to run against production on any instance you manage.
The restore path is the part worth proving rather than assuming. In live testing, a TDE-encrypted database backed up on one instance failed to restore on a second instance that lacked the certificate, was recovered by restoring the certificate there first — same thumbprint — and then restored online with the original data intact. That is the sequence a real DR runbook depends on, and the free audit above is what tells you, in advance, whether you are set up to run it.