The same discipline over Azure RBAC, with a different administrative surface, a different API, a different set of people who can even see the assignments, and one operational tax: role settings here do not inherit down the scope tree.

PIM controls when privilege is held, not what privilege exists. Which assignments should exist at all, who can undo the controls you just built, and the two accounts deliberately left standing, permanent, and outside the entire machine.

Make a user who signed in with a password and a push touch a security key before they can become Global Administrator. Authentication context, the Conditional Access policy, the role setting, and the exclusion that would quietly remove the gate.

Requiring MFA on activation reuses the claim the session already carried, so it charged an attacker nothing. Since April 2026 an activation can demand a phishing-resistant credential, fresh, every time. The mechanism, and its three traps.

Build a role-assignable group carrying three directory roles, bring it under PIM, and make the administrators eligible for membership rather than in it. One activation grants the tier; two of the steps cannot be undone.

Groups are how just-in-time access scales past a handful of roles, and they carry constraints sharp enough to reshape a design: a hard cap of 500, a documented slow path through Exchange and SharePoint, and a door that only opens one way.

Take a tenant from standing Global Administrator and Security Administrator assignments to a working just-in-time estate, with deliberate activation windows, a named approver population, and an audit trail that proves it.

Every meaningful PIM decision lives on one settings page, the defaults are not published anywhere, and the three-way choice at the top is the difference between a real control and a decorative one.