What’s the issue?
SQL Server supports backup encryption, available since SQL Server 2014, which protects backup files using a server certificate or asymmetric key along with a chosen encryption algorithm. The certificate used for backup encryption is created in the master database and is referenced when backups are taken with the WITH ENCRYPTION clause.
Like all SQL Server certificates, backup encryption certificates have an expiry_date property that records when the certificate is considered expired. The expiration date is set at creation time and defaults to one year from creation if not specified explicitly.
This finding identifies instances where one or more certificates being used for backup encryption have passed their expiration date.
Why is this a problem?
For backup encryption specifically, SQL Server does check certificate expiration at backup time. When a new backup is attempted using an expired certificate, the engine raises the error “The certificate specified for backup encryption has expired” and the backup fails. This is different from TDE certificate behavior, where expired certificates continue to function with only a warning.
Restore operations are not affected by certificate expiration. An expired certificate can still be used to decrypt and restore backups that were taken under it, which is essential for recovering data after the certificate has aged out. The expiration only blocks new backups, not access to existing ones.
The most common operational impact is silent backup failure. Scheduled backup jobs configured to use an expired certificate begin failing immediately after the expiration date, and unless monitoring catches the failures promptly, the database can go without successful encrypted backups for an extended period. This produces a recovery gap that may not be visible until a restore is needed.
The bigger long-term risk with backup encryption certificates is the same as with TDE: certificate management discipline. The expired certificate must still be retained as long as any backup taken under it exists, since dropping it makes those backups permanently unreadable. Organizations sometimes assume that an expired certificate has been rotated and the old one can be removed, when in fact it is still required for restore.
What should you do about this?
Review backup job history for failed backups citing the expired certificate error, since these are the immediate operational impact.
Create a new certificate in master with an appropriate expiration date, back up the new certificate and its private key immediately to a secure location separate from the backup files, and update backup scripts and jobs to reference the new certificate. If backups are configured through maintenance plans, remember to update the BackupEncryptorName property in the plan itself, since changing the script alone does not affect the maintenance plan settings.
Take a fresh encrypted backup using the new certificate to confirm the configuration works, and verify the backup can be restored successfully on a different instance using only the certificate backup files. This validates both the new certificate and the recovery procedure end to end.
Do not drop the old, expired certificate until you are certain no encrypted backup taken under it will need to be restored. The expired certificate is still required to decrypt those backups, so retain the certificate (and its backup file) for the full retention period of the backups it protected. Once all such backups have aged out of retention, the old certificate can be safely removed from the master database.