Renaming an Azure SQL DB encrypted with DB level-CMK can render it Inaccessible

Microsoft

Feb 25, 2026

Issue

An issue was brought to our attention recently by a customer where we noticed that the cx DB was Inaccessible. On further investigation, it was concluded that the database was encrypted with DB level CMK & the DB was renamed, which had made it 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. "

Mitigation

Please start by validating the following:

Key Vault key is active, enabled, RSA 2048, no expiration.

Managed identity exists and has correct RBAC role.

Firewall and private endpoints are fine with no changes.

As mentioned in our Public documentation, after renaming an Azure SQL database, the identities on the DB must be reassigned. To reassign the identity, set the managed identity to None after your resource name (Azure SQL DB Name) changes and then apply the same user assigned managed identity to it.

Additional Questions:

After the primary DB is Online, do I have to fix the Geo-DR or Any Replica DBs?

As mentioned in the Public Documentation- "Once the database is back online, previously configured server-level settings, including failover group configurations, tags, and database-level settings such as elastic pool configurations, read scale, auto pause, point-in-time restore history, long-term retention policy, and others are lost. Hence, it's recommended that customers implement a notification system to detect the loss of encryption key access within 30 minutes. After the 30-minute window has expired, we advise validating all server and database level settings on the recovered database." To reestablish primary-secondary link (After 30 Min duration), customers have to delete failover group, create geo-replica, create secondary db, recreate failover group and add the db to the failover group.

Deleting the Failover Group:

Creating the Geo-Replica:

Now Secondary DB is created successfully:

Now Recreate the Failover Group:

Add the DB to the Failover Group:

DB added to the Failover Group

2. Does the requirement to reassign the managed identity applies exclusively to Azure SQL Database and Azure SQL Managed Instance, or if this behavior also affects any other managed database services offered in Azure or any other service ? (i.e: postgres flexible server, MySQL etc.

This issue is specific to “Database Level CMK in Azure SQL” which is our new and recent offering. Since the identities are assigned to a database resource, if you change the resource the customer owning the identity needs to make sure that the new resource has the new identity. (Azure SQL Managed Instance does not support database level CMK)

This is NOT a problem/requirement for Server level CMK in Azure SQL. Other Azure managed database services (for example, Azure Database for PostgreSQL Flexible Server, MySQL, or MariaDB) use different encryption and keymanagement implementations and do not exhibit this same managedidentity reassignment behavior after rename operations.

3. Can an end-customer share notification of Loss of DB level CMK?

Not exactly, but please check the public documentation to monitor key status. You may also subscribe to various key vault alerts, which will notify them about key expiry or any changes in key permissions.