What’s the issue?
SQL Server certificates, including those used to protect TDE database encryption keys, have an expiry_date property recorded in sys.certificates. The expiration date is set when the certificate is created and defaults to one year from creation if not specified explicitly, although administrators can set any future date or use the maximum supported value to effectively avoid expiration.This finding identifies TDE certificates that have an expiration date set. It is not necessarily a problem, but it is worth noting in case the team is unaware of the expiration date or unaware of how SQL Server handles certificate expiration for TDE.
The behavior of expired TDE certificates is an area where reasonable assumptions often differ from actual SQL Server behavior, which is the main reason this condition is worth surfacing.
Why is this a problem?
Unlike certificates used for SSL or TLS, an expired TDE certificate does not stop working. SQL Server continues to use the certificate to protect the database encryption key and to decrypt data even after the expiration date has passed, so encrypted databases continue to function and backups can still be taken and restored without interruption.Despite this, an expired certificate is still a meaningful operational issue. Some monitoring tools and audit processes flag expired certificates as findings, and certain restore scenarios on different SQL Server versions or in specific configurations can produce warnings that confuse the team during recovery. Expiration is also a useful trigger to review the certificate’s age, the strength of its key, and whether rotation is appropriate.
The bigger risk with TDE certificates is not expiration itself but rather inconsistent assumptions about expiration. Teams sometimes assume the certificate will need to be replaced before the expiration date and plan a rotation that, if mishandled, leaves the new certificate without a backup or fails to protect newer data correctly. The rotation process is where most TDE certificate problems actually occur.
Some organizations also have policies that require certificate rotation on a defined schedule for security reasons, regardless of whether SQL Server itself enforces expiration. Long lived certificates increase the impact of a potential certificate compromise, so rotating them periodically is a reasonable security practice even though SQL Server does not require it.
What should you do about this?
No remediation is required if the certificate is functioning correctly and the team is aware of the expiration date and has a documented decision about whether to rotate. Confirm the current expiration dates by querying sys.certificates for certificates protecting active database encryption keys, joining against sys.dm_database_encryption_keys.If certificate rotation is required by policy or desired for security reasons, plan the rotation carefully. The standard approach is to create a new certificate, alter each affected database encryption key to use the new certificate with ALTER DATABASE ENCRYPTION KEY REGENERATE, back up the new certificate immediately along with its private key, and retain the old certificate until all backups taken under it have aged out of retention.
Do not drop the old certificate until you are certain no encrypted backup taken under it will need to be restored, since the old certificate is still required to decrypt those backups. Keep the old certificate backup file in secure storage for the full retention period of the backups it protected, even after the certificate has been removed from the active instance.