What it is
A Privileged Identity Management (PIM) eligible assignment on a privileged role, Owner, User Access Administrator, or Contributor, that the principal hasn't activated in months. Eligibility is rightly considered safer than standing access, but it is not nothing: the principal can self-activate that role at the scope whenever it likes. An eligibility nobody uses is standing potential access that has outlived its need, and it's invisible to any review that only enumerates active role assignments.
Why it happens
PIM's own framing works against cleanup here. Because eligibility "isn't standing access", it gets handed out more generously than an active grant ever would, and it feels harmless to leave in place. There's no bill, no failing deployment, no console warning; a dormant eligibility produces no signal at all.
The tooling gap seals it. Eligible assignments live in a separate API surface from active ones: az role assignment list doesn't return them, and most home-grown RBAC audits and access-review habits enumerate active assignments only. So the person who changed teams a year ago still can become Owner of the old subscription, and every list anyone actually looks at says they have no access there.
An eligibility that's genuinely used is PIM working as designed. One that sits unactivated for months on a critical role is the tell: the need ended, the grant didn't.
What it costs / blast radius
The direct cost is nothing; the harm is a dormant escalation path plus audit blindness. If the principal's credentials are compromised, the attacker doesn't get a low-privilege account, they get an account that can promote itself to Owner or Contributor at that scope (approval and MFA-on-activation apply only if the role's PIM settings require them). (Azure behavior; authored assessment.) Meanwhile the environment's effective privilege picture is quietly wrong: everyone who could hold a role is part of its real blast radius, whether or not this month's access review saw them.
See it
# Eligibility schedules live in their own API surface; ordinary
# 'az role assignment list' output will never show these.
az rest --method GET --url \
"https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/roleEligibilitySchedules?api-version=2020-10-01" \
--query "value[].{principal: properties.expandedProperties.principal.displayName, role: properties.expandedProperties.roleDefinition.displayName, scope: properties.scope, since: properties.startDateTime}" \
--output table
# Cross-check activity: has this principal done anything at this scope
# lately? Zero activity over months = the eligibility was never needed.# Removal is itself a roleEligibilityScheduleRequest with AdminRemove.
az rest --method PUT --url \
"https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/$(uuidgen)?api-version=2020-10-01" \
--body '{
"properties": {
"principalId": "<principalId>",
"roleDefinitionId": "/subscriptions/<subscriptionId>/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635",
"requestType": "AdminRemove",
"justification": "Eligibility unused; removing dormant escalation path"
}
}'
# If the person still needs occasional access, re-grant the eligibility
# with an expiry so it has to be re-justified instead of living forever.How StratoLens helps
StratoLens flags PIM eligibilities on critical roles that sit dormant, automatically and continuously, across every subscription, inside your own tenant. The "could become Owner but never has" list stops being a query nobody runs and becomes a finding someone acts on.