The same role granted separately across 5+ subscriptions signals blanket over-provisioning, not intent

Why it happens

It is simply easier to grant a role on each subscription as it appears than to design a management-group hierarchy up front and place the grant once. Onboarding scripts, landing-zone templates, and "just give them access everywhere" tickets scatter identical assignments across the estate.

Azure never objects, because every one of those assignments is individually valid. There is no built-in view that says "this identity can write to twelve subscriptions," so the sprawl compounds quietly and the true reach of a principal becomes something nobody can see at a glance. Deliberate, scoped grants and accidental blanket over-provisioning look exactly the same in the assignment list.

What it costs / blast radius

Role assignments are free, so there is no dollar cost. (Azure behavior; authored assessment.) The harm is blast radius and visibility: one compromised principal now reaches every subscription it was blanket-granted, and because the access is spread across many independent assignments, no single place tells you how far that identity can actually go. You discover the real reach during an incident, which is the worst possible time.

See it

// A separate, standing Contributor assignment per subscription.
targetScope = 'managementGroup'   // needed to deploy subscription-scoped modules
param subscriptionIds array   // e.g. 12 subscription IDs
param principalId string

module grant 'contributor-grant.bicep' = [for subId in subscriptionIds: {
  name: 'grant-${subId}'
  scope: subscription(subId)
  params: { principalId: principalId }
}]
// 12 subscriptions => 12 identical grants, and no one view of the total reach.

targetScope = 'managementGroup'
param principalId string

resource contributor 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(managementGroup().id, principalId, 'Contributor')
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'b24988ac-6180-42a0-ab88-20f7382dd24c')
    principalId: principalId
    principalType: 'Group'   // assign to a group; manage reach by membership, in one place
  }
}