If you rename an Azure SQL Database encrypted with Transparent Data Encryption (TDE) using database level Customer-Managed Keys (CMK), the database can become inaccessible unless you reassign its Managed Identity immediately after the rename.
This behavior is specific to TDE with database-level CMK and does not apply to TDE with server-level CMK. This post explains who is affected, why this happens, how to prevent it and how to recover if your database becomes inaccessible.
Here’s the error message you may get:
Azure portal shows the error:
“Access to Azure Key Vault has been lost for this database. Existing data will be inaccessible until this issue is resolved.”
Attempting Key revalidation in the portal produces:
"AADSTS1000901: The provided certificate cannot be used for requesting tokens. The value of token_not_after on the certificate should be greater than the current time. "
Who is affected?
You may be affected if all of the following are true:
- Your Azure SQL Database uses database‑level CMK for Transparent Data Encryption (TDE)
- The database is renamed (for example, from database_old to database_new)
- The user‑assigned managed identity is not reassigned after the rename
This issue does not affect:
- Databases using server‑level CMK
- Azure SQL Managed Instance (database‑level CMK is not supported there)
- Other Azure managed database services such as Azure Database for PostgreSQL, MySQL, or MariaDB, which use different encryption and identity models
Why does this happen?
With TDE with database‑level CMK, Azure SQL Database uses a user‑assigned managed identity that is bound to the database resource to access the encryption key stored in Azure Key Vault.
When a database is renamed, the underlying Azure resource name changes. As a result, the managed identity association must be explicitly reassigned to the renamed database resource. If this step is missed, the database can lose access to the Key Vault key and transition to an inaccessible state.
In some cases, the database may appear to function normally for a period of time after the rename. This behavior is not guaranteed and should not be relied upon.
How to prevent this issue?
If you plan to rename a database that used TDE with database‑level CMK:
- Immediately after renaming the database, reassign the managed identity:
-
- Set the managed identity to None
- Reapply the same user‑assigned managed identity
Do not delay this step. Waiting increases the risk of the database becoming inaccessible.
Important
If your workflow involves frequent database renames, consider using TDE with server‑level CMK, which does not require identity reassignment after rename operations.
Mitigation - How to recover an inaccessible database
If your database has already become inaccessible after a rename, follow the steps below.
Step 1: Verify Key Vault and identity prerequisites
Before attempting recovery, confirm that:
- The key vault key is enabled, active, and uses RSA 2048 or 3072
- The user‑assigned managed identity exists and has the correct key vault permissions
- Firewall rules and private endpoints have not changed
Step 2: Reassign the managed identity
- In the Azure portal, navigate to the renamed Azure SQL Database
- Under Identity, set the managed identity to None
- Reassign the same user‑assigned managed identity that was previously configured
Step 3: Revalidate the encryption key
- In the Azure portal, go to Transparent data encryption blade of the Azure SQL Database
- Select Revalidate key
Once the key is successfully revalidated, the database should transition back to an online state.
Step 4: Restore geo‑replication (if applicable)
If the database was part of a failover group, the geo‑replication link will be broken and must be re‑created:
- Delete the existing failover group
- Create a new geo‑replica (the old secondary database can be deleted)
- Recreate the failover group and add the database
For more information on "how to configure a failover group", please see Configure a Failover Group - Azure SQL Database
How to be notified of loss of database-level CMK?
Azure SQL Database does not provide a direct notification when a database loses access to its key vault key. However, you can:
- Monitor encryption status using Azure SQL Database diagnostic views
- Configure Azure Key Vault alerts for key expiry or permission changes
Microsoft recommends implementing monitoring to detect key access issues within 30 minutes to minimize downtime.
References:
Configure Azure Key Vault alerts | Microsoft Learn
Configure a Failover Group - Azure SQL Database | Microsoft Learn
Microsoft