7 mins to read
BLUF: Azure PIM converts always-on privileged role assignments into time-bound activations. Users request access, complete the required checks, do the work, and lose the role when the window closes. That’s the foundation of just-in-time privileged access in Azure.
—
Let’s establish the problem: most cloud environments have standing privilege. Identities sitting on permanent global admin or owner assignments, not because anyone made a deliberate choice to keep them that way, but because nobody went back to clean it up. Yet standing privilege is one of the most straightforward attack vectors in cloud. An attacker doesn’t need to escalate. They just need to reach that identity.
Azure PIM, (Microsoft Entra Privileged Identity Management) is Microsoft’s native service built to help address the problem of standing access. It makes powerful roles eligible and time-bound instead of always active. Users activate the access they need, when the task requires it, and lose it when the window closes. You’ll still see it called “Azure PIM” or “Azure Entra PIM” across most teams and documentation, even though Microsoft now uses the Entra naming. They refer to the same service.
For a lot of teams, getting PIM configured correctly is the first meaningful step toward reducing standing access in Azure.
How Azure PIM Supports Just-in-Time Access
PIM introduces two states for privileged role assignments: eligible and active.
An eligible assignment means the identity is approved to hold the role, but doesn’t hold it by default. To get access, the user has to explicitly request activation. Depending on how you’ve configured it, that request might require MFA, a justification, manager approval, or all three.
An active assignment means the role is live, full stop.
The JIT flow is simple: request activation, satisfy the requirements, use the role, and it expires. That expiration is the operative control. A role that expires after two hours can’t be abused two weeks later when credentials get compromised.
Azure PIM vs RBAC vs PAM: What Each One Does
These three terms can easily get used interchangeably. Let’s flesh out the differences.
Azure RBAC defines what an identity can do and where: management group, subscription, resource group, resource. It answers the “can” question.
Azure PIM controls when an eligible RBAC role becomes active and under what conditions. It answers the “when” question. It doesn’t change what the role grants. It gates access to it.
Cloud PAM is the broader practice: reducing standing privileged access across all cloud identities, permissions, and workflows. PIM is one mechanism inside that practice. Cloud PAM also covers right-sizing permissions, detecting unused access, governing service accounts and workload identities, and enforcing least privilege across multiple cloud providers.
Just using PIM as a complete PAM solution is not enough. It’s a strong Just-in-Time activation layer for Azure roles within Microsoft Entra, but permissions sprawl, over-permissioned service principals, and cross-cloud exposure need something more.
Before You Enable PIM: Plan Scope, Roles, and Break-Glass
Before you touch any policies, review your current privileged assignments. Document who holds what roles today and why. That review will surface orphaned assignments, overly broad scopes, and grants that predate current team structures. You can’t make good eligibility decisions without knowing what you’re starting from.
For each role, decide four things before you go live:
Scope. Is this assignment scoped to a specific resource, resource group, subscription, or management group? Narrower scope limits blast radius.
Activation duration. How long does someone legitimately need this role for a typical task? Use that as your ceiling, not a round number.
Approvers. Which roles need explicit approval versus self-activation with MFA and justification? High-sensitivity roles like Global Administrator and Owner at subscription scope should require approval.
On break-glass: keep at least two emergency access accounts outside PIM eligibility, monitor them closely for any sign-in activity, and store credentials with strict procedural controls. They exist for rare, but possible scenarios like the most recent global admin leaving the company or the user accounts are federated, but federation is currently down. Keep them separate and keep eyes on them.
Azure PIM Roles You Can Manage
PIM covers three categories.
Microsoft Entra directory roles – Global Administrator, Privileged Role Administrator, Security Administrator, User Administrator. Highest-sensitivity assignments for most environments.
Azure resource roles — Owner, Contributor, User Access Administrator, and built-in or custom roles at management group, subscription, resource group, or resource scope. Configured separately from directory roles.
PIM for Groups (rebranded from Privileged Access Groups in 2023) — makes group membership or ownership eligible rather than permanent. This extends JIT logic to anything the group grants: Azure roles, application permissions, access policies tied to group membership. If your team assigns access through groups rather than direct role assignments, this is the path.
One gap worth naming: PIM doesn’t natively manage service principals or managed identities. Those workload identities are common targets in cloud environments and require separate controls.
How to Enable PIM in Azure: The Setup Workflow
This is the high-level workflow. Microsoft’s documentation covers the click-by-click sequence. What matters here are the decisions.
- Open the Microsoft Entra admin center and navigate to Privileged Identity Management.
- Choose whether you’re configuring Entra directory roles or Azure resource roles. These are configured independently.
- For directory roles, select the role and set: activation duration, MFA requirement, approval requirement, notification settings.
- Assign eligibility to specific users or groups.
- For Azure resource roles, onboard the subscription or management group to PIM first before configuring role settings.
Start with a small number of high-value roles. Global Administrator and Owner at subscription scope are the obvious first targets. Validate the activation workflow with the people who will use it before you expand.
The most common security configuration mistake: setting activation duration too long to reduce friction. A 24-hour window on a role someone needs for 30 minutes isn’t a true JIT operation.
Azure PIM Best Practices for Reducing Standing Privilege
Start with discovery. PIM access reviews show who holds eligible and active assignments and when those assignments were last used. Run a review before you make new eligibility decisions.
Use the narrowest role that works. If someone needs to manage a single resource group, scope the assignment there, not the subscription. If a task requires read access, don’t grant Contributor.
Set activation windows based on task duration, not shift length. An eight-hour window is standing privilege with extra steps.
Review eligible assignments on a recurring schedule. People change roles. Projects end. Access granted for specific work persists without anyone noticing. PIM access reviews automate this process, but someone needs to act on the results.
Get your notification routing right. Approval requests going to a shared mailbox nobody monitors will delay activations and push users toward workarounds. That defeats the purpose.
Elevate PIM with Sonrai’s Just-in-Time
Sonrai’s Cloud Permissions Firewall is a cloud PAM platform built around one idea: identities should only have the access they need, when they need it, and nothing more. That means identifying what exists, what’s unused, restricting unused permissions, and granting permissions on demand through auditable workflows.
For teams already using PIM, Sonrai fills the gaps. PIM gates role activation in Azure, but it doesn’t tell you whether the permissions inside those roles are right-sized or whether they’re actually being used. An eligible role that grants far more than a task requires is still an oversized blast radius when activated. Sonrai identifies that excess privilege and restricts it before it becomes a problem. The two work together: PIM handles the activation workflow you’ve already built, Sonrai governs what those roles actually grant.
Where teams want to go further, Sonrai can take on the Just-in-Time access function too. This matters the most in two scenarios: when you’re managing workload identities and service accounts that PIM can’t touch, and when you’re operating across AWS and GCP alongside Azure. PIM’s scope ends at Microsoft Entra. Sonrai enforces consistent permissions governance across all three providers, so your JIT access story doesn’t have gaps the moment you step outside Azure.
Either way, Sonrai layered on top of PIM or running in its place, the goal is the same: reduce what’s standing, govern what’s used, and make sure every access grant has a reason behind it.
.
Conclusion
Azure PIM is the right starting point for just-in-time privileged access in Azure. It converts permanent role assignments into time-bound activations and gives you the audit trail to prove it. What it doesn’t do is govern the permissions those roles carry, manage workload identities, or extend to other cloud providers.
Teams that stop at PIM have addressed activation. Teams that also right-size roles, review assignments on a recurring basis, and extend coverage to workload identities and multi-cloud environments have addressed the underlying problem: standing privilege that exceeds need. These two different strategies will yield two different security results.
Frequently Asked Questions
Is Azure PIM the same as Microsoft Entra PIM?
Yes. Microsoft rebranded Azure Active Directory to Microsoft Entra ID. Azure PIM is now officially called Microsoft Entra Privileged Identity Management. The underlying service is the same — many teams still search for “Azure PIM,” which is why both names appear in Microsoft’s own documentation.
What is the difference between PIM and PAM in Azure?
PIM is a specific Microsoft Entra service that controls when eligible Azure roles become active. PAM is the broader practice covering how privileged access is granted, governed, reviewed, and revoked across cloud identities and systems. PIM handles activation. It doesn’t cover the full lifecycle of permissions governance.
What licence do you need to enable PIM in Azure?
Azure PIM requires a Microsoft Entra ID P2 licence. It’s included in Microsoft Entra ID P2, Enterprise Mobility + Security E5, and Microsoft 365 E5. Users who activate roles, approve requests, or appear in access reviews need to be covered by the licence.
How long should an Azure PIM activation last?
Match the duration to the task. A deployment that takes 30 minutes doesn’t need an 8-hour window. The common mistake is using longer windows to reduce helpdesk load — that trades security for convenience in a way that undermines the whole point of time-bounding access.
What are the most common Azure PIM mistakes?
Activating PIM on roles without first reviewing existing permanent assignments. Setting activation durations that are too long. Skipping approval requirements on high-sensitivity roles to speed up workflows. Failing to route audit logs to a SIEM. Most of the operational disruption teams experience comes from insufficient planning before enabling eligibility, not from PIM itself.
Does Azure PIM enforce least privilege on its own?
No. PIM controls when a role activates, not what it grants. A user with an eligible Global Administrator assignment still gets full Global Administrator permissions during the activation window. Right-sizing — assigning the narrowest role and scope that supports the task — is a separate decision that PIM doesn’t make for you.
Can Azure PIM manage service principals and managed identities?
Not directly. PIM manages human user assignments to Entra directory roles and Azure resource roles, and group membership through PIM for Groups. Service principals and managed identities fall outside its scope. Governing workload identity permissions requires separate controls — whether through Azure-native policies or a third-party cloud PAM platform that covers non-human identities.