Blocked accounts with read and write permissions on Azure resources should be removed

What does the recommendation "Blocked accounts with read and write permissions on Azure resources should be removed" check?

Flags Microsoft Entra ID accounts that have been blocked from signing in (their account-enabled flag is set to false) but still hold read or write RBAC role assignments on a subscription, resource group or resource. Defender for Cloud cross-references the directory's sign-in state against live role assignments and surfaces any blocked principal that retains contributor-style or reader access. It looks only at human Entra ID user accounts with read and write roles: it does not cover accounts that hold the Owner role (a separate recommendation), service principals or managed identities, or accounts that are merely inactive but still permitted to sign in.

Why does "Blocked accounts with read and write permissions on Azure resources should be removed" matter?

A blocked account is one an administrator has deliberately taken out of service, usually a leaver or a compromised identity, yet leaving its role assignments in place means the access is dormant rather than gone. If the sign-in block is ever lifted, whether by mistake, by a helpdesk reinstating the wrong person, or by an attacker who re-enables the account through a stolen admin session, the old read and write permissions snap straight back into effect with no fresh approval. Blocked-but-permissioned accounts are a quiet path to data exfiltration and resource tampering precisely because nobody is watching them. Removing the role assignments closes that gap and keeps your access review honest, so the list of who can touch a resource matches the list of who is actually allowed to.

How do I fix "Blocked accounts with read and write permissions on Azure resources should be removed"?

1. Confirm the account is genuinely retired in Microsoft Entra ID (look for accountEnabled set to false), then list its current access with 'az role assignment list --assignee <user-object-id> --all' to see every scope where read or write roles are held.
2. Remove each role assignment at the scope where it was granted, for example 'az role assignment delete --assignee <user-object-id> --role Contributor --scope /subscriptions/<sub-id>'. Inherited assignments must be deleted at their originating scope, not the child resource.
3. Once the offboarding is complete, delete or hard-disable the stale account so it cannot be reactivated, and add an access-review or automation runbook that strips role assignments from any newly blocked account so this is enforced going forward rather than caught after the fact.

# Remove the highest-impact stale grants first: external/guest identities holding Owner.
SCOPE="/subscriptions/00000000-0000-0000-0000-000000000000"
az role assignment list --scope "$SCOPE" --all --include-inherited \
    --query "[?contains(principalName, '#EXT#') && roleDefinitionName=='Owner'].principalId" -o tsv |
while read -r oid; do
  az role assignment delete --assignee-object-id "$oid" --scope "$SCOPE"
  echo "$oid: external Owner assignment removed"
done

# Find blocked/deprecated (disabled) accounts that still hold a role on this scope.
for oid in $(az role assignment list --scope "$SCOPE" --all \
    --query "[?principalType=='User'].principalId" -o tsv | sort -u); do
  enabled=$(az ad user show --id "$oid" --query accountEnabled -o tsv 2>/dev/null)
  if [ "$enabled" = "false" ]; then
    echo "$oid is disabled in Entra but still holds a role - remove its assignment"
  fi
done

# Keep it shut: assign the built-in deprecated-owner policy by its exact display name
# (look the id up at runtime - never hardcode a policy GUID).
pid=$(az policy definition list \
  --query "[?displayName=='Deprecated accounts with owner permissions should be removed from your subscription'].name" -o tsv)
az policy assignment create \
  --name audit-deprecated-owners \
  --policy "$pid" \
  --scope "$SCOPE"