October opens with identity depth, starting where the blast radius is biggest: privileged access. The Conditional Access post established the principle that standing privilege is the enemy; Privileged Identity Management is the machinery that eliminates it, and today is the full engineering treatment.

The Model: Eligible, Active, Time Bound

PIM manages three assignment dimensions for Entra roles and Azure RBAC roles alike. Eligibility means you may activate the role; activation means you hold it now, for a bounded duration; and both eligibility and activation carry expiry. The target state for a mature tenant: zero permanent active assignments on privileged roles, eligibility granted to groups rather than individuals, activation windows of one to eight hours depending on role sensitivity, and activation requirements scaled to risk, MFA for everything, justification always, ticket number for production touching roles, and approval by a second human for Global Administrator, Privileged Role Administrator, and the Azure Owner role on production subscriptions.

resource "azurerm_role_management_policy" "sub_owner" {
  scope    = data.azurerm_subscription.prod.id
  role_definition_id = data.azurerm_role_definition.owner.id

  active_assignment_rules {
    expire_after = "P15D"
  }

  eligible_assignment_rules {
    expiration_required = true
    expire_after        = "P180D"
  }

  activation_rules {
    maximum_duration = "PT4H"
    require_multifactor_authentication = true
    require_justification              = true
    require_approval                   = true
    approval_stage {
      primary_approver {
        object_id = azuread_group.pim_approvers.object_id
        type      = "Group"
      }
    }
  }
}

resource "azurerm_pim_eligible_role_assignment" "platform_owner" {
  scope              = data.azurerm_subscription.prod.id
  role_definition_id = data.azurerm_role_definition.owner.id
  principal_id       = azuread_group.platform_admins.object_id

  schedule {
    expiration {
      duration_days = 180
    }
  }
}

PIM for Groups: The Scaling Pattern

Assigning PIM per role per person collapses under its own administration. PIM for groups inverts it: a group carries a bundle of role assignments (the on call platform engineer set: Contributor here, Key Vault Secrets Officer there, AKS RBAC Cluster Admin on the production clusters), and users are eligible for group membership. One activation, one approval flow, one audit trail, granting the whole working set for the shift. It also reaches where role PIM cannot: activating into a group that is assigned to applications, granting time bound access to third party systems that only understand group membership. Model your operational personas as PIM groups and the access model starts matching how people actually work.

Running It: Reviews, Alerts, and the Culture Part

PIM ships access reviews: quarterly attestation of who remains eligible, with auto removal on non response, which converts access sprawl from a permanent condition into a decaying one. Enable the built in alerts, roles assigned outside PIM, activations without use, too many Global Administrators, and route them into the Sentinel pipeline from September. Watch the audit log for activation patterns: a role activated daily at 9 AM by the same person is a workflow that needs a service identity or a delegated permission, not a human ritual, and each one you fix shrinks both friction and attack surface. The cultural objection, activation is annoying, is answered with tuning rather than surrender: sub minute activation for low risk roles with no approval, approvals reserved for the roles where a second pair of eyes is genuinely proportionate, and the break glass accounts from the Conditional Access post standing outside PIM entirely for the day the approval chain itself is the outage. Standing access is a convenience the estate pays for continuously; PIM converts it into a cost paid only at use, visibly, with receipts.

Cheers
Osama