Forbidden
Azure returns `Forbidden` (403) when the caller is authenticated but blocked by authorization, policy, or service-level access controls.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
What Does Forbidden Mean?
The request is blocked after identity is established, so operation flow stops until access rules at the target scope are corrected.
Common Causes
- -Caller lacks required permission for the exact action at resource, group, or subscription scope.
- -Deny assignment or policy enforcement overrides expected role allows.
- -Service-specific firewall/private endpoint/network ACL blocks the caller path.
- -Recent RBAC changes have not propagated to the control plane yet.
How to Fix Forbidden
- 1Capture denied action/scope or service-specific reason from the 403 response payload.
- 2Evaluate effective permissions and deny assignments at the target scope hierarchy.
- 3Verify network and endpoint access controls for services that enforce data-plane restrictions.
- 4Apply least-privilege remediation and retry after propagation window.
Step-by-Step Diagnosis for Forbidden
- 1Collect request correlation IDs, principal identity, and denied operation details from logs.
- 2Confirm caller tenant/subscription context matches intended target scope.
- 3Inspect RBAC assignments, deny assignments, and relevant policy effects for that scope.
- 4For service endpoints, validate firewall, private endpoint, and trusted-network conditions.
Authorization Graph and Scope Resolution
- -Trace effective role path from subscription to resource level (example: principal has Contributor on sibling resource group, not target group).
- -Audit deny precedence and policy outcomes (example: explicit deny assignment blocks `Microsoft.KeyVault/vaults/secrets/read` despite broad role).
Service-Level Access Control Checks
- -Inspect network ACL and private endpoint requirements for data-plane calls (example: storage account firewall denies public IP of deployment agent).
- -Verify token audience and service endpoint compatibility (example: management-plane token used against data-plane endpoint returns 403-style denial).
How to Verify the Fix
- -Replay the exact denied request and confirm 403 is resolved for the intended principal.
- -Validate audit logs show expected allow path at the corrected scope.
- -Test nearby high-risk actions to ensure least-privilege boundaries remain intact.
How to Prevent Recurrence
- -Treat access as code: version RBAC, deny assignments, and policy exceptions with peer review.
- -Run automated preflight permission tests for critical deployment and runtime identities.
- -Continuously monitor 403 trends by resource/provider to detect access drift early.
Pro Tip
- -map each production identity to an expected action matrix and alert when real denied actions drift from that baseline.
Decision Support
Compare Guide
401 Unauthorized vs 403 Forbidden: Auth vs Access Denied
Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Playbook
Authorization Denial Playbook (403 / AccessDenied / PERMISSION_DENIED)
Use this playbook to triage policy-based access denials after authentication succeeds, isolate the deny layer, and apply least-privilege remediation safely.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.