Azure AuthorizationFailed Troubleshooting Guide

Azure's AuthorizationFailed error says a principal lacked permission for an action at a scope, but the same symptom comes from missing roles, wrong scopes, stale tokens, deny assignments, role conditions and data plane gaps, and each needs a different fix. Under pressure, teams often respond by granting Owner or Contributor, which rarely fixes data plane errors and always leaves a service principal or managed identity over-privileged. This guide works through the error as a troubleshooting problem: the exact message, the likely causes from most to least common, how to diagnose each, the fix, and how to prevent recurrence. It also separates AuthorizationFailed from look-alike errors such as RequestDisallowedByPolicy and LinkedAuthorizationFailed. It is for cloud engineers, platform teams and identity administrators. Messages and timings were checked against Microsoft Learn on 11 November 2026.

Key takeaways

The message tells you three things. The object ID of the caller, the action string and the scope are all in the error; check each before changing a role.
Deny assignments win. Azure Resource Manager checks deny assignments before role assignments, so a correct role can still fail.
Management roles are not data roles. Owner and Contributor manage a storage account but do not grant blob data access through Microsoft Entra ID; data actions need data roles such as Storage Blob Data Reader.
Allow for propagation and caching. Role assignment changes can take up to 10 minutes, management group data plane changes several hours, and managed identity caches around 24 hours.
Policy is not permission. RequestDisallowedByPolicy is Azure Policy blocking what you deploy, not RBAC blocking who you are. More roles will not fix it.

Reading the error

Microsoft documents the message as The client with object id does not have authorization to perform action over scope (code: AuthorizationFailed); in practice the fields are filled in, and for guest users Microsoft shows the form The client '<client>' with object id '<objectId>' does not have authorization to perform action '<action>' over scope '<scope>' or the scope is invalid. Extract:

Object ID: the user, service principal or managed identity that called. Confirm it is the identity you meant; a pipeline may be using a different service connection or a VM's system-assigned identity rather than its user-assigned one.
Action: the resource provider operation, such as Microsoft.Compute/virtualMachines/write or Microsoft.Authorization/roleAssignments/write. This is the permission a role must contain.
Scope: the full resource ID. A typo in a subscription or resource group name also produces "or the scope is invalid".

How Azure decides, and where it fails

Microsoft describes the access check as a sequence. Each step is a place where the request can be refused:

Step (Microsoft Learn)	What can go wrong	Symptom
1. Principal acquires a token for Azure Resource Manager, including transitive group memberships	Token issued before a new group membership or role; wrong tenant	Fails until sign-out or token refresh; `InvalidAuthenticationTokenTenant`
2 and 3. ARM retrieves role and deny assignments for the resource	Assignment at the wrong scope, or orphaned after a resource move	`AuthorizationFailed`
4. If a deny assignment applies, access is blocked	Deployment stack deny settings or other Azure-managed deny assignments	`AuthorizationFailed` despite a correct role
5 and 6. Effective permissions computed: `Actions - NotActions`, `DataActions - NotDataActions`	Custom role excludes the action; management role used for a data action	`AuthorizationFailed` or a service error such as `AuthorizationPermissionMismatch`
7 to 9. Role assignment conditions evaluated	ABAC condition not met	Message mentions "an ABAC condition not fulfilled"

Causes, most common first

1. No role with the action at that scope

Diagnose: in the portal, open the scope, then Access control (IAM), then Check access for the principal; or list assignments with Get-AzRoleAssignment -Scope /subscriptions/$subId filtered by object ID. Microsoft notes that listing by -ObjectId can lag about 10 minutes behind changes.
Fix: assign the narrowest built-in or custom role containing the action at the lowest workable scope. Microsoft's example is Virtual Machine Contributor on the resource group to manage VMs in it.
Prevent: define deployment identities' roles in code alongside the resources they manage.

2. The change has not taken effect

Timings from Microsoft: role assignment changes can take up to 10 minutes. Built-in roles with DataActions assigned at management group scope may not update on the data plane for several hours (the Storage documentation warns of up to 12 hours for data actions). Managed identity back ends cache group and role membership per resource URI for around 24 hours. A new child management group can take up to 10 minutes to inherit the parent's assignments.
Fix: sign out and in (portal, CLI, PowerShell) or acquire a fresh token for REST calls. For managed identities, wait or restart the workload so it requests a new token. Avoid management group scope where timely grant or revocation matters.

3. Management plane role used for a data plane action

Diagnose: the failing operation reads or writes data (blobs, queues, secrets) and the principal holds only Owner, Contributor or a service contributor role. Microsoft states that these roles "don't provide access to the blob data within that account via Microsoft Entra ID".
Fix: assign a data role (Storage Blob Data Reader, Contributor or Owner, or the service's equivalent). Storage returns AuthorizationPermissionMismatch in this situation; Microsoft advises allowing replication time and checking for deny assignments.
Watch for: roles containing Microsoft.Storage/storageAccounts/listKeys/action let a principal bypass this by using Shared Key. A data error that "goes away" when someone switches to account keys has been hidden, not fixed.

4. Deny assignment

Diagnose: Access control (IAM), Deny assignments tab at the scope (needs Microsoft.Authorization/denyAssignments/read). Review Users, Denied Permissions and Properties, including excluded principals and DoNotApplyToChildScopes.
Context: Microsoft states that you cannot create your own deny assignments directly; they are created and managed by Azure, for example from deployment stack deny settings. Customer-managed deny assignments are in private preview.
Fix: change the resource through the owning mechanism (update the deployment stack) or ask its owner to add an exclusion.

5. ABAC condition or restricted delegation

Message: ... does not have authorization or an ABAC condition not fulfilled to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '...' or the scope is invalid. If access was recently granted, please refresh your credentials.
Causes: no role with roleAssignments/write (use Role Based Access Control Administrator rather than Owner), or a condition limits which roles or principals the caller may assign.
Known limitation: a role with a Microsoft.Storage data action combined with a condition using GUID comparison operators returns AuthorizationFailed; Microsoft says this combination is not currently supported.

6. Resource moved, or scope invalid

Moving a resource leaves its direct role assignments orphaned; re-create them after the move. Custom roles must have valid assignable scopes, can name only one management group, and cannot include DataActions when a management group is an assignable scope.

Look-alike errors

Error code	Microsoft's description	What to do
`AuthorizationFailed`	Account or service principal lacks access for the deployment scope; can also appear when a required resource provider is not registered	This guide; also check provider registration
`LinkedAuthorizationFailed`	Check the account belongs to the same tenant as the target resource group	Cross-tenant or cross-subscription references in a deployment
`RequestDisallowedByPolicy`	A policy prevents the action; the message names the `policyAssignment` and `policyDefinition`	`az policy assignment show`; make the resource compliant or request an exemption
`InvalidAuthenticationTokenTenant`	Get a token for the appropriate tenant	Sign in to the tenant that owns the subscription
`MissingSubscriptionRegistration` / `NoRegisteredProviderFound`	Register the subscription with the resource provider	Register the provider (needs its own permission)
`PrincipalNotFound`	Principal does not exist in the directory, often replication delay	Set `principalType` on the assignment
`RoleAssignmentUpdateNotPermitted`	Existing assignment name reused with different values	Use a deterministic `guid()` name per principal, role and scope
`Insufficient privileges to complete the operation`	Azure CLI cannot look up the assignee in Entra ID	Use `--assignee-object-id` instead of granting Directory Readers

A step-by-step triage procedure

Capture the error code, object ID, action, scope and correlation ID from the activity log or deployment output.
Classify: if the code is one of the look-alikes, follow that row instead.
Confirm identity and tenant: resolve the object ID to a named principal and check it is the intended one.
Check timing: if a role or group change was made recently, refresh the token and retry for up to 10 minutes (longer for management group data roles and managed identities).
Check access at the exact scope, then the Deny assignments tab, then any conditions on the matching assignment.
Decide plane: data operations need data roles; do not add Owner.
Apply the smallest fix in code, re-run, and revert if it does not resolve the error rather than adding a second role.
Record the cause and add a deployment check for it.

Decision guidance

Situation	Better choice	Avoid
Pipeline needs to create role assignments	Role Based Access Control Administrator with a condition limiting assignable roles	Owner or User Access Administrator
Engineer needs occasional elevated access	Eligible assignment through Privileged Identity Management	Permanent Owner
App reads blobs	Storage Blob Data Reader on the container	Contributor plus account keys
Many subscriptions need the same data role	Subscription-scope assignments in code	Management group scope if prompt revocation matters
Policy blocks a deployment	Comply, or time-bound exemption from the policy owner	Moving the subscription out of the management group

Small tenants can resolve most cases in the portal. Larger estates should give platform teams read access to role and deny assignments across management groups, manage assignments in code, and route policy and deny assignment issues to their owners rather than to whoever holds Owner.

Where identity fits

Most production AuthorizationFailed errors involve service principals and managed identities. The fix becomes a standing privilege of a non-human identity, so review it afterwards. See the Azure RBAC and Service Principals Guide, How to find over-privileged Azure managed identities and the Azure Managed Identities Security Guide. Sign-in failures before authorisation, such as AADSTS700213 in GitHub Actions, are covered in the GitHub Actions OIDC Errors Troubleshooting Guide.

Detection and measurement

Activity log: failed operations carry the status and correlation ID; send it to a Log Analytics workspace and query failures by caller and operation. See the Azure Activity Log and Diagnostic Settings Guide.
Role assignment writes: alert on Microsoft.Authorization/roleAssignments/write granting Owner, Contributor or User Access Administrator, especially to service principals and soon after a failed operation by the same principal.
Data plane: enable resource diagnostic logs (for example Storage) to see 403s that never reach the activity log.

Metrics:

Authorisation failures per principal per week, grouped by error code.
Owner or Contributor grants to non-human identities made in response to tickets.
Median time to resolve an authorisation ticket.
Share of role assignments created through infrastructure as code.
Number of principals using account keys where a data role exists.

Common failure patterns

Owner as the universal fix: it does not grant data access and creates a principal that can reassign roles. See How to Audit Azure Owner and User Access Administrator Assignments.
Switching to account keys: a data plane 403 is bypassed with Shared Key, replacing an auditable identity with a shared secret.
Not refreshing tokens: a correct new assignment is undone and redone because the caller kept an old token.
Granting at management group for data roles: access arrives hours later and revocation is just as slow.
Treating policy denials as RBAC: roles are added for a RequestDisallowedByPolicy error that names the policy outright.
Losing assignments on moves: resources moved between groups lose direct assignments, and the outage is "fixed" with a broad role at the subscription.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-3 Access Enforcement; AC-6 Least Privilege	Layered RBAC, deny and condition enforcement; narrow fixes
NIST SP 800-53 Rev. 5	AC-2 Account Management; CM-3 Configuration Change Control	Managing principals and reviewed role changes
NIST SP 800-53 Rev. 5	AU-12 Audit Record Generation	Activity and diagnostic logging of denials
NIST CSF 2.0	PR.AA-05	Access permissions defined, enforced and reviewed
CIS Controls v8.1	6.8 Define and Maintain Role-Based Access Control	Roles sized to job function
ISO/IEC 27001:2022 Annex A	5.15 Access control; 5.18 Access rights	Granting and reviewing access rights
MITRE ATT&CK	T1098.003 Additional Cloud Roles; T1078.004 Cloud Accounts	Over-granted roles are what attackers add or abuse

Practitioner checklist

Record object ID, action, scope and correlation ID from every failure.
Rule out look-alike codes such as RequestDisallowedByPolicy before touching RBAC.
Refresh tokens and allow propagation time before re-granting.
Check access, deny assignments and conditions at the exact scope.
Use data roles for data operations; never fall back to account keys.
Assign the narrowest role at the lowest scope, in code, with deterministic assignment names.
Use PIM eligibility for people and conditions on role-assigning roles.
Alert on high-privilege grants to service principals and review incident grants within a week.