Skip to main content
emnode
Compliance High severity MCSB PA-2

Microsoft Defender for Cloud · Subscription / RBAC

Privileged roles should not have permanent access at the subscription and resource group level

Written and reviewed by Emnode · Last reviewed

What does the recommendation "Privileged roles should not have permanent access at the subscription and resource group level" check?

Flags any user who holds a privileged Azure RBAC role (Owner, Contributor, User Access Administrator or Role Based Access Control Administrator) as an active permanent assignment at subscription or resource group scope, meaning the rights are always live rather than activated just-in-time through Privileged Identity Management. It looks only at standing access on the Azure resource control plane. It does not evaluate Microsoft Entra directory roles such as Global Administrator, it does not flag eligible or time-bound assignments, and it does not inspect role assignments made at individual resource scope.

Why does "Privileged roles should not have permanent access at the subscription and resource group level" matter?

A permanent Owner or User Access Administrator assignment is a credential that never sleeps: if that account is phished or its token is stolen, the attacker inherits full control of the subscription the instant they sign in, with no activation step, approval or time limit standing in the way. Standing privilege also widens every audit: each permanent admin is one more account that can silently change RBAC, delete resources or exfiltrate data at any hour. Converting these to eligible just-in-time access means the dangerous permissions exist for minutes during a justified task, not permanently, shrinking the window an attacker can exploit from months to almost nothing.

How do I fix "Privileged roles should not have permanent access at the subscription and resource group level"?

  1. Inventory the standing assignments by listing everything that is not Active permanent at the scope, for example 'az role assignment list --scope /subscriptions/<subscriptionId> --include-inherited' to see current RBAC, then in the Access control (IAM) blade group the Role assignments tab by State to find Active permanent rows for privileged roles.
  2. For each human who genuinely needs the role, recreate it as an eligible assignment in Privileged Identity Management: in Access control (IAM) choose Add eligible assignment, or submit a roleEligibilityScheduleRequest (PowerShell 'New-AzRoleEligibilityScheduleRequest -Scope <scope> -PrincipalId <id> -RoleDefinitionId <id> -RequestType AdminAssign'), then remove the original permanent assignment with 'az role assignment delete'.
  3. Tighten the PIM role settings so the new model holds: require approval, MFA and justification on activation, cap the maximum activation duration, and turn off the option to create permanent active assignments for these roles via 'Configure Azure resource role settings in PIM' so nobody can reintroduce standing access.

Remediation script · bash

# 1. Revoke a stale or inactive privileged assignment (zero Azure cost).
# A leftover service principal cannot use just-in-time access, so it loses the role outright.
SUB="00000000-0000-0000-0000-000000000000"
az role assignment delete \
  --assignee "<service-principal-object-id>" \
  --role "Owner" \
  --scope "/subscriptions/$SUB"

# 2. Convert a human administrator's PERMANENT Owner to a PIM ELIGIBLE assignment.
#    Eligible assignments are made via the ARM authorization API (no 'az role assignment'
#    flag exists for this). 'az rest' calls it directly, so this block runs as-is.
PRINCIPAL="<user-object-id>"
# Owner role definition ID is the same well-known ID in every tenant:
ROLE_DEF="/subscriptions/$SUB/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635"
REQ_NAME=$(cat /proc/sys/kernel/random/uuid)

az rest --method put \
  --url "https://management.azure.com/subscriptions/$SUB/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/$REQ_NAME?api-version=2020-10-01" \
  --body "{\"properties\":{\"principalId\":\"$PRINCIPAL\",\"roleDefinitionId\":\"$ROLE_DEF\",\"requestType\":\"AdminAssign\",\"scheduleInfo\":{\"startDateTime\":null,\"expiration\":{\"type\":\"NoExpiration\"}},\"justification\":\"Replace standing Owner with just-in-time eligibility (MCSB PA-2)\"}}"

# 3. Only AFTER eligibility is confirmed, remove the old PERMANENT (active) assignment
#    so the administrator is never locked out:
az role assignment delete \
  --assignee "$PRINCIPAL" \
  --role "Owner" \
  --scope "/subscriptions/$SUB"

Full walkthrough (console steps, edge cases and verification) in the lesson Keep Azure privileged access clean.

Is "Privileged roles should not have permanent access at the subscription and resource group level" a false positive?

A dedicated break-glass account kept for emergency recovery, when PIM itself is unreachable, is correctly excluded from just-in-time activation and will keep flagging. Leave one or two such accounts as permanent, exclude them from this recommendation by exemption, and compensate with tight monitoring and alerting on every sign-in rather than removing their standing access.