5.3.2. PIM for Azure Resources and Groups

💡 First Principle: The eligible/active machinery is generic — point it at any assignment system. PIM for Azure resources temporalizes Azure RBAC (Owner, Contributor at subscription/RG scope); PIM for Groups temporalizes membership and ownership of a group — and since groups carry roles, licenses, and app access, that quietly makes everything group-driven activatable.

PIM for Azure resources: onboard a subscription (or management group) to PIM discovery, then manage its RBAC assignments as eligible/active with the same per-role settings (duration, MFA, approval, justification). The 1.3.2 boundary reappears: Entra roles and Azure roles are separate hierarchies, so "just-in-time Contributor on the production subscription" is PIM for Azure resources — a stem answering it with Entra-role PIM has crossed the fence. Scope discipline applies too: eligible Owner at resource group scope beats subscription scope when the duty is narrower.

PIM for Groups: make membership (or ownership) of a group eligible. Two headline patterns. First, role-assignable group + PIM for Groups — the group holds one or more Entra roles (3.2.1's rules apply: created role-assignable, membership assigned not dynamic); activating membership grants the role bundle in one gate — cleaner at scale than per-role assignments, and the way to give one activation multiple roles. Second, access-bearing groups — a group granting a sensitive app, VPN profile, or CA exclusion becomes just-in-time without the app knowing anything about PIM. Each group gets its own activation settings (MFA, approval, duration), and activation propagates through whatever the group grants.

Together with 5.3.1 you now hold the full privileged-access design kit: eligible-by-default, per-role/per-group gates, narrow scopes, bounded windows — with active permanent reserved for exactly one category, covered next.

⚠️ Exam Trap: "Grant just-in-time membership that confers three admin roles at once with a single approval" = PIM for Groups on a role-assignable group — not three separate role assignments. And remember the creation-time flag: an existing normal group can't become role-assignable, so the design may require a new group.

Reflection Question: Security wants JIT for: (a) Contributor on the prod subscription, (b) User Administrator + Helpdesk Administrator as one bundle, (c) membership in the group that's excluded from a blocking CA policy. Name the PIM variant and one key setting for each.