Azure 403 after assigning a role: control plane vs data plane, scopes and propagation

"I gave them Contributor and they still get 403" is the most common Azure access question there is, and the role assignment is usually fine. The call is being refused for a reason the role can't fix: the role manages the resource but the call reads its data; the role is at the wrong scope; the assignment exists but hasn't reached the service yet; or the request never got as far as an authorisation check because a firewall or private endpoint turned it away. This guide tells the four apart, gives the data-plane role each service wants, and sets out the waits that make people think a fix didn't work.

Read the error first

The message says which cause you have, if you read past "403":

Cause 1: the role is control plane and the call is data plane

Azure roles have two lists. Actions cover managing a resource through Resource Manager; DataActions cover using it through its own endpoint. Owner and Contributor have * in Actions and nothing in DataActions: they can create, configure and delete a storage account, and can't read a blob in it. That separation is deliberate, so a wildcard role can't read every byte in a subscription. The fix is the data-plane role for the service, at the resource or resource-group scope:

Three traps around this:

• Key Vault has two permission models. A vault on Azure RBAC (the default for new vaults since API version 2026-02-01) ignores access policies, and the Azure roles above apply. A vault on the legacy access policy model ignores Azure data roles, and the identity must be in the vault's Access policies. Switching a vault to RBAC invalidates every access policy at once; assign the roles first. Note that Key Vault Contributor is control plane only.
• Account keys are the loophole. Any control-plane role that includes Microsoft.Storage/storageAccounts/listKeys/action (Contributor does) can fetch the storage keys and read data with Shared Key authorisation, bypassing RBAC. That's why "I can read it in the portal" doesn't prove the role is right: the portal may be using the key. Disable shared-key access, and test with the identity that will do the work.
• Databricks workspaces. Storage data roles assigned at the subscription scope don't apply to a storage account inside a Databricks-managed resource group; assign at the resource group, account or container.

Cause 2: the wrong scope, or the wrong principal

Assignments inherit down the hierarchy: management group → subscription → resource group → resource. A role on resource group A gives nothing in resource group B, and a role on one storage account gives nothing on its neighbour. Check with az role assignment list --assignee <object id> --all -o table, and read the Scope column, not just the role name.

The principal has to be the one making the call:

• Which identity is it, really? DefaultAzureCredential may be using your az login account locally and the app's managed identity in Azure, or a user-assigned identity you forgot to name. Turn on the SDK's logging to see which credential produced the token.
• Same name, different object. Display names aren't unique. Assign by object ID (--assignee-object-id, with --assignee-principal-type), which also avoids the PrincipalNotFound replication error when you assign a role to an identity you created seconds ago.
• A new system-assigned identity after a redeploy. Deleting and recreating a resource creates a new principal; the old role assignment is now Identity not found, and a Bicep role assignment with the same name fails with RoleAssignmentUpdateNotPermitted. Name role assignments with guid(scope, principalId, roleDefinitionId) so they change when the principal does.
• A moved resource. Moving a resource to another resource group or subscription orphans role assignments made directly on it; recreate them.
• A guest, or a conditional assignment. Guests need an explicit assignment, and an assignment with a condition (for example "only these roles, only to users") can refuse what the role name promises.

Cause 3: it has not propagated yet

A Forbidden in the first minutes after a correct assignment is the service telling the truth about now. Add a retry with backoff to anything that assigns a role and uses it in the same run.

Cause 4: the network answered before RBAC did

A storage account or vault with public network access disabled, a firewall allow-list, or a private endpoint refuses requests that don't arrive the right way, and it says 403, not "connection refused". Signs it's the network: the message mentions a client address, trusted services, public access or a TCP connection; access works from one place and not another; it broke after a network or DNS change.

The usual culprit with a private endpoint is DNS: the client resolves myaccount.blob.core.windows.net to the public IP, so the request arrives on the public endpoint and the firewall rejects it. From the client, nslookup the name; a 10.x or 172.x private address means the private endpoint is in use, a public address means it isn't, and the fix is linking the private DNS zone to the virtual network, or forwarding the privatelink zone from your own DNS servers. Two more:

• A second host name. Data Lake (dfs), queues and tables have their own endpoints; a private endpoint for blobs doesn't cover them.
• Who's outside the network. The portal, a hosted pipeline agent and your laptop are outside the virtual network. Allow the trusted-services bypass, add the client IP temporarily, or run the agent inside the network.

Once the network is right and the 403 remains, it's cause 1 or 3 after all. Microsoft's private-endpoint troubleshooter runs the checks in that order: DNS, connection state, firewall, then the data-plane role.

Prove it before you close the ticket

# Who am I, and what does Azure think I hold?
az ad signed-in-user show --query id -o tsv
az role assignment list --assignee <object id> --all -o table

# Try the data plane as that identity, with Entra auth (not a key)
az storage blob list --account-name <account> --container-name <container> --auth-mode login -o table
az keyvault secret list --vault-name <vault> -o table

Run the same commands as the service's own identity where you can (az login --identity on a VM, or the app's logs), because the question is never whether you can read the data; it's whether the caller can.

Sources

• Understand Azure role definitions, Microsoft Learn (Actions and DataActions, the Owner example)
• Troubleshoot Azure RBAC, Microsoft Learn (propagation, caching, identity not found, moved resources)
• Authorize access to blobs by using Microsoft Entra ID, Microsoft Learn
• Troubleshoot 403 errors in Azure Blob Storage, Microsoft Learn
• Provide access to Key Vault with Azure role-based access control, Microsoft Learn
• Azure Key Vault REST API error codes, Microsoft Learn (403 causes)
• Troubleshoot 403 access denied errors for Storage or Key Vault through a private endpoint, Microsoft Learn
• Managed identity best practice recommendations, Microsoft Learn (the 24-hour cache)