There should be more than one owner assigned to subscriptions

What does the recommendation "There should be more than one owner assigned to subscriptions" check?

Flags any subscription that has exactly one principal holding the built-in Owner role at the subscription scope. It counts direct Owner role assignments on the subscription itself, so a single human user, a lone service principal or one group with no members will all trip it. It does not look at Contributor, User Access Administrator or any custom role that happens to grant write or role-assignment rights, it does not count Owner assignments that are inherited from a parent management group, and it makes no judgement about whether that one owner uses multi-factor authentication or holds the role as an eligible Privileged Identity Management assignment rather than a standing one. The signal is purely about redundancy of the highest-privilege role, not about how that role is protected.

Why does "There should be more than one owner assigned to subscriptions" matter?

A subscription with a single owner is a single point of administrative failure. If that one account is disabled when the person leaves, locked out after too many sign-in failures, deleted during an identity clean-up, or simply unreachable during a major incident, then nobody can assign roles, accept a billing transfer, lift a resource lock or recover access, and you are reduced to raising a Microsoft support case just to regain control of your own subscription. The business consequence is a frozen subscription at the worst possible moment: production cannot be reconfigured, break-glass changes stall, audits flag an unrecoverable governance gap, and recovery can stretch into days while revenue-bearing workloads sit untouched. Adding a second owner gives you a recoverable path the instant the first is unavailable, while staying well inside the companion cap of three owners that exists to limit breach exposure from compromised privileged accounts.

How do I fix "There should be more than one owner assigned to subscriptions"?

1. Identify a second trusted principal, ideally a small break-glass group rather than another individual, then assign it the Owner role on the subscription: az role assignment create --assignee <objectId-or-upn> --role Owner --scope /subscriptions/<subscriptionId>.
2. In Bicep, declare the assignment with a Microsoft.Authorization/roleAssignments resource scoped to the subscription, setting roleDefinitionId to the Owner role (8e3af657-a8ff-443c-a75c-2fe8c4bcb635) and a deterministic name via guid(subscription().id, principalId).
3. Keep the total at two or three owners and enrol them in Privileged Identity Management as eligible, MFA-gated assignments so redundancy does not become a standing-access risk. This is an audit recommendation: Defender for Cloud reports the gap but never assigns an owner for you.

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