App Service Key Vault reference stuck at AccessToKeyVaultDenied despite correct, verified RBAC role assignment (tried two separate identities)

Question

App Service Key Vault reference stuck at AccessToKeyVaultDenied despite correct, verified RBAC role assignment (tried two separate identities)

Muhammad Wasim Rashid 0

I have a Linux App Service (Node 24, West Europe region "Denmark East") with two app settings configured as Key Vault references:

Email__AcsConnectionString -> @Microsoft.KeyVault(SecretUri=https://kv-xxxxx.vault.azure.net/secrets/xxxxx/)
Unsubscribe__Secret -> @Microsoft.KeyVault(SecretUri=https://kv-xxxxx.vault.azure.net/secrets/xxxxx/)

Both are stuck in status AccessToKeyVaultDenied ("Key Vault reference was not able to be resolved because site was denied access to Key Vault reference's vault"), checked via:

GET /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{site}/config/configreferences/appsettings?api-version=2023-12-01

What I've verified (twice, with two completely different identities):

Original system-assigned identity had Key Vault Secrets User correctly assigned, scoped directly at the vault. Still denied after 24+ hours and two app restarts.
I then removed the managed identity entirely and re-added it (forcing a brand-new principal ID), granted the new identity Key Vault Secrets User at the vault scope, and restarted again. Still denied, immediately.
Key Vault config: enableRbacAuthorization: true, publicNetworkAccess: Enabled, networkAcls unset (no restrictions), no deny assignments on the vault.
The App Service has no VNet integration (virtualNetworkSubnetId: null, vnetRouteAllEnabled: false) - no possible network routing issue.
keyVaultReferenceIdentity is unset (defaults to SystemAssigned), matching the identity holding the role - no ambiguity from multiple identities.
No Azure Policy deny effects found affecting this resource group.

Since the failure persists identically across two unrelated identities, each freshly granted the correct role, this doesn't look like a propagation delay or a misconfigured role assignment - it looks like something stuck on the platform side for this specific Key Vault/App Service pairing.

Has anyone seen this exact failure mode (correct RBAC, still denied, persists across identity recreation)? What finally resolved it for you?

0 comments

1 answer

Your answer

Answer 1

Hello @Muhammad Wasim Rashid

Your RBAC configuration appears correct: with enableRbacAuthorization: true, the App Service managed identity needs the Key Vault Secrets User role at the vault or secret scope. Key Vault references use the system-assigned identity by default, so an unset keyVaultReferenceIdentity is expected in this configuration.

At this point, recreating the identity again is unlikely to provide useful evidence. Next, determine which identity Key Vault actually receives.

Enable the Key Vault AuditEvent diagnostic log, force another reference refresh, and inspect the resulting SecretGet request. Key Vault logs include the caller identity, object identifier, application ID, caller IP address, HTTP status, and result description.

Force the refresh with:

POST https://management.azure.com/{app-resource-id}/config/configreferences/appsettings/refresh?api-version=2022-03-01

App Service caches Key Vault references for up to 24 hours; this endpoint is the supported way to trigger an immediate refetch.

Compare the oid or object-identifier claim in the Key Vault log with the current App Service principalId:

If they differ, the platform resolver is using a different or stale identity.
If they match and Key Vault returns HTTP 403, the log’s result description should distinguish an RBAC denial from a firewall/network denial. HTTP 403 means the caller was authenticated, but authorization or network policy rejected the request.
If no SecretGet event appears after the forced refresh, the request isn’t reaching the vault, which points away from the Key Vault RBAC assignment.
If the correct identity reaches Key Vault successfully but App Service still reports AccessToKeyVaultDenied, the remaining evidence points to the App Service reference resolver or cached resolution state. This is an inference, not a documented root cause.

Also run the built-in Key Vault Application Settings Diagnostics detector under App Service → Diagnose and solve problems → Availability and Performance → Web app down. Microsoft specifically recommends this detector for unresolved Key Vault references.

If the logs confirm the correct principalId, an allowed network path, and repeated failures after a forced refresh, open an Azure support request for the Microsoft.Web resource provider. Include:

App Service and Key Vault resource IDs
UTC timestamps of the refresh attempt
Current App Service principalId and tenant ID
Key Vault SecretGet audit record and correlation ID
Output of the config-reference status API
Region, OS, and App Service plan
Results from the App Service diagnostic detector

The Key Vault audit record is the decisive evidence needed before classifying it as a platform-side resolver issue.

References:

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.