What’s the issue?
Transparent Data Encryption (TDE) protects database files, log files, and backups by encrypting them with a database encryption key, which is itself protected by a certificate or asymmetric key in the master database. The certificate must be backed up using BACKUP CERTIFICATE, with both the certificate file and the private key file written to disk and protected by a password.This finding indicates that one or more TDE certificates currently in use have not been backed up in the last 90 days, based on the pvt_key_last_backup_date column in sys.certificates. The threshold reflects a common practice of confirming certificate backups on a quarterly cadence at minimum.
A missing or stale certificate backup is one of the most consequential gaps in a TDE configuration, since it directly affects whether encrypted data can be recovered.
Why is this a problem?
Without a current backup of the TDE certificate and its private key, encrypted databases and encrypted backups cannot be restored on any instance other than the one that originally created them. If the source instance is lost (hardware failure, ransomware, accidental drop of the master database), every encrypted database and every encrypted backup becomes permanently unreadable.This is one of the most common causes of unrecoverable data loss in TDE environments. The encryption itself works as intended, the backups appear to complete successfully, and recovery procedures look sound on paper, but the missing certificate turns a routine restore into a permanent loss event.
A stale certificate backup is similarly risky if the certificate has been rotated, recreated, or modified since the last backup. The current certificate in use no longer matches the backed up version, so a recovery using the old backup will fail to decrypt newer encrypted data even though a backup exists.
The 90-day threshold is not a hard requirement but reflects the reality that certificate state can change without anyone realizing, and a regular verified backup is the only reliable way to confirm the protection is still effective.
What should you do about this?
Back up each affected certificate immediately using BACKUP CERTIFICATE. Store the certificate file, the private key file, and the password in a secure location separate from the database backups, ideally in your enterprise key management or secrets management system.Test the restore path by importing the backed up certificate to a different instance and confirming that an encrypted backup can be restored using it. This validates both the backup itself and the recovery procedure, and is the only way to be confident the protection actually works.
Schedule regular certificate backups and verification, ideally quarterly, and add the certificate backup status to your standard health check and audit process. Document the certificate name, backup location, password storage, and last verified restore date for each instance, so the protection remains intentional and the recovery path is always known.