Not long ago, many of the Microsoft 365 tenants I visited had several users, and sometimes even service accounts, permanently assigned to the Global Administrator role. Usually that was for convenience. Some of those accounts had weak passwords, and hardly anyone ever reviewed them. That attitude has changed, thankfully, and permanent admin access is now widely seen as a major risk. Organizations that take governance and security seriously now use Privileged Identity Management (PIM) in Microsoft Entra ID as their standard tool.

Just-in-time access replaces standing permissions

To me, the core idea behind PIM is simple. Nobody should hold more privileges than they need, and nobody should hold them longer than necessary. We no longer assign admin roles permanently. Instead, users or groups get 'eligible' status and activate the role on demand, for a limited window, when their work calls for it. Each activation comes with clear requirements. MFA is the default, but you can also require a justification and, for sensitive roles, explicit approval from another administrator. This flexibility is useful in practice. For Exchange admins I often set stricter policies with approval and short time windows, while a less critical role like User Admin only needs MFA and a reason. The PIM role settings let you customize each role individually.

PIM for Groups brings new options and new pitfalls

A lot of people still underestimate PIM for Groups (see the documentation). It extends just-in-time assignment beyond directory roles to security groups and Microsoft 365 Groups. That helps a lot when, for example, a support team needs temporary access to certain resources or apps. It also adds complexity, though. In dynamic groups, eligible memberships can build up tangled permission chains. For that reason I run Access Reviews regularly and keep a close eye on group assignments.

JIT activation takes only a few steps in practice

For users, the activation flow is pleasantly simple. In the Entra portal, the eligible user requests activation for a role or group, enters a justification (for example "User onboarding for Project X"), completes MFA and, if configured, waits for an approver to accept the request. Only then are the elevated rights granted, and only for the configured time window. Every step is logged in Azure, so nothing goes unnoticed. My advice is to start with basic MFA requirements and add further layers such as justification or approval once you notice risk patterns or people trying to take shortcuts.

This flowchart shows the typical just-in-time activation process with PIM:

flowchart TD
  Start["Start: eligible user"] --> Request["Request activation"]
  Request --> MFA["Complete MFA"]
  MFA --> Reason["Enter justification"]
  Reason --> Approval["Approval (if required)"]
  Approval --> Active["Role active"]
  Active --> Expiry["End of time window"]
  Expiry --> Inactive["Role inactive"]

Figure: Just-in-time privileged role activation with PIM

It pays to treat roles differently. Global Admin always requires approval in my setups, while MFA and a reason are often sufficient for admin roles with less impact.

I avoid the usual pitfalls with a gradual rollout

Early in a PIM rollout, the same patterns tend to show up:

  • Too many users are made eligible for critical roles
  • Activation requirements are too loose or not adjusted per role
  • Access Reviews are missing or happen too rarely
  • Emergency accounts are forgotten and left unmanaged

One tip that has worked well for me:

Move a small group of trusted admins to PIM first and bring everyone else over step by step, never all at once. Emergency (break glass) accounts should always stay permanent, but they need close monitoring and proper documentation.

The move to PIM works best in stages. In workshops I set the order together with the admin teams. Global Admins go first, then the role-based admins (Exchange, SharePoint, Security), and after that the application-specific or delegated admins. Real emergency accounts, the "break glass" ones, stay permanent but under strict controls: unique long passwords, MFA, activity monitoring and well-tested procedures for emergency access.

Alerts, Access Reviews and reports make privileged access visible

What I value most about PIM is the transparency. Every activation, every change to a role setting and every attempt to get around the requirements ends up in a central log. You can set up alerts for suspicious activity such as repeated or simultaneous activations. I consider Access Reviews mandatory and schedule them regularly, so every eligible assignment gets checked to see whether it is still needed. If you stream the audit logs to a Log Analytics workspace (Entra admin center → Identity → Monitoring & health → Diagnostic settings, category "AuditLogs"), you can report on PIM activations with KQL under Logs in that workspace, for example:

AuditLogs
| where LoggedByService == "PIM"
| where OperationName == "Add member to role completed (PIM activation)"
| extend User = tostring(InitiatedBy.user.userPrincipalName), Role = tostring(TargetResources[0].displayName)
| summarize Activations = count() by User, Role

Dashboards like this show unusual usage quickly, and I can then contact the people responsible for those admin accounts before anything escalates. For setting up alert rules and reporting, the official PIM configuration docs are a good place to start.

Permanent admins give way to controlled access windows

Rolling out PIM across Entra ID tenants is one of the most effective ways I know to lower risk in Microsoft 365 environments. In almost every environment I've helped move over, there are fewer "privilege zombies" afterwards, and it's much clearer who has access, when and for what reason. The work doesn't stop after go-live, though. Role assignments and activation requirements need regular review so they keep up with new threats. And emergency accounts always need their own strict set of rules, however mature your PIM setup is.