Deprecated accounts should be removed from subscriptions

What does the recommendation "Deprecated accounts should be removed from subscriptions" check?

Flags Microsoft Entra ID user accounts that are blocked from signing in but still hold a role assignment on the subscription. Defender for Cloud treats a 'block sign-in' (accountEnabled=false) account that retains access as deprecated: someone left the organisation or finished a pilot, yet their permissions were never revoked. It only inspects subscription-scoped role assignments held by disabled human users. It does not cover active accounts, service principals, managed identities, guest accounts that are still enabled, or accounts whose access was granted through a group rather than directly.

Why does "Deprecated accounts should be removed from subscriptions" matter?

A disabled account that keeps its role assignment is dormant standing access waiting to be revived. If the account is re-enabled, whether by an admin restoring a leaver in error or by an attacker who has compromised the directory, it regains exactly the permissions it held before, with no fresh approval and little attention paid to it. Because nobody is using these accounts day to day, their reactivation rarely triggers the scrutiny a brand new grant would. Removing the access closes a quiet path to privilege that bypasses your joiners and leavers process entirely, and it keeps your access reviews honest by ensuring the people who can touch a subscription are people who actually still work there.

How do I fix "Deprecated accounts should be removed from subscriptions"?

1. Confirm the account is genuinely deprecated: in Microsoft Entra ID check that 'Block sign in' is set to Yes and that the user is a real leaver, not a temporarily suspended colleague. If the person has left, the cleanest fix is to delete the account in Entra ID, which removes both the identity and its assignments.
2. If the account must survive for audit or licence reasons, leave the identity in place but strip its subscription access: remove the role assignment with 'az role assignment delete --assignee <objectId> --scope /subscriptions/<subId>', or in the portal under Subscription > Access control (IAM) > Role assignments.
3. Stop the backlog rebuilding: drive offboarding through an Entra ID access review or a leaver workflow that revokes Azure RBAC on exit, and prefer group-based assignments so removing someone from a group withdraws their access in one step.

# Find the highest-risk privileged assignments first: external accounts and blocked leavers holding Owner.
SUB="00000000-0000-0000-0000-000000000000"

# List Owners, with type and object id, so external and group principals are obvious.
az role assignment list \
  --scope "/subscriptions/$SUB" \
  --role Owner \
  --query "[].{who:principalName, type:principalType, id:principalId}" -o table

# Remove an external partner's Owner assignment (work finished). Keep at least one Owner you control.
az role assignment delete \
  --assignee "[email protected]" \
  --role Owner \
  --scope "/subscriptions/$SUB"

# Remove a deprecated (blocked) account's role assignment by object id.
# Blocking the Entra sign-in does NOT remove the assignment; delete it explicitly.
az role assignment delete \
  --assignee-object-id "<blocked-user-object-id>" \
  --scope "/subscriptions/$SUB"

# Consolidate the remaining legitimate Owners behind one Entra group, then make it eligible
# (just-in-time) via Privileged Identity Management so nobody holds standing Owner.