Share via

I am getting Authentication issue when trying to change the storage account encryption settings to use CMK

Bharath Mohan 0 Reputation points
2026-05-07T05:22:27.3366667+00:00

There is one env prd01 storage account in the same subscription able to connect to KV with system assigned Identity, I am not able to connect with rest, I have even tried to create a Manual managed identity and have given the role Key Vault Crypto Service Encryption User to the expected key vault, I am getting storage account is not authorized to connect to key vault message.

Azure Storage
Azure Storage

Globally unique resources that provide access to data management services and serve as the parent namespace for the services.


2 answers

Sort by: Most helpful
  1. Venkatesan S 8,485 Reputation points Microsoft External Staff Moderator
    2026-05-07T06:10:00.8966667+00:00

    Hi Bharath Mohan,

    Thanks for reaching out in Microsoft Q&A forum,

    I am getting storage account is not authorized to connect to key vault message.

    When you try to change the storage account encryption to use customer‑managed keys (CMK) and run into an “authentication issue,” it usually means that the storage account’s managed identity is not allowed to authenticate to the key vault. This can happen even if the key vault, key, and identity exist, because the permissions or identity linkage are not configured correctly. The error is Azure’s way of saying “this storage account is not authorized to use the key from that vault.”

    In practice, the CMK‑setup flow is simple but strict: the storage account must have a managed identity, the key vault must be enabled for CMK use, and that identity must be granted explicit cryptographic permissions on the key vault (via Azure RBAC or access policies). If any of these pieces is missing or mis‑aligned such as assigning the role to a different identity or forgetting to enable soft delete on the vaultthe operation will fail with an authentication‑like error.

    Check the below steps in your environment:

    1. Enable a managed identity on the storage account
    • Turn System‑assigned identity to On, or assign a User‑assigned managed identity on the storage account. This identity is what Azure uses to call the key vault on your behalf.
    1. Prepare the key vault for CMK
      • Ensure the key vault has soft delete and purge protection enabled, which is a hard requirement for CMK‑enabled storage accounts.
    2. Grant the right permissions on the key vault
      • If the key vault uses Azure RBAC:
        • In Access control (IAM), assign the Key Vault Crypto Service Encryption User role to the storage account (for system‑assigned) or to the user‑assigned identity. This role allows the identity to read key metadata and perform wrap/unwrap operations.
      • If the key vault uses Access policies (legacy):
        • Add an Access policy entry for the storage account’s managed identity and grant Get, Wrap Key, and Unwrap Key permissions on keys.
    3. Check network and identity alignment
      • If the key vault is behind a firewall or private endpoint, ensure that trusted Microsoft services can reach it (for example, by enabling “Allow trusted Microsoft services”).
      • Verify that the identity you see in the storage account’s Identity blade is the exact one that has the role assigned; mismatched identities are a common cause of this error.
    4. Re‑apply the CMK configuration cleanly
      • Temporarily switch the storage account back to Microsoft‑managed keys, then re‑enable CMK after a short wait so the updated permissions and identity state can propagate.
      • In templates (ARM/Bicep/Terraform), ensure the identity is created and enabled before you try to configure CMK; interleaving these steps can trigger transient authentication‑style failures.

    Reference:

    Kindly let us know if the above helps or you need further assistance on this issue.

    Please do not forget to 210246-screenshot-2021-12-10-121802.pngand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-05-07T05:22:41.5666667+00:00

    To change Azure Storage encryption to use a customer-managed key (CMK) in Key Vault, the storage account’s managed identity must be correctly configured and authorized on the Key Vault. The working prd01 account is a good baseline; the others are failing because the identity used for encryption is not authorized to access the key.

    Use the following checks and steps for each non-working storage account:

    1. Confirm which identity the storage account is using
    • For existing accounts using CMK, Azure Storage can use either:
      • System-assigned managed identity, or
      • A user-assigned managed identity.
    • In the portal (or via CLI/PowerShell), check the Identity blade of the storage account and verify:
      • System-assigned identity is On if you intend to use it, or
      • The correct user-assigned managed identity is attached.
    1. Ensure the identity is actually assigned to the storage account
    • System-assigned identity (PowerShell example from context):
        $accountName = "<storage-account>"
        
        $storageAccount = Set-AzStorageAccount -ResourceGroupName $rgName `
            -Name $accountName `
            -AssignIdentity
      
    • Azure CLI equivalent:
        accountName="<storage-account>"
        
        az storage account update \
            --name $accountName \
            --resource-group $rgName \
            --assign-identity
      
    • For user-assigned identity, ensure it is explicitly attached to the storage account in the Identity blade.
    1. Grant the correct Key Vault role to the correct identity
    • When Key Vault uses RBAC (not access policies), the identity used by the storage account must have the Key Vault Crypto Service Encryption User role on the Key Vault (or the specific key scope):
      • PowerShell example:
            $principalId = $storageAccount.Identity.PrincipalId
            
            New-AzRoleAssignment -ObjectId $principalId `
                -RoleDefinitionName "Key Vault Crypto Service Encryption User" `
                -Scope $keyVault.ResourceId
        
      • Azure CLI example:
            principalId=$(az storage account show --name $accountName \
                --resource-group $rgName \
                --query identity.principalId \
                --output tsv)
            
            az role assignment create --assignee-object-id $principalId \
                --role "Key Vault Crypto Service Encryption User" \
                --scope $kvResourceId
        
    • Common pitfalls:
      • Role is assigned to the wrong object (e.g., app registration instead of the storage account’s managed identity object ID).
      • Role is assigned at subscription/resource group level but Key Vault is using access policies instead of RBAC.
    1. If Key Vault uses access policies instead of RBAC
    • The identity must have Get, Wrap, and Unwrap permissions on the key used for CMK (this pattern is shown for Backup and Cosmos DB but applies similarly to CMK scenarios):
      • Ensure the managed identity used by the storage account has these permissions on the key.
    1. Verify Key Vault and key state
    • Ensure:
      • Key Vault exists and is reachable (network/firewall rules allow the storage account to reach it).
      • The key is not deleted, disabled, or expired.
      • No recent changes removed the identity’s permissions or deleted the identity.
    1. Compare with the working prd01 storage account
    • For prd01, note:
      • Which identity is configured (system-assigned or user-assigned).
      • Whether Key Vault is using RBAC or access policies.
      • Exact role assignments or access policies on the Key Vault.
    • Replicate the same pattern for the non-working storage accounts.
    1. After fixing permissions
    • After assigning or correcting the Key Vault Crypto Service Encryption User role (or equivalent access policy permissions), retry updating the encryption settings to use CMK.
    • Some services require up to an hour for permission changes to propagate; if errors persist beyond that, re-check identity and role assignments.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.