SQL Server on Azure VM with TDE via EKM and Azure Key Vault and Managed Identity Key rotation

Thanks @Santhosh Kumar Machukuri but in order to create a new asymmetric key, the credential needs to be mapped to the SQL sysadmin to perform this action. You cannot do that while the credential is still mapped to the existing TDE_Login.

`ALTER LOGIN [domain\sysadmin1]     ``

ADD CREDENTIAL [<akv-name>.vault.azure.net]

Hi NS,

Thank you for your observation — you are correct in noting the behavior around credential mapping.

In SQL Server TDE with EKM using Azure Key Vault, a credential can only be mapped to one login at a time. As a result, attempting to map the same Key Vault credential to another login (such as a sysadmin) while it is already associated with the existing TDE login will fail, which is expected behavior.

To proceed with key rotation, the recommended approach is:

• Use the existing credential that is already mapped to the current TDE login.
• Perform the key rotation by creating a new asymmetric key in SQL Server that references the updated key (or key version) in Azure Key Vault.
• Update the Database Encryption Key (DEK) to use the new asymmetric key.

There is no requirement to remap the credential to another login (such as sysadmin) if the current setup is correctly configured, as the EKM provider continues to use the existing credential for authentication.

This behavior is by design for SQL Server on Azure VM when using EKM with Azure Key Vault and Managed Identity.

Hi NS,

Let me know if you have got the chance to check my last message where I explained about credential mapping. Feel free to let me know if you have any questions.

Hi @Santhosh Kumar Machukuri
Thanks for your suggestion. Are you referring to this step to perform the key rotation:

CREATE ASYMMETRIC KEY NewASYKey  
          FROM PROVIDER [AzureKeyVault_EKM]  
          WITH PROVIDER_KEY_NAME = 'MyTdeKeyName/<new-version-id>';  
        CREATE LOGIN TDE_Login_New FROM ASYMMETRIC KEY NewASYKey;  
        ALTER LOGIN TDE_Login_New  
          ADD CREDENTIAL [vaultname.vault.azure.net];  

This can only be done with an account that has the credential is mapped to the sysadmin account performing this step. The new asymmetric cannot be created with the already mapped TDE Login.

Hi NS,

Yes — you’re on the right.

The step you mentioned is indeed part of the key rotation process. Creating a new asymmetric key from the Azure Key Vault provider is required when you want to point TDE to a new key (or a new key version).

However, just to clarify, rotation is not only this step. At a high level, the process is:

1. Create a new key (or new version) in Azure Key Vault
2. Create a new asymmetric key in SQL Server:

CREATE ASYMMETRIC KEY NewASYKey 
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = '<AKV key name>';

1. Create a login from this asymmetric key (if needed)
2. Update the database encryption key:

ALTER DATABASE ENCRYPTION KEY 
ENCRYPTION BY SERVER ASYMMETRIC KEY NewASYKey;

Also, regarding the credential part we discussed earlier:

• The same AKV credential is reused
• But SQL Server only allows it to be mapped to one login at a time, which is why you see conflicts when trying to use it across multiple logins during rotation

So yes — your step is correct, but it’s one part of the full rotation workflow.

@Santhosh Kumar Machukuri Thanks for your response.
Just to clarify, you are agreeing with me that there is a limitation and it's not possible to rotate the key without breaking the existing key? This would also have an impact on not being able to restore any backups from the prior key version

Hi NS,

Key rotation is supported in SQL Server with TDE and Azure Key Vault and does not require re-encrypting data or breaking existing encryption; however, the complexity arises from a SQL Server limitation where a credential can only be mapped to one login at a time.

During rotation, this creates a temporary conflict because the credential is needed by a privileged login to create a new asymmetric key but is already tied to the TDE login. This is not a limitation of key rotation itself, but an operational constraint that requires careful sequencing—temporarily remapping the credential, performing the key update, and then restoring the original mapping.

Hope this helps.

Hi @Santhosh Kumar Machukuri
Thank you for confirming. That would also mean that there is only one credential mapped at a time, as the named credential is now tied to TDE_Login_New as in the example below. In this case you would no longer be able to restore any backups with the old key. Prior to switching over keys, you would also have to decrypt the database first.
Would the only workaround be a service principal?
This does not seem very feasible operational perspective.

CREATE ASYMMETRIC KEY NewASYKey       
 FROM PROVIDER [AzureKeyVault_EKM]  

      WITH PROVIDER_KEY_NAME = 'MyTdeKeyName/<new-version-id>';  

    CREATE LOGIN TDE_Login_New FROM ASYMMETRIC KEY NewASYKey;  

    ALTER LOGIN TDE_Login_New  

      ADD CREDENTIAL [vaultname.vault.azure.net];

Hi NS,

Thanks for sharing your concerns — to clarify, rotating the TDE protector does not require decrypting the database, and it does not prevent restoring backups created with older keys, as long as those key versions are retained in Azure Key Vault. You are correct that only one login can have the credential mapped at a time; however, this only impacts which login can perform key management operations, not the ongoing use of the database encryption key. The database remains accessible and existing encryption continues to function normally. Also, using a service principal would not remove this limitation, as the one credential-to-login constraint still applies. The main challenge here is operational (managing credential mapping during rotation), rather than a limitation in the ability to rotate keys itself.

@Santhosh Kumar Machukuri
Thanks for your reply.
If you look at the snipped of the documentation I added above you will see that the Credential has to be mapped to the operational TDE_Login (TDE_Login_New), and the TDE_Login in turn is derived from the Asymmetric key (NewASYKey), you cannot map the credential ([vaultname.vault.azure.net]) to more than one login at a time.

This means if you switch the key without prior decryption, you would not have access to the key material once you switch to the new TDE_Login. In that case you would have to make sure you decrypt the database first. With access to the new key material using the new TDE_login the database can be encrypted again

Hi NS,

Thank you for pointing that out and referencing the documentation — you are correct that the credential must be mapped to the active TDE login (for example, TDE_Login_New) and that this login is derived from the asymmetric key.

However, an important distinction is that this requirement applies to key management operations, not to the ongoing usability of the database encryption. Once the database encryption key (DEK) is established, SQL Server does not rely on the active login/credential mapping for normal runtime operations or access to already encrypted data.

Additionally, even after switching to a new key and login, older key versions remain usable for restore operations, as long as they are retained in Azure Key Vault. SQL Server can still reference those keys when needed (for example, during restore), independent of which login currently has the credential mapped.

So while the documentation correctly describes the dependency between credential ↔ login ↔ asymmetric key for setup and rotation, it does not imply that switching the credential mapping invalidates previous keys or breaks restore scenarios. The limitation here remains operational (credential reassignment during rotation), not a functional restriction on key usage or recovery.

Hi NS,

I hope you are doing well. Kindly let us know if you have got the chance to check my last message. Feel free to let us know if you have any queries or concerns.

Hi Santosh, LEt me give this a try and get back to you