Azure SQL Server key vault access lost for one database which is using server level encryption

Question

Azure SQL Server key vault access lost for one database which is using server level encryption

Toni August 20

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!

Toni August 20 Zuverlässigkeitspunkte

2026-06-23T15:01:11.28+00:00
Hi @Manoj Kumar Boyini

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
Manoj Kumar Boyini 18,435 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-keys

This will help determine whether the database is still referencing a customer-managed TDE protector and why the key revalidation is failing.

Toni August 20

Hello @Manoj Kumar Boyini

here are some more details:

The key in the Key vault still exists. I can see that it was created on 6/17/2025. It has no expiration date. As mentioned, the Key vault was deleted and restored 2 weeks ago. Apart from adding a role assignment to the key vault no other log entries are available for the last 2 weeks. The last log entry is from 2 weeks ago.
There are no firewall restrictions. Access is allowed from all public networks. No private endpoints are defined.

Here is the requested output of az sql db show for the database:

{
  "autoPauseDelay": null,
  "availabilityZone": "NoPreference",
  "catalogCollation": "SQL_Latin1_General_CP1_CI_AS",
  "collation": "SQL_Latin1_General_CP1_CI_AS",
  "createMode": null,
  "creationDate": "2025-12-30T13:21:37.710000+00:00",
  "currentBackupStorageRedundancy": "Geo",
  "currentServiceObjectiveName": "ElasticPool",
  "currentSku": {
    "capacity": 0,
    "family": null,
    "name": "ElasticPool",
    "size": null,
    "tier": "Standard"
  },
  "databaseId": "47648ecb-184c-4b81-b418-48ba9c2fe2eb",
  "defaultSecondaryLocation": "northeurope",
  "earliestRestoreDate": "2026-06-17T07:18:37.374701+00:00",
  "edition": "Standard",
  "elasticPoolId": "/subscriptions/xxxxxx/resourceGroups/rgp_xxxxxx/providers/Microsoft.Sql/servers/xxxxxx/elasticPools/edp_xxxxxx",
  "elasticPoolName": "edp_xxxxxx",
  "encryptionProtector": null,
  "encryptionProtectorAutoRotation": false,
  "failoverGroupId": null,
  "federatedClientId": null,
  "freeLimitExhaustionBehavior": null,
  "highAvailabilityReplicaCount": null,
  "id": "/subscriptions/xxxxxx/resourceGroups/rgp_xxxxxx/providers/Microsoft.Sql/servers/xxxxxx/databases/xxxxxx",
  "identity": {
    "tenantId": null,
    "type": "None",
    "userAssignedIdentities": null
  },
  "isInfraEncryptionEnabled": false,
  "keys": {},
  "kind": "v12.0,user,pool",
  "ledgerOn": false,
  "licenseType": null,
  "location": "westeurope",
  "longTermRetentionBackupResourceId": null,
  "maintenanceConfigurationId": "/subscriptions/xxxxxx/providers/Microsoft.Maintenance/publicMaintenanceConfigurations/SQL_Default",
  "managedBy": null,
  "manualCutover": null,
  "maxLogSizeBytes": null,
  "maxSizeBytes": 42949672960,
  "minCapacity": null,
  "name": "xxxxxx",
  "pausedDate": null,
  "performCutover": null,
  "preferredEnclaveType": null,
  "readScale": "Disabled",
  "recoverableDatabaseId": null,
  "recoveryServicesRecoveryPointId": null,
  "requestedBackupStorageRedundancy": "Geo",
  "requestedServiceObjectiveName": "ElasticPool",
  "resourceGroup": "rgp_xxxxxx",
  "restorableDroppedDatabaseId": null,
  "restorePointInTime": null,
  "resumedDate": null,
  "sampleName": null,
  "secondaryType": null,
  "sku": {
    "capacity": 0,
    "family": null,
    "name": "ElasticPool",
    "size": null,
    "tier": "Standard"
  },
  "sourceDatabaseDeletionDate": null,
  "sourceDatabaseId": null,
  "sourceResourceId": null,
  "status": "Inaccessible",
  "tags": null,
  "type": "Microsoft.Sql/servers/databases",
  "useFreeLimit": null,
  "zoneRedundant": false
}

Thank you for your help!

Toni

Antwort, die vom Frageautor angenommen wurde

Manoj Kumar Boyini 18,435 Externe Microsoft-Mitarbeiter Moderator

Hi @Toni August

Our analysis indicates that the database was previously configured with a database-level customer-managed key (CMK). Although the database was later switched back to server-level encryption after the Azure Key Vault recovery, a residual reference to the previously configured encryption key was not fully removed.

As part of Azure SQL Database's periodic Transparent Data Encryption (TDE) validation process, the service attempted to validate access to the historical key reference. Because the managed identity previously associated with the CMK configuration was no longer available, the validation could not be completed, causing the database to transition to the Inaccessible state.

To resolve the issue, please:

Reassign the user-assigned managed identity that was previously used for the CMK configuration to the logical SQL server.
Verify that the Azure Key Vault key previously used for TDE is present, enabled, and accessible.
Ensure the managed identity has the required Azure Key Vault permissions: Get, Wrap Key, and Unwrap Key.
Retry the key validation operation from the Transparent Data Encryption (TDE) settings page.

Once key validation succeeds, the database should transition back to an accessible state.

0 Kommentare

1 zusätzliche Antwort

Ihre Antwort

Toni August 20 Zuverlässigkeitspunkte

2026-06-23T15:01:11.28+00:00

Hi @Manoj Kumar Boyini

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
Manoj Kumar Boyini 18,435 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-keys

This will help determine whether the database is still referencing a customer-managed TDE protector and why the key revalidation is failing.

Answer 1

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.