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

Microsoft Defender for Cloud · Subscription / RBAC

External accounts with write permissions should be removed from subscriptions

Written and reviewed by Emnode · Last reviewed

What does the recommendation "External accounts with write permissions should be removed from subscriptions" check?

Flags any subscription that still has a role assignment granting write-level access (Contributor or another role with write actions) to an external account, meaning a sign-in whose domain does not match your Entra ID tenant, typically a guest or a leftover account from a partner, contractor or acquired organisation. It looks only at write-capable roles on the subscription: it does not cover Owner assignments (a separate, higher-severity recommendation), read-only roles, service principals, or management-group assignments that cascade down. Assignments to internal tenant members are never flagged, however broad their access.

Why does "External accounts with write permissions should be removed from subscriptions" matter?

An external write account is standing access you do not centrally govern: it lives in someone else's directory, so you cannot enforce your own MFA, conditional access or joiner-mover-leaver process against it. A contractor who has rolled off, or a partner whose own tenant is breached, becomes an unmonitored path straight into your subscription with permission to deploy resources, change configuration and move laterally. Because the account is foreign to your tenant, its activity is easy to overlook in access reviews and its sudden compromise is hard to attribute back to a real owner. Write access is enough to do real damage: a Contributor can spin up costly resources, alter networking, disable logging or stage data for exfiltration, all without ever holding Owner. The business consequence is a privileged foothold that survives staff and supplier changes and that your security team has no clean way to revoke in a hurry. Removing external write access shrinks the privileged attack surface to identities you can actually monitor, attribute and revoke on your own terms.

How do I fix "External accounts with write permissions should be removed from subscriptions"?

  1. List the offending assignments and confirm each holder is genuinely external: 'az role assignment list --subscription <sub-id> --include-inherited --query "[?principalType=='User']"' and cross-check the user's domain against your tenant before acting.
  2. Remove each unneeded external write assignment with 'az role assignment delete --assignee <object-id-or-upn> --role Contributor --scope /subscriptions/<sub-id>', or for access that must continue, replace the standing grant with a time-bound, approval-gated assignment through Microsoft Entra Privileged Identity Management.
  3. Prevent recurrence by assigning the built-in policy that audits this state, looked up by display name rather than a hardcoded GUID: 'pid=$(az policy definition list --query "[?displayName=='Guest accounts with write permissions on Azure resources should be removed'].name" -o tsv); az policy assignment create --name no-ext-write --policy "$pid" --scope /subscriptions/<sub-id>'.

Remediation script · bash

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

Full walkthrough (console steps, edge cases and verification) in the lesson Remove stale and external Azure identities.

Is "External accounts with write permissions should be removed from subscriptions" a false positive?

A managed service provider or co-managing partner that runs your platform under a formal contract will legitimately hold write access through guest accounts, and this control still flags them. That is acceptable if the access is deliberate, scoped and reviewed: govern it through Entra B2B with PIM-eligible (not permanent) assignments and a recurring access review, then treat the recommendation as an exemption you reconfirm rather than a finding to clear.