VM system-assigned managed identity denied access to Key Vault secrets after policy update

Cloud Platforms Microsoft Azure
, , , , , , , ,
1

We have a VM running an application that needs to retrieve connection strings from Key Vault at startup. The VM has a system-assigned managed identity enabled, but the app is failing to authenticate and getting access denied when trying to read secrets:


Azure.Identity.AuthenticationFailedException
Managed identity authentication failed
Response status code: 403 (Forbidden)

I’ve added the VM’s managed identity to the Key Vault access policies with “Get” and “List” permissions for secrets. The Key Vault access policy model is set to “Vault access policy” (not RBAC). The managed identity shows up in the access policies list, but the VM still can’t retrieve secrets. This is blocking our app from starting up. Could this be a managed identity permissions issue or do I need to configure the audit log review differently?

2

Look at the audit logs in Key Vault. Go to Diagnostic settings and enable audit logging if it’s not already on. The logs will show you exactly what identity is trying to access the vault and why it’s being denied. Check for events with operation name “SecretGet” and look at the caller identity and failure reason. This will tell you if it’s an access policy issue, firewall issue, or something else entirely.

3

Access policies usually propagate within a few minutes, not 30 minutes. Check if your Key Vault has a firewall configured. If the Key Vault networking is set to “Private endpoint and selected networks”, the VM’s subnet needs to be allowed in the firewall rules, or the VM needs to be in a subnet with a service endpoint for Key Vault. A firewall block would give you a 403 even with correct access policies.

Also verify the Key Vault’s “Permission model” setting. If it’s set to “Azure role-based access control” instead of “Vault access policy”, your access policies won’t work at all - you’d need to assign RBAC roles instead.

4

Let’s systematically troubleshoot this Key Vault access issue. The 403 error with managed identity can have several root causes:

1. Key Vault Access Policy Configuration Verify the access policy is correctly configured:


az keyvault show --name <vault-name> \
  --query properties.accessPolicies

Confirm:

  • The objectId matches your VM’s managed identity Object ID exactly
  • Permissions include “Get” for secrets (“List” is optional but helpful)
  • The tenantId matches your Azure AD tenant

If using Azure RBAC permission model instead of access policies:


az role assignment create \
  --assignee <managed-identity-object-id> \
  --role "Key Vault Secrets User" \
  --scope <keyvault-resource-id>

2. Managed Identity Permissions Verification Check that the managed identity is active and properly configured:


az vm identity show \
  --name <vm-name> \
  --resource-group <rg-name>

Verify:

  • type is “SystemAssigned” or “SystemAssigned, UserAssigned”
  • principalId exists and matches what’s in Key Vault access policies
  • Identity wasn’t recently re-enabled (which creates a new principalId)

Common issue: If you disabled and re-enabled the managed identity, the Object ID changed and your old access policies no longer apply. You must delete the old access policy and create a new one with the new Object ID.

3. Audit Log Review for Detailed Failure Analysis Enable Key Vault diagnostic logging:


az monitor diagnostic-settings create \
  --name kv-audit-logs \
  --resource <keyvault-resource-id> \
  --logs '[{"category":"AuditEvent","enabled":true}]' \
  --workspace <log-analytics-workspace-id>

Query for failed access attempts:

  • Look for CallerIdentity (should match your VM’s managed identity Object ID)
  • Check ResultType (should show why access was denied)
  • Review ClientIP (verify it’s from your VM’s IP range)
  • Check for any Conditional Access policy blocks

The audit logs will explicitly state whether the failure is due to:

  • Missing access policy
  • Insufficient permissions
  • Network firewall block
  • Conditional Access policy
  • Disabled Key Vault

Network Considerations If Key Vault has firewall enabled:


az keyvault network-rule add \
  --name <vault-name> \
  --subnet <subnet-id>

Or add the VM’s public IP if not using VNet integration. Better approach is to use Private Endpoint for Key Vault and ensure VM’s subnet can reach it.

Application Code Verification Ensure your application uses the correct authentication:


// .NET example
var credential = new DefaultAzureCredential();
var client = new SecretClient(
    new Uri("https://<vault-name>.vault.azure.net/"),
    credential
);

DefaultAzureCredential automatically uses managed identity when running on Azure VM.

Testing Steps

  1. Test from the VM directly using Azure CLI:

az login --identity
az keyvault secret show --vault-name <vault-name> --name <secret-name>

If this works but your app doesn’t, the issue is in application code, not access policies.

  1. If CLI also fails with 403:

    • Check Key Vault firewall (most common issue)
    • Verify access policy Object ID matches exactly
    • Review audit logs for specific denial reason

  2. Check for Azure Policy restrictions:

    • Organization-level policies might prevent managed identity access
    • Check Azure Policy compliance for both VM and Key Vault resources

After making any access policy changes, wait 2-3 minutes for propagation, then retry. If using RBAC model instead of access policies, RBAC can take up to 10 minutes to propagate in some cases.