Guest accounts with owner permissions on Azure resources should be removed

What does the recommendation "Guest accounts with owner permissions on Azure resources should be removed" check?

Flags any Azure role assignment that grants the built-in Owner role to an account provisioned outside your Microsoft Entra tenant, that is, a guest or external identity whose home domain differs from your own. Defender for Cloud evaluates assignments at the subscription scope and resolves the assignee's user type, so it catches a B2B guest, a personal Microsoft account or a partner identity that has been made Owner. It does not flag member (internal) Owners, and it is not about Contributor or custom roles: only the Owner role on a guest principal triggers it. It also does not check whether the guest has actually signed in or used the access.

Why does "Guest accounts with owner permissions on Azure resources should be removed" matter?

Owner is the most powerful Azure role: it can read every resource, change configuration and, critically, grant further access to anyone, including the ability to assign more Owners. A guest account carrying Owner means someone outside your organisation can hand themselves or others standing administrative control of the subscription. Guest identities sit outside your normal joiner and leaver process, so they are rarely deprovisioned when a contractor or partner engagement ends, and they often escape the Conditional Access and MFA policies you enforce on your own staff. That combination, high privilege plus weak lifecycle, is exactly what attackers hunt for: a forgotten external Owner is a quiet, fully-privileged foothold that can survive long after anyone remembers granting it, and a compromised guest tenant becomes a direct path into your subscription with no further escalation required.

How do I fix "Guest accounts with owner permissions on Azure resources should be removed"?

1. Audit the assignments before touching anything: run 'az role assignment list --scope /subscriptions/<sub-id> --role Owner --include-inherited --output table' and cross-reference each assignee against your tenant to confirm which are genuinely external guests.
2. Remove the offending grant with 'az role assignment delete --assignee <guest-object-id> --role Owner --scope /subscriptions/<sub-id>', or in the portal under Subscription > Access control (IAM) > Role assignments. Where the external party still needs reduced access, reassign a least-privilege built-in or custom role instead of Owner.
3. Stop the problem recurring: for any guest that legitimately needs administrative access, grant it through Microsoft Entra Privileged Identity Management as an eligible (not active) assignment with MFA, approval and a time-boxed activation, rather than a permanent Owner role assignment.

# 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"