The same just-in-time discipline extends over Azure RBAC, and almost everything you learned about it in the directory has to be relearned. Different administrative surface, different API, a different population who can even see the assignments, and one operational tax that catches every estate at exactly the same point: role settings here are per role and per resource, and they do not inherit.
The same argument, a different building
PIM layers eligible and time-bound assignments over Azure role-based access control at management group, subscription, resource group and resource scope, for built-in and custom roles alike. The argument for doing it is identical to the directory case and if anything stronger. A standing Owner on a production subscription is a credential that can delete the production subscription, and it is held by a human whose laptop exists in the world. Making that eligible rather than active is the same trade as before: the authority is unchanged, the window is not.
Microsoft’s deployment guidance names the starting point without hedging: manage all subscription Owner and User Access Administrator roles using PIM. Those two are the pair that matter, and User Access Administrator is the one people forget, for the same reason Security Administrator gets forgotten in the directory. It is the role that can grant the other roles. A tenant that has carefully made Owner eligible while leaving User Access Administrator standing has built a gate next to an unlocked door with a sign on it explaining how to make yourself a key.
One structural limit carries over unchanged and is worth restating because it bites harder here. Eligible assignments cannot be created for applications, service principals or managed identities, because those identities cannot perform the activation. In the directory that is an inconvenience. In Azure, where a great deal of legitimate authority is held by deployment pipelines and managed identities, it means a meaningful share of your privileged assignments simply cannot be brought into this model. Those need a different answer: tight scoping, time-bound active assignments where they fit, and the workload identity controls that live outside this wave.
Onboarding has quietly disappeared, which is good news with an edge
If you last looked at this a couple of years ago, you remember a discovery step: you went to the PIM blade, ran a Discover resources flow, and clicked things into management. That is now the legacy experience. PIM can automatically manage Azure resources in a tenant with no onboarding required, the newer experience is the default when you open Azure resources in PIM, and there is a banner link to switch between the two if you need the old one.
Two things survive from the old model and both are operationally sharp. The first is that management is still a one-way door, exactly as it is for groups: once a management group or subscription is managed, it cannot be unmanaged, and Microsoft is explicit that this exists to stop another resource administrator from removing PIM’s settings. The second is a piece of plumbing that will one day break your tenant if nobody knows about it. Legacy onboarding assigned a Microsoft service principal, MS-PIM, as User Access Administrator on the resource. That assignment is not decoration. Microsoft’s own troubleshooting guidance for access being denied in PIM identifies the cause as exactly this: somebody removed the User Access Administrator role from the MS-PIM service principal, and for PIM to reach Azure resources that principal must always hold it. It is precisely the kind of assignment that shows up in a well-meaning cleanup of unfamiliar service principals with elevated rights, and removing it produces failures that look nothing like their cause.
Where the administration actually happens now
The most useful thing to know about Azure resource PIM in 2026 is that a growing share of it does not happen in the PIM blade at all. It has been pulled into Access control, which is where Azure administrators already live, and that changes the adoption story more than any feature has.
When you add a role assignment through Access control, the flow now carries an Assignment type tab offering Eligible or Active, and an assignment duration of Permanent or Time bound with a start date and time. The wording in the interface is admirably plain: an eligible user must perform one or more actions to use the role, and an active user does not have to perform any action to use it. The same flow offers a Configure PIM Policy route into the settings, and a separate Update PIM policy link that lands you on the PIM page to edit role settings. On the other side, an eligible user can activate from where they already are: the Check access tab surfaces their eligible and time-bound assignments with an Activate role action, and the Subscriptions view carries a View eligible subscriptions option in its command menu that lists eligible, active and expired assignments and lets them activate in place.
This matters for a reason that is about people rather than technology. The main reason just-in-time access fails in Azure estates is that it asks platform engineers to go somewhere they never otherwise go, in a portal they associate with identity rather than with infrastructure, before they can do their job. Putting eligibility on the tab where they already assign roles, and activation on the page where they already check their access, removes the entire objection. When I am arguing for this with an infrastructure team, that is the argument that lands.
Two caveats before you build a rollout plan around it. This capability is still described as being deployed in stages, so it might not be present in your tenant yet, or might not look the way it does in the documentation. And on the Access control page the eligible assignment types are available at management group, subscription and resource group scope but not at an individual resource. That is a property of that flow rather than of PIM itself, which does reach individual resources from its own blade, and which is also where a standing assignment held at resource scope has to be converted. If your delegation model has landed on assigning roles at the level of a single storage account or key vault, Access control does not meet you there, and the answer is usually that the delegation should have been at the resource group anyway.
The tax: settings do not inherit
Here is the difference that reshapes designs. For Microsoft Entra roles there is one policy per role, tenant-wide, and the complaint is that it is too coarse. For Azure resource roles, settings are defined per role and per resource, and Microsoft states the consequence explicitly: role settings configured at a higher level, such as a subscription, are not inherited at a lower level, such as a resource group.
Take a moment with the arithmetic. Configure Owner with a one-hour window and approval on a subscription, then create a resource group beneath it, and the Owner policy on that resource group is whatever the defaults are, not what you carefully set one level up. Multiply by the number of scopes in a real landing zone, and the honest position is that a per-resource-group PIM policy design is not maintainable by hand at any interesting scale. This is not a criticism of the feature; it is the direct consequence of settings living on the resource rather than on the role, which is also what makes them expressive.
In the directory the policy is too coarse to express your design. In Azure it is fine-grained enough to express anything and too fine-grained to maintain by hand. Both push you to the same place: decide at the smallest number of scopes you can defend.
Three practical responses. Concentrate eligible assignments at the smallest number of scopes that expresses your real delegation model, which for most estates means the subscription and occasionally the management group, and resist the drift toward per-resource-group policies. Script the settings rather than clicking them, because the same policy applied to twenty scopes by hand is twenty chances to differ. And treat the scope design itself as the primary control: the landing zone series on this site already covers management group structure, and it is worth reading in that light, because a subscription topology that mirrors your delegation boundaries makes this problem small and one that does not makes it permanent.
A different API, and a different set of eyes
Automation crosses a boundary here that surprises people who have just finished scripting the directory side. PIM for Azure resources is built on Azure Resource Manager rather than Microsoft Graph. Microsoft’s guidance is direct about what that means: you consent to Azure Resource Management and need no Graph permissions at all, and the caller needs at least Owner or User Access Administrator on the resource being administered. The objects are role eligibility schedule requests and role assignment schedule requests under the authorization provider, with role management policies and policy assignments alongside them, and the tooling that reaches them is the Az PowerShell module rather than the Graph SDK.
One honest gap for the automation-minded: Microsoft publishes no Azure CLI commands for creating eligible role assignments or for reading and updating role management policies. The documented paths are the REST API and Az PowerShell. If your estate standardises on the CLI, that is a real friction point rather than something you have failed to find, and it is worth knowing before you plan the work.
The permissions story has a second consequence that is genuinely a governance issue rather than a technical one. Privileged Role Administrators, Security Administrators and Security Readers do not by default have access to view assignments to Azure resource roles. Read that again if you run a security function. The people you have made responsible for privileged access oversight can see every eligible assignment in the directory and are blind to every eligible assignment in Azure, unless somebody has separately granted them a reader role at the right scopes. I have sat in reviews where an organisation believed it had complete visibility of privileged access and was in fact looking at half of it, and nothing in either interface tells you that the other half exists. If you take one action item from this article, make it granting your security readers actual visibility of the Azure control plane.
What is missing here that you have got used to
Several things you now rely on from the directory side do not exist over here, and knowing the list saves you looking for them.
There is no Discovery and insights equivalent, so the bulk conversion of standing assignments to eligible ones that made the first build sheet quick has no counterpart. Converting an Azure estate is a scripted exercise or a patient one. There are no default approvers: where Entra roles silently fall back to the active Privileged Role Administrators and Global Administrators, here you must select at least one approver, and Microsoft recommends at least two. The alert surface is smaller and shaped differently, with four alerts rather than seven, evaluated per subscription, and the important one, roles being assigned outside PIM, fires only for assignments made at subscription scope. It will not tell you about a standing Owner granted at a management group, a resource group or an individual resource, which is a gap worth compensating for with your own monitoring. Microsoft also documents that this alert has produced duplicate notifications.
The good news is that the control that matters most does carry over intact. Authentication context works for Azure resource role activation with the same mechanics and the same ten-minute reauthentication window, so the phishing-resistant elevation from the previous two articles applies here without modification. Two small differences if you are following the documentation closely: the Azure page hedges the ordering instruction to a recommendation rather than an imperative, and it does not repeat the warning about never scoping a policy to the privilege being activated. Follow the stricter directory guidance anyway. The reasoning is structural and does not change because the page is shorter.
Two patterns worth having in the toolbox
The first solves the problem that the one-policy-per-role rule created in the directory, and it solves it in a way that is only possible here. If two populations need the same Azure role under different conditions, duplicate the built-in role as a custom role and give the custom role its own PIM policy. Microsoft documents this with a scenario worth borrowing wholesale: employees should be eligible for a role without approval, while contract associates doing the same work must be approved. Two roles with identical permissions, two policies, two populations. Give the custom role a name that makes obvious which built-in it duplicates, or you have created an archaeology problem for whoever inherits it.
The second is attribute-based conditions on eligible assignments, which lets you narrow what the activated role can touch rather than only how long it holds it. The combination is genuinely powerful, because it means a person can activate into a role that is both time-bound and constrained by attributes of the resource. Temper your enthusiasm with the current scope: conditions can be added today for exactly three built-in roles, all of them storage data roles, being Storage Blob Data Contributor, Storage Blob Data Owner and Storage Blob Data Reader. That is a narrow but real capability, and it is worth knowing about now so you recognise the pattern when Microsoft widens it.
A note on groups here, since the previous articles spent so long on them. For Azure roles, the group carrying the assignment can be any Entra security group, with none of the role-assignable requirements that constrain the directory. That sounds like a simplification and it partly is. But Microsoft’s own deployment guidance recommends against assigning or nesting a group into PIM for Groups for this purpose, and a group holding an eligible Azure role produces the double activation covered earlier: membership first, then the role. Pick one layer to be the gate.
Propagation, with different numbers
As everywhere in PIM, the assignment itself is created and removed within seconds. What differs is what sits downstream. Azure Resource Manager caches, and Microsoft’s own troubleshooting guidance says it can take up to ten minutes for role assignment changes to take effect, with the remedy being a sign-out and sign-in for the portal, PowerShell and the CLI, or a token refresh for anything calling REST directly.
Ten minutes against a one-hour activation window is a sixth of the window spent waiting, and that is the number to design against rather than the seconds figure. Two further cases are worth knowing because they are much longer and much less expected: managed identities that receive access through group membership sit behind a cache that Microsoft describes as lasting around twenty-four hours, and built-in roles with data actions assigned at management group scope can take several hours to take effect on the data plane. Neither is a reason to avoid PIM here. Both are reasons to be extremely specific in a runbook about what to expect, because an engineer who activates a role and finds it does not work will conclude the platform is broken and go and get a standing assignment instead, which is the outcome all of this exists to prevent.
Where to start
Owner and User Access Administrator on subscriptions, and nothing else in the first pass. Microsoft’s example posture for the critical subscriptions is a one-hour activation window with approval by other owners of that subscription and an eligible assignment expiring after three months; for the less critical ones it drops the approval and keeps the hour and the three-month expiry. That approver design is worth copying exactly, because “other owners of this subscription” is a population that both understands what is being asked and has a reason to care, which is the whole test of whether an approval gate does anything.
Then stop and let it run before extending. The three-month eligible expiry is doing real work in that design and it is the part people quietly drop, because it is the part that creates a recurring obligation. It is also the only thing standing between a well-designed eligible estate and the same accumulation of forgotten access you spent this project clearing out of the directory.
What remains after all of this is the discipline that keeps it true: the alerts worth acting on, the reviews that remove what nobody needs any more, and the audit trail that proves any of it happened. That is the next article, and it is the one that decides whether this survives its second year.
Governance
‹ Previous: [PIM 5] The Role Model: Fewer Than Five, and Two Outside the Machine
Next: [PIM 7] Operating PIM: The Loop That Keeps It Honest ›
