Azure RBAC and Service Principals Guide: Role Assignments

Role assignments, service principal credentials and managed identities decide how far an attacker can go once inside Azure, usually without any exploit. A Contributor who can run code on a virtual machine inherits its managed identity, an Application Administrator can add a secret to a privileged service principal, and a delegate with User Access Administrator can make anyone Owner. This guide goes deeper than the platform overview: how Azure role-based access control (Azure RBAC) evaluates access, which built-in roles are effectively privileged, constraining role assignment, Key Vault permission models, service principal risk and managed identity abuse. For the wider picture see the Microsoft Azure Security Guide. It is written for Azure administrators, cloud security engineers and identity teams.

Key takeaways

• Roles that can write role assignments are the keys to the estate. Owner, User Access Administrator and Role Based Access Control Administrator can grant any role within their scope; constrain them with conditions and Privileged Identity Management (PIM).
• "Can run code here" means "can be this identity". Anyone able to execute code on a resource can use every managed identity attached to it, so Virtual Machine Contributor and similar roles inherit that identity's permissions.
• Application credentials are a persistence layer. App owners, Application Administrators and Cloud Application Administrators can add secrets or certificates to a service principal and act as it, which ATT&CK tracks as T1098.001.
• Move Key Vault to Azure RBAC. Under the legacy access policy model, any role with Microsoft.KeyVault/vaults/write can grant itself access to secrets.
• Review machines, not just people. Orphaned role assignments, unused service principals and high-privilege Microsoft Graph application permissions accumulate unless access reviews include service principals.

How Azure RBAC decides access

Microsoft defines Azure RBAC as "an authorization system built on Azure Resource Manager that provides fine-grained access management to Azure resources". A role assignment attaches a role definition to a security principal (user, group, service principal or managed identity) at a scope. Access is granted by creating an assignment and revoked by removing it.

• Role definition: Actions and NotActions (management plane), DataActions and NotDataActions (data plane), and AssignableScopes. NotActions is a subtraction, not a deny.
• Additive model: effective permissions are the sum of all assignments, direct, through groups, and inherited from parent scopes.
• Evaluation order: Azure Resource Manager collects role assignments and deny assignments; if a deny assignment applies, access is blocked; otherwise it checks whether a role grants the action at that scope, then evaluates any role assignment conditions.

Microsoft's best practices: avoid broad roles at broad scopes, keep "a maximum of 3 subscription owners", assign roles to groups, reference roles by ID in automation, and avoid wildcards in custom roles because future actions would be granted automatically.

Built-in roles that are effectively privileged

The built-in roles reference lists Owner, Contributor, Role Based Access Control Administrator and User Access Administrator in its Privileged section. Several other roles are privileged in practice because of what they let a principal become.

Custom roles and role definitions

• Write narrow Azure custom roles: list exact Actions and DataActions, set AssignableScopes to the subscriptions or resource groups that need the role, and keep definitions in code with review.
• Watch for hidden power: actions such as Microsoft.Authorization/roleAssignments/write, */listKeys/action, Microsoft.Compute/virtualMachines/runCommand/action, extension writes and Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action make a custom role privileged regardless of its name.

Constraining role assignment: conditions, ABAC and deny assignments

Microsoft lists three problems with delegating through Owner or User Access Administrator: the delegate "has unrestricted access at the role assignment scope", "can assign any role to any user within their scope, including themselves", and can create further role-granting administrators.

• Delegate with conditions: Role Based Access Control Administrator "has fewer permissions than User Access Administrator" and was designed for delegation. Add a condition so the delegate can only assign named roles (for example Backup Contributor and Backup Reader), only to user or group principal types, or only to specific groups, with separate rules for adding and removing assignments. A condition that blocks Owner, User Access Administrator and Role Based Access Control Administrator is the minimum.
• Azure ABAC for data: a role assignment condition "filters down permissions" using resource, request, environment and principal attributes. Conditions currently apply to Blob and Queue storage data actions, for example read access only to blobs tagged Project=Cascade. They cannot explicitly deny access.
• Azure deny assignments: they block actions "even if a role assignment grants them access" and are evaluated first, but "You can't directly create your own deny assignments". Azure creates them, for example for a deployment stack with deny settings, protecting stack resources from outside changes. Customer-managed deny assignments are in private preview.
• Privileged Identity Management: make Owner, User Access Administrator and Role Based Access Control Administrator eligible, time-bound and approval-gated. ATT&CK's mitigation for T1098.003 Additional Cloud Roles recommends PIM roles that require two or more approvals.
• Guard the root: a Global Administrator can elevate to User Access Administrator at root scope (Microsoft.Authorization/elevateAccess/action). The Storm-0501 hybrid cloud attacks used that path and Owner assignments over victims' subscriptions. Alert on every elevation.

Azure RBAC for Key Vault versus access policies

Microsoft calls the access policy model "a legacy authorization system" and states that "Starting with API version 2026-02-01, Azure RBAC is also the default access control model for new key vaults". The core reason is separation of duties.

The Key Vault documentation warns that under access policies, Contributor-level users "can grant themselves data plane access by configuring a Key Vault access policy", the behaviour behind the Azure Key Vault Contributor escalation. Migrate by mapping each access policy to a role (Secret Management maps to Key Vault Secrets Officer; most applications only need Key Vault Secrets User), assigning roles, then switching the vault's permission model. Some service templates (Azure Storage, Azure Backup) need custom roles. Use Azure Policy to audit vaults still on access policies.

App registrations, enterprise applications and service principals

An application object lives in its home tenant and is "a template or blueprint" for service principals; the service principal is the local instance in each tenant, listed under Enterprise applications. A multitenant app gets a service principal in every tenant that consents to it. Managed identities are also service principals, but without an application object. For fundamentals see the Cloud Workload Identity Guide; this section covers the abuse angle.

Who can act as a service principal

• Application owners: owners of an app registration (formerly an Azure Active Directory app registration) or service principal can manage its credentials, so an ordinary user owner is a path to every permission the app holds.
• Application Administrator and Cloud Application Administrator: both are marked Privileged in Entra ID and "can create and manage all aspects of app registrations and enterprise apps" (Cloud Application Administrator excludes App Proxy). They can add credentials to an application and act with its permissions, and ATT&CK gives exactly this example under T1098.001: "an adversary with the Application Administrator role can add a new set of credentials to their application's service principal." Scope these roles to specific apps where possible and make them PIM eligible.
• Anyone holding a credential: service principal secrets in scripts, pipeline variables and configuration files are the most common leak. Microsoft recommends service principal certificates because "Unlike client secrets, client certificates can't be embedded in code, accidentally", and federated credentials remove the secret entirely.

Microsoft Graph application permissions and app role assignments

• Application permissions are tenant-wide: as app roles they work without a signed-in user, and "The application can access any data that the permission is associated with". Consent creates an appRoleAssignment object on the service principal.
• Consent is restricted: "Only Privileged Role Administrator and Global Administrator can consent to application permissions." Keep it that way, and restrict user consent to verified publishers and low-risk delegated permissions.
• Know the dangerous permissions: application permissions that write to the directory (User.ReadWrite.All can update users holding privileged admin roles), assign roles or read all mail make a privileged service principal, which is Tier 0. Prefer delegated permissions or resource-specific consent.

Malicious app registrations and service principal takeover

Attackers holding an Application Administrator, app owner or consenting account can register a malicious app, add credentials to a trusted one, or grant new permissions. The Storm-1283 OAuth apps abuse used hijacked app identities to run cryptomining VMs, and the Microsoft Midnight Blizzard breach moved from a test tenant OAuth application to corporate mailboxes. See the SaaS and OAuth App Governance Guide.

Service principal hygiene

• Ownership: every service principal has at least two accountable owners recorded outside the app object, and no user owners on privileged apps.
• Credentials: no secrets on privileged service principals; certificates with short validity or federated credentials instead; secrets, where unavoidable, in Key Vault with expiry.
• Scope: Microsoft notes that Contributor is a common default for automation and says to apply the least possible permissions instead.
• Conditional Access for workload identities: block service principal sign-ins from untrusted locations, as Microsoft recommends.
• Retirement: remove credentials and assignments, disable, then delete. See the Service Account Security Guide.

Managed identity abuse paths

Managed identities remove secrets, but Microsoft's own guidance is blunt: when a resource has a managed identity, "if a user has access to install or execute code on this resource, then the user has access to all the identities assigned/associated to the Azure resource". The same applies to anyone who can assign the identity elsewhere.

• System assigned managed identity or user-assigned: Microsoft recommends system-assigned for audit logging and permissions lifecycle (the identity dies with the resource) and user-assigned for ephemeral compute, replicated resources and pre-provisioned access. A shared user-assigned identity is convenient but widens blast radius: compromising any one resource yields it.
• Clean up: "Role assignments aren't automatically deleted when either system-assigned or user-assigned managed identities are deleted." Remove them, or they remain as orphaned assignments.
• Revoke when compromised: user-assigned identities support revokeTokens/action; use it with removing role assignments. See the Cloud Incident Response Guide.

Implementation roadmap

1. Inventory assignments: export role assignments at every scope and list principals holding Owner, User Access Administrator, Role Based Access Control Administrator or Contributor, by principal type.
2. Fix the top of the tree: reduce subscription Owners to three or fewer, remove direct user assignments at management group scope, and move remaining privileged human roles to PIM eligible.
3. Replace User Access Administrator: assign Role Based Access Control Administrator with conditions to delegates; test the condition with a pilot delegate attempting a blocked role, then remove the old assignment. Rollback is re-adding the original assignment.
4. Right-size workload identities: add job-function roles at narrow scope, watch Activity Log authorisation failures for a week, then remove subscription Contributor.
5. Migrate Key Vault: map access policies to roles in a test vault, switch the permission model, then roll out per vault; switching back to access policies is the rollback.
6. Clean up applications: remove unused service principals, user owners and secrets on privileged apps, and unneeded Graph application permissions.
7. Turn on detection and reviews: alerts on the operations below, and recurring access reviews for privileged Azure roles that include service principals.

Decision guidance

• Built-in or custom role: use built-in job-function roles at narrow scope first; write a custom role only when the gap is real, and keep it in code with an owner.
• Secret, certificate, federation or managed identity: managed identity for workloads in Azure; federated credentials for CI/CD and workloads in other clouds or Kubernetes; certificates for anything else; secrets only for legacy cases, short-lived and vaulted.
• Delegation: User Access Administrator only for break-glass; conditioned Role Based Access Control Administrator for everyone else.
• Small or large: a small tenant needs one platform group with PIM-eligible Owner, application teams with Contributor at resource group scope, managed identities and quarterly reviews. Large estates add group-only assignments, conditional delegation per landing zone, custom roles as code, deployment stacks with deny settings and a Tier 0 list of privileged service principals. See the Cloud PAM and CIEM Guide.

Detection, access review and measurement

Azure RBAC access review: PIM access reviews for Azure resource roles run weekly, monthly, quarterly, semi-annually or annually, can auto-apply denials, and can include the Service Principals scope "to review the machine accounts with direct access". Reviewing service principals needs Microsoft Entra Workload ID Premium in addition to Entra ID P2 or ID Governance. Denying a user assigned through a group does not remove them from the group, so fix group membership separately. See the Access Reviews Guide.

Metrics:

• Subscriptions with more than three Owners (target: zero).
• Permanent (non-PIM) assignments of Owner, User Access Administrator and Role Based Access Control Administrator.
• Service principals and managed identities with Owner or Contributor at subscription scope or above.
• Privileged service principals with client secrets, and secrets past 90 days.
• Key vaults still on access policies, orphaned role assignments and access review completion rate.

Common failure patterns

• Contributor treated as safe: it can run code on compute, read storage keys and grant itself secrets on access policy vaults.
• User Access Administrator as the delegation tool: a team lead who needed to add readers can make an attacker Owner.
• Subscription-wide managed identities: a VM identity with Contributor on the subscription turns any web shell into full subscription control.
• User-owned privileged apps: a phished developer who owns an app with directory write permissions hands over the app.
• Secrets that never expire: service principal secrets outlive the people and projects that created them.
• Reviews that skip machines: quarterly reviews of human assignments while service principals and orphaned assignments are never examined.

Framework mapping

In NIST CSF 2.0 this sits mainly under PR.AA-05 (least privilege and separation of duties) and DE.CM-03 (personnel activity and technology usage monitored).

Practitioner checklist

• Keep three or fewer Owners per subscription and make all Owner, User Access Administrator and Role Based Access Control Administrator assignments PIM eligible.
• Replace User Access Administrator delegation with Role Based Access Control Administrator constrained by conditions that block privileged roles.
• Remove Contributor and Owner at subscription scope from service principals and managed identities; use job-function roles at resource group or resource scope.
• Restrict Virtual Machine Contributor, Run Command and Managed Identity Operator on resources that carry powerful identities.
• Migrate every key vault to Azure RBAC and audit the rest with Azure Policy.
• Remove user owners and client secrets from privileged service principals; use certificates, federated credentials or managed identities.
• Inventory Microsoft Graph application permissions and remove directory-write and mail-wide permissions that are not justified.
• Alert on role assignment writes, elevate access, federated credential writes and new service principal credentials.
• Run recurring PIM access reviews of privileged Azure roles that include service principals, and delete orphaned assignments.

Standards and references

• Microsoft Learn: What is Azure role-based access control (Azure RBAC)?
• Microsoft Learn: Best practices for Azure RBAC
• Microsoft Learn: Delegate Azure access management to others
• Microsoft Learn: Azure RBAC vs. access policies for Key Vault
• Microsoft Learn: Application and service principal objects in Microsoft Entra ID
• Microsoft Learn: Overview of Microsoft Graph permissions
• Microsoft Learn: Managed identity best practice recommendations
• MITRE ATT&CK: T1098.001 Additional Cloud Credentials

Related NHI Mgmt Group resources: Microsoft Azure Security Guide · Cloud Workload Identity Guide · Active Directory and Entra ID Hardening Guide · SaaS and OAuth App Governance Guide · JIT Access Guide