The Owners Who Were Not People

The problem

Owner looks like just another Azure RBAC role. At a subscription it is root for everything underneath it, including the right to grant roles to anyone else. User Access Administrator cannot change those resources directly, but it can assign itself Owner, so it is Owner with one extra step.

The tenant had standing assignments of both. Nobody had a complete list. A single-subscription CLI command had been treated as the inventory.

What made it hard

• PIM is the right shape for people and the wrong shape for pipelines. You cannot make a service principal or managed identity eligible for an Azure role. They cannot complete an activation flow.
• Root depends on scope. Owner on a resource group is root for that group. Owner at the tenant root management group is root for all of Azure. Saying "Owner means root" without the scope misses the assignment that actually matters.
• A naive tenant-root query looks clean and is wrong. Listing assignments at scope "/" only works if elevate access is already on. For everyone else it errors or returns nothing, which looks like no root assignments.

What I did

Inventoried every Enabled subscription in the tenant. I looped az account list filtered to this tenant and Enabled subscriptions, then listed Owner and User Access Administrator with --all and --include-inherited. That surfaces assignments inherited from management groups without querying tenant root.

Left MS-PIM alone. Microsoft's MS-PIM service principal holds User Access Administrator so Privileged Identity Management can manage Azure resource roles. Deleting that assignment would have broken PIM. Confirm the display name before you treat a service principal as a finding.

Moved humans to just-in-time. Standing Owner for people became PIM-eligible assignments with approval, an audit trail, and phishing-resistant MFA.

Treated workload identities as a different control. Pipeline service principals moved off client secrets onto workload identity federation, with a narrower role than Owner. Vendor Lighthouse grants were scoped and time-boxed instead of standing.

Turned off leftover elevate access. A Global Administrator had flipped "Access management for Azure resources" to Yes during a tenant cleanup and never flipped it back. That setting is Owner for the whole tenant for as long as it stays on.

What we found

• Four standing Owners on a single subscription: a platform engineer from an outage two years ago, a vendor deployment identity, a pipeline service principal with a secret in a variable group, and a Global Administrator with elevate access still on.
• Three of the four were not people. PIM could cover one of them. The other three needed a different control.
• Lighthouse grants from a prior managed-service engagement still had Owner at subscription scope after the engagement ended.

Results

• Standing human Owner went to zero on production subscriptions. Activations now go through PIM.
• Pipeline identities dropped from Owner to a scoped deployment role and authenticated with federation instead of a stored secret.
• The elevate-access setting was turned off, and sign-in to the break-glass path is monitored.
• The inventory script became a recurring control, not a one-off cleanup. New standing Owner in an Enabled subscription shows up the next run.

What I'd do differently

Start with the identities PIM cannot cover. The human Owner was the easy conversation. The pipeline and the vendor grant were the ones that still had standing root after the first cleanup pass.

Document MS-PIM before the first removal. Someone will flag that User Access Administrator service principal. If you have not already written down why it exists, it gets deleted in the same sweep as the real findings.

Related reading

• Owner Means Root: the full write-up on standing Owner, PIM gaps, and the identities PIM cannot cover.
• The Deny Is the Perimeter: the AWS version of a ceiling that still holds when a standing grant appears.