What’s the issue?
SQL Server backup encryption protects backup files using a server certificate or asymmetric key, with the certificate created in the master database and referenced when backups are taken with the WITH ENCRYPTION clause. The certificate must be backed up using BACKUP CERTIFICATE, which produces both a certificate file and a private key file protected by a password.This finding indicates that one or more certificates currently being used for backup encryption have not had their private key backed up in the last 90 days, based on this column. The 90-day threshold reflects a common practice of confirming certificate backups on a quarterly cadence at minimum, ensuring that a current, verified backup of every active certificate is always available.
Why is this a problem?
Without a current backup of the certificate and private key, encrypted backups can only be restored on an instance where that certificate is already present (typically the source instance) and cannot be restored elsewhere. If the source instance is lost (hardware failure, ransomware, accidental drop of the master database), every encrypted backup taken under that certificate becomes permanently unreadable.This is one of the most common causes of unrecoverable data loss in environments using backup encryption. The encryption itself works as intended, the backups complete successfully, the recovery procedures look correct on paper, and 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 or recreated since the last backup. The current certificate in use no longer matches the backed up version, so a recovery using the old backup file will fail to decrypt newer encrypted backups even though a backup file exists. Without periodic verification, the team cannot tell whether the current backup file actually matches the active certificate. 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. Without this discipline, the certificate backup quietly drifts out of date until it is needed for recovery, by which point it is too late.
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 backup files themselves, ideally in your enterprise key management or secrets management system.Test the recovery path by importing the backed up certificate to a different instance and confirming that an encrypted backup can be restored using only the certificate backup files. This validates both the backup itself and the recovery procedure, and is the only way to be confident the protection actually works under pressure.
Schedule regular certificate backups and verification on a defined cadence, 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.