A just-in-time estate decays back into a standing one within about a year, quietly, through exceptions that each seemed reasonable at the time. Nothing in this wave prevents that. What prevents it is an operating loop: a small set of alerts that are actually worth acting on, a review cadence that removes what nobody needs, and an audit trail that can prove any of it happened. This article is about that loop and about the two places it costs more than you expect.
The decay is the normal case
Every estate I have converted to eligible assignments drifted afterwards, and the drift never looked like a failure while it was happening. Somebody needed access urgently during an incident and got a standing assignment nobody removed. An integration could not activate, so a permanent grant was made and documented in a ticket that closed. A project team was made eligible for a tier they no longer work in. None of these is a mistake exactly; each one is a local decision that was probably right at the time. In aggregate they are the whole problem returning.
So the operating question is not how to prevent exceptions, which you cannot and should not. It is how to make them visible and how to make them expire. Alerts do the first. Reviews do the second. Audit is what lets you argue about any of it afterwards with evidence rather than recollection.
The alerts, as they actually are
PIM ships seven alerts for Microsoft Entra roles. Not a configurable framework, not a rules engine: seven, fixed, with a handful of tunable thresholds between them. Knowing that the list is short and closed is genuinely useful, because it tells you what you must build yourself.
One of the seven is worth more than the other six combined, and it is the only one rated high severity: Roles are being assigned outside of Privileged Identity Management. That is the alert for somebody granting a standing assignment through the ordinary roles experience and walking around everything this wave built. Its email can be toggled on or off in the alert settings, and for Entra roles those emails reach Privileged Role Administrators, Security Administrators and Global Administrators who have enabled PIM. Turn it on, route it somewhere a human reads, and treat it as an incident rather than as information. If you act on exactly one alert in this product, act on that one.
The rest are hygiene, all rated low except one, and each is useful in a different way. Administrators aren’t using their privileged roles fires when somebody goes a configurable number of days, from zero to a hundred, without activating, and it is the closest thing PIM has to an automatic prompt to remove an assignment. Potential stale accounts in a privileged role is rated medium and is the one whose behaviour changed: it is now based on sign-in activity over a configurable one-to-three-hundred-and-sixty-five-day window, and the documentation states explicitly that it is no longer based on the last password change date. If you have a runbook that explains this alert in terms of password rotation, that runbook is wrong. Roles are being activated too frequently takes a timeframe and a renewal count between two and a hundred, and is a decent proxy for an activation window that is too short for the work. Roles don’t require multifactor authentication for activation is a configuration check, and after the previous two articles you should be aiming past it rather than at it. The organization doesn’t have Microsoft Entra ID P2 or Microsoft Entra ID Governance is the only one you cannot configure at all, by design.
The seventh, There are too many Global Administrators, needs a warning attached. It fires only when two separate criteria are both met: a threshold on the number of Global Administrator assignments, tunable from two to a hundred, and a percentage of total role assignments that are Global Administrators, tunable across the full range. Meet only one and nothing fires. That is worth knowing because people configure the count, see nothing, and conclude the alert is broken. And if you go and read the settings page, brace yourself: Microsoft’s live text describes the count setting as the number you consider “too few” and the percentage as a level below which you do not want to “dip”, on an alert about having too many. I am not paraphrasing that into sense, because you will see the odd wording in the portal and should recognise it rather than doubt yourself.
Two structural facts finish the picture. Out-of-box values for every one of those tunables are unpublished, so as with the role policies, read your tenant rather than trusting a number you found in an article, including this one. And reading alerts requires one of Global Administrator, Privileged Role Administrator, Global Reader, Security Administrator or Security Reader, which is a sensibly broad list that lets a security function see this without being able to change it.
Seven alerts for directory roles, four for Azure subscriptions, and none at all for groups. The gaps are not oversights you can configure around. They are the specification.
Azure resource roles get a different and smaller set: four alerts, evaluated per subscription, covering too many owners, too many permanent owners, duplicate roles, and assignments made outside PIM. The last of those is high severity like its directory cousin and carries a limitation that matters enormously. It fires for role assignments created at subscription scope, and Microsoft states plainly that it is not triggered for assignments on management groups, resource groups or individual resources. So the exact move you would most want to catch, a standing Owner quietly granted at a resource group, is outside its coverage. Microsoft also documents that this alert has produced duplicate notifications. If Azure is a meaningful part of your estate, this gap is the strongest argument in this article for building your own detection over the activity log rather than relying on what ships.
PIM for Groups has no alerts at all. This is not an inference from an empty blade: Microsoft states that PIM security alerts are on the beta endpoint only and are available only for Microsoft Entra roles. Sit with that for a moment against the previous articles in this wave. The group is the object that bundles three roles into one activation, and it is the object with a documented way for an administrator to add a permanent member through the ordinary Groups experience and bypass PIM entirely. That combination has no alert. Whatever monitoring you build for tier groups, you are building it yourself, and the membership-changed event on a role-assignable group is where to start.
Discovery and insights as a ratchet
Discovery and insights, still labelled preview and still the successor to the old Security Wizard, is the tool the first build sheet used to convert standing assignments in bulk. Its value afterwards is different and underrated: run it periodically and it tells you what has crept back. Reduce Global Administrators lists who currently holds the role with bulk options to make eligible or remove. Eliminate standing access does the same across the other privileged roles. Review service principals lists the non-human identities holding privileged roles, offering removal only, because a service principal cannot be made eligible.
Treat it as a ratchet rather than a report. The number of standing privileged assignments in a healthy estate should only ever go down, and a quarterly pass through this page with the authority to actually remove things is worth more than any dashboard. The weekly PIM digest email, which goes to Privileged Role Administrators, Security Administrators and Global Administrators who have enabled PIM, has a Take action link that lands here, and it is one of the few product emails I would recommend nobody filter away. Note it is public cloud only, and note what it reports: users activated, users made permanent, assignments made inside PIM, assignments made outside it, and the top five roles by total administrators. The two numbers to watch on it are users made permanent and assignments outside PIM, which together are the decay rate of everything this wave built.
There is no equivalent for Azure resources. The conversion and the ongoing hygiene there are scripted or they are manual.
Reviews, and where they are actually created
Access reviews of Entra roles and Azure resource roles are created inside PIM, not in the general Access Reviews blade, and for Azure you pick the subscription first. That is a small navigational fact with a large consequence, because a security team that has standardised on the Access Reviews blade will not find privileged-role reviews there and may conclude the tenant has none.
The scoping choice that matters is assignment type, and the options are precisely eligible assignments only, active assignments only, or all active and eligible assignments. Choose deliberately, because the two halves answer different questions. Reviewing eligible assignments asks who should still be able to become an administrator, which is the governance question and the one that keeps the estate small. Reviewing active assignments in a properly converted tenant should return almost nothing except your emergency access accounts, which makes it a superb integrity check: a long list of active privileged assignments in a tenant that believes itself just-in-time is a finding all by itself. I run eligible-scoped reviews quarterly and an active-scoped review occasionally, for exactly that reason.
Cadence runs from one-time through weekly, monthly, quarterly, annually and semi-annually, with duration capped to stop instances overlapping; the published example is that a monthly review can run at most twenty-seven days. Selecting several roles does not produce one review covering them, it produces one review per role, so five roles means five reviews to track and five sets of decisions to apply. Reviewers can be named users, the members themselves, or each user’s manager with a mandatory fallback for people who have none.
On self-review I want to be careful to separate my opinion from Microsoft’s position. Members reviewing their own privileged access is a supported option, it is offered without any caution in the documentation, and Discovery and insights will even offer to require all Global Administrators to review their own access. My view, as practitioner guidance and not as anything Microsoft says, is that self-review is close to worthless for privileged roles taken alone. The question “do you still need to be able to become a Global Administrator” has one answer from almost everyone who currently can, and it is not the answer that shrinks the estate. Use named reviewers who own the tier, or managers, and keep self-review for the low-stakes access where the volume genuinely makes delegation impractical. One useful mechanical detail if you do use it: role-assignable groups are excluded from self-review, and under the manager option they fall to the fallback reviewer instead.
Two configuration details are worth setting deliberately. Auto apply results to resource decides whether denied access is actually removed when the review ends or whether somebody has to apply it by hand, and leaving it disabled is how organisations end up with a folder of completed reviews and an unchanged tenant. If reviewers don’t respond offers no change, remove access, approve access, or take recommendations. Recommendations are based on a thirty-day sign-in window covering both interactive and non-interactive sign-ins, which is more generous than people assume and worth knowing before you trust it. My default is auto-apply enabled and take recommendations, because the alternative is a review whose result depends on whether a busy person clicked something.
What actually happens when a reviewer says no
This is the part that surprises people, and it has one case that is a genuine trap.
First, nothing moves until the review completes and applies. No access rights change in the directory during the review, however emphatically reviewers have clicked deny. When it does complete, the state moves through applying to applied, and denied users are removed from roles in a few minutes. So the correct answer to “we reviewed that last week” is always “and was it applied”, which is a different question.
Second, the group cases diverge and the divergence is the trap. For an Entra role held by a role-assignable group, the review shows the group without expanding its membership, the reviewer approves or denies the group as a whole, and a denied group loses its role assignment. That is clean and it is what you would hope for. For an Azure resource role held by a security group, the review shows the group’s membership fully expanded, which looks more useful and is where the trap lives: when a reviewer denies a user who holds the role via the group, that user is not removed from the group. Microsoft’s stated reason is sound, that the group may grant other things elsewhere, and its stated consequence is that administrators must implement the changes resulting from the denial themselves.
In an Azure role review, a denial of a group member is a note to yourself. The reviewer believes they removed access. Nothing was removed.
Read that as a workflow requirement rather than a footnote. If you run Azure role reviews over group-based assignments, you need a step after the review where somebody reads the denials and acts on them, and you need reviewers to understand that their click is a recommendation rather than an action. Without that step you have built a review process that produces reassurance and no change, which is worse than not reviewing, because the reassurance is documented.
Two more cases cannot be auto-remediated at all: a user who holds access through a nested group is not removed from the nested group, so they keep the access, and a group synchronised from on-premises Active Directory cannot be managed in Entra, so its membership cannot be changed. Both fail in the direction of access being retained.
The sharpest licensing edge in the wave
Everything above is covered by Entra ID P2. Here is where that stops, and it is a seam rather than a slope.
Reviewing the role assignments held by a PIM-managed group is a role review, created in PIM, covered by P2. Reviewing the membership of that same group is a different feature: it is created in the Access Reviews blade under Teams and Groups, it covers all eligible and active members, and it requires Microsoft Entra ID Governance or the Entra Suite. Not P2. The licensing matrix carries it as its own row, still marked preview, with the P2 column blank.
Follow that through to the practical position. Build the tier-group model from earlier in this wave on a P2 tenant and you can review, quarterly and automatically, which roles that group holds. You cannot review, with the same machinery, who is eligible to activate into it, which is the question that actually matters, unless you buy Governance. On P2 alone you review the group’s membership by hand or by script. That is workable and I have shipped it, but it is a real gap and anybody costing this wave for a client needs to know about it before the design review rather than after. Two mechanical details if you do have the licence: only active owners are assigned as reviewers and eligible owners are excluded, so a group whose owners are all eligible has no reviewers at all, which is why a fallback reviewer is mandatory on these.
This seam is not an accident, and the anchor article named the reason. Microsoft’s stated position is that no new identity governance features will be added to P2. Everything new lands in Governance. Expect more seams exactly like this one, and expect them to fall along the same line: the thing that was in P2 stays, the thing built afterwards does not.
One further gap worth knowing rather than discovering: multi-stage reviews, where two or three sets of reviewers act in sequence, are documented for reviews created in the Access Reviews blade. The PIM review creation flow offers no multi-stage option anywhere. A general concept page does mention assignments to privileged roles in passing, which muddies it, but no procedure or interface anywhere backs that up. Treat multi-stage for PIM-created role reviews as undocumented rather than as available or unavailable, and design without it.
Audit, and the retention answer that is not the obvious one
All three providers carry a Resource audit blade for everything that happened and a My audit blade for what you personally did. Both hold thirty days of data. Thirty days is enough for an investigation that starts promptly and nothing like enough for one that starts when somebody finally notices, which in practice is most of them.
For longer retention, the PIM documentation’s own answer is to use Azure Monitor to route the data to an Azure storage account, and it links the guidance on archiving Entra logs to storage. I want to flag that deliberately, because the instinct of most people building this, mine included, is to send everything to a Log Analytics workspace, and that is not what these pages prescribe. In practice most estates want both, storage for cheap long retention and a workspace for the querying and alerting that the rest of this article assumes. Just know which one the documentation is pointing at when you follow it.
The correlation technique for reconstructing an activation is documented and worth committing to memory, because the audit log is dense. Filter the service to PIM. The reason the user gave appears in the status reason column. The approver is the actor shown as initiated by on the request-approved event, and the requester appears on the targets tab of the details pane, while the ticket number sits on the activity tab. A useful shortcut: the entry immediately above an approval event is typically the completion event, where the actor is the requester.
Two access notes that matter for how you staff this. Reading the audit history requires at least Privileged Role Administrator, which is a higher bar than reading the alerts, so the security reader who can see the alerts cannot necessarily see the audit trail behind them. And if your organisation uses a service provider through Azure Lighthouse, role assignments authorised by that provider do not appear here at all.
Then there is the single most valuable string in this article. The activity Add member to role outside of PIM (permanent) is the tell-tale for somebody bypassing everything you built. It appears under the RoleManagement category for directory roles and under ResourceManagement for Azure resource roles, so a detection written against only one of those categories is half blind. Note also what it does not cover: there is no equivalent event under GroupManagement, which is consistent with there being no alerting for PIM for Groups and reinforces that tier-group membership monitoring is yours to build.
Microsoft publishes a security operations page for PIM with ready-made detection content, and it is a better starting point than writing queries from scratch. Four Sentinel analytics templates are linked from it, covering bulk changes to privileged account permissions, changes to PIM settings, rejected elevation requests, and, my favourite for the sheer cynicism of it, detection of somebody disabling the PIM alerts. A companion page adds a template for a privileged role assigned outside PIM. Sigma rules are linked too, with an explicit disclaimer that they are community-written and not tested or maintained by Microsoft, so read before you deploy. And to save you a search: there is no PIM-specific Azure Monitor workbook template. The published gallery covers sign-ins, Conditional Access, multifactor authentication and identity protection, and PIM is not among them. Build your own over the audit logs.
The break-glass monitoring from the role model article belongs in this same loop, and it is the one alert that should reach a human by more than one channel, because the circumstances it fires in are the circumstances where email may be among the things that are broken.
One date on the calendar
If you have inherited any PIM reporting scripts, check what they call. The second-iteration beta API under the privileged access endpoint, covering directory roles and Azure resources, stops returning data on the twenty-eighth of October 2026. Note the verb carefully, because it decides how this fails: the endpoint stops returning data rather than being removed, so a script may keep succeeding and quietly report nothing at all. A privileged access report that returns zero findings looks exactly like good news.
The replacement is the current generally available surface, where the distinction to understand is between schedules and instances: schedule objects include assignments due to start in the future, while instance objects show only what is current. For a report answering who can do what right now, you want instances. PIM for Groups is unaffected by the retirement, since it only ever existed on the current generation. Two things remain on beta and are worth knowing before you build on them: the alerts API, which is also directory-roles-only, and the approvals API.
That is the loop: watch the one alert that matters, run the ratchet, review what should still exist, keep enough audit to argue with, and know which parts of the machinery cost more than P2. The build sheet that follows builds the review half of it end to end, including denying something and watching it actually disappear. After that, one article remains, on where PIM’s responsibility genuinely ends.
Governance
‹ Previous: [PIM 6] PIM for Azure Resources: JIT Over Azure RBAC
Next: [PIM 7.1] Build Sheet: Access Reviews for Privileged Roles ›
