Azure SQL-Datenbank
Ein Azure-Dienst für relationale Datenbanken.
Azure SQL Server key vault access lost for one database which is using server level encryption
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 12%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETA%3C/text%3E%3C/svg%3E)
Toni August
0
Zuverlässigkeitspunkte
We use an Azure SQL Server with a couple databases in an elastic pool. A week ago one of the databases went into "Inaccessible" status.
On the TDE settings page for the database I get this message:
Access to Azure Key Vault has been lost for the server of this database. Follow the troubleshooting steps below to resolve this issue. Existing data will be inaccessible until this issue is resolved.
On the TDE settings page for the SQL Server I get this message:
Access to Azure Key Vault has been lost for this server. Follow the troubleshooting steps below to resolve this issue. Existing data will be inaccessible until this issue is resolved.
The SQL Server is using a Service-managed key for encryption and this was always set like this. The database which is having the issue temporarily used a Database level customer-managed key (CMK) but this was set back to Server-level encryption key 2 weeks ago and the database was working fine until 1 week ago where it was set to inaccesible probably through an automated process because it happened outside of our working hours and there is no username attached to the log entry.
Is there any way to resolve this? There is not much I can do in the Azure portal itself. The SQL Server is set to service-managed key and the database to server level encryption so there should be no key vault involved which is managed by us.
Thank you!
Azure SQL-Datenbank
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(16, 2%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMK%3C/text%3E%3C/svg%3E)
Manoj Kumar Boyini 17,220 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator2026-06-23T14:31:03.68+00:00 Hi @Toni August
I kindly request you to please share the details requested in the private message for further investigation.
Based on the symptoms and the error message shown on the TDE blade, Azure SQL is still detecting a dependency on Azure Key Vault for the database encryption protector. Even though the database was switched back to server-level encryption two weeks ago, the database becoming inaccessible with a Key Vault access error suggests that the database may still be referencing a customer-managed key (CMK) or encountered an issue during key validation.
To help narrow down the cause, could you please confirm:
- Whether the Azure Key Vault and key that were previously used for the database-level CMK still exist and are accessible.
- Whether any changes were made recently to the Key Vault, key permissions, managed identities, networking, private endpoints, firewall rules, or DNS configuration.
- Whether the key used previously has been disabled, deleted, or expired.
Common causes for this type of issue include:
Lost permissions to Azure Key Vault (Get, Wrap Key, Unwrap Key).
Deleted or unavailable Key Vault/key.
Expired or disabled encryption key.
Network, DNS, or Private Endpoint connectivity issues preventing Azure SQL from reaching Azure Key Vault.If you can provide the requested details, we can further investigate the current encryption protector state and determine whether the database is still associated with a customer-managed key or if additional backend investigation is required.
-
Toni August 0 Zuverlässigkeitspunkte
2026-06-23T15:01:11.28+00:00 thank you for your response! Let me give you more details:
The key vault and keys still exist. I can give you a timeline of things that happened as far as I know:
- long time ago
- Azure SQL Server & elastic pool was created
- Azure SQL database was created in the pool with default server level encryption key
- Azure Key Vault was created and a key was created
- a few weeks later the database encryption was changed to customer managed key using the key from the key vault
- 2 weeks ago
- the key vault was accidentaly deleted which made the database inaccessible
- the key vault including the keys was restored soon after and the database worked again
- the database encryption was set back to Server level encryption key and the database was still working fine
- 1 week ago
- the database was set to inaccessible due to the error mentioned in my original post
The Key Vault including the keys which were deleted at some point but were restored still exist today and are not deleted. Apart from that we didn't do any changes to the SQL Server, database or the Key Vault during the last 2 weeks.
All other SQL databases on this SQL server are working fine. They never had a customer managed key though.
Here is a screenshot from the databases data encryption page:
This is from the SQL Server Transparent data encryption page:
The validate key button always fails no matter what I choose. I can't choose an existing key or select a backup key because clicking on any of those options doesn't do anything and the view stays like it is in the screenshot.
Thanks for your help!
Toni
- long time ago
-
Manoj Kumar Boyini 17,220 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator
2026-06-23T15:46:13.37+00:00 Hello @Toni August
Thank you for the additional details.
It appears that the affected database may still have a dependency on the previously configured customer-managed key (CMK), even though the portal currently shows "Server level encryption key". The fact that the database became inaccessible after the Key Vault deletion/restoration event and continues to show Key Vault access errors suggests Azure SQL is still attempting to validate a key associated with the previous CMK configuration.Since the Key Vault and key still exist, could you please confirm:
- The original key version used by the database is still present, enabled, and not expired.
- Whether the Key Vault uses firewall restrictions, private endpoints, or custom DNS.
Additionally, please share the output of:
az sql db show --resource-group <RG> --server <ServerName> --name <DatabaseName> --expand-keysThis will help determine whether the database is still referencing a customer-managed TDE protector and why the key revalidation is failing.
Zum Kommentieren anmelden
Anmelden, um zu antworten