A maximum of 3 owners should be designated for subscriptions

What does the recommendation "A maximum of 3 owners should be designated for subscriptions" check?

Counts the principals holding the built-in Owner role at the subscription scope and flags any subscription with more than three. It looks only at direct Owner role assignments at subscription scope: it does not count Owner assignments inherited from a parent management group, nor Contributor, User Access Administrator or custom roles, even though those can also grant broad control. Both permanent and eligible (PIM) Owner assignments are included in the tally, and the count covers users, groups and service principals alike, so a single over-broad group assignment can trip the control on its own. The threshold of three is fixed by the recommendation and is not configurable from the finding itself.

Why does "A maximum of 3 owners should be designated for subscriptions" matter?

Owner is the most privileged role on a subscription: it can do anything Contributor can plus grant access to other principals through Microsoft.Authorization actions, so every additional Owner is another account that can hand out access, delete resources or disable controls. The more Owners you have, the larger the attack surface and the harder it is to tell a legitimate change from a compromised credential. A single phished or stale Owner account can quietly add backdoor access across the whole subscription, and broad Owner sprawl breaks separation of duties: when several people can all grant the same high privilege, no one approval gate is meaningful. It also slows incident response, because attribution of who changed what becomes guesswork exactly when speed matters most, and it weakens audit evidence for frameworks that expect least-privilege administration.

How do I fix "A maximum of 3 owners should be designated for subscriptions"?

1. Audit current Owners with `az role assignment list --scope /subscriptions/<id> --role Owner --include-inherited`, decide who genuinely needs to grant access, then remove the rest with `az role assignment delete`, downgrading day-to-day administrators to Contributor so they keep operational control without the ability to hand out roles.
2. For the Owners who remain, convert standing access to just-in-time eligibility with Microsoft Entra Privileged Identity Management, so the Owner role is activated on demand with approval, justification and an expiry rather than being held permanently, which both shrinks the live count and adds an audit trail for every activation.
3. Prevent regression by assigning Owner only to a small Entra security group, governing its membership through a recurring access review, and codifying the limit with an Azure Policy guardrail or alert that fires when a subscription's direct Owner assignments exceed three.

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