A subscription Owner who can delete every resource group at 3 a.m. on a Sunday, with no approval, no justification, and no expiry, is the single most common privileged-access problem in an Azure tenant. Privileged Identity Management is the control that removes it. The account is not malicious and the engineer behind it is not careless. The role was assigned during a project two years ago, the project ended, and the assignment never did. That gap between when privilege was needed and how long it persisted is exactly the exposure that standing access creates, and it is the exposure Privileged Identity Management was built to close.

The mental shift this article asks for is small to state and large to absorb. Stop thinking of a privileged role as something a person has, and start thinking of it as something a person can request when they need it and lose when they do not. A permanent Owner has the role all the time, which means an attacker who phishes that account has Owner all the time, an audit of who can delete production returns a list that grew silently for years, and a single mistake at the keyboard has the blast radius of the highest-authority role in the tenant every minute of every day. Convert that same person to an eligible Owner who activates for four hours with a justification and an approval, and the privilege exists for four hours a quarter instead of permanently. The attack surface shrinks from continuous to occasional, the audit trail becomes a record of deliberate activations rather than a static list, and the blast radius is bounded to the windows when work is actually happening.

This is the rule the whole article turns on, and it is worth naming because it is what you will carry away when the configuration details fade. Call it the no-standing-access rule: privileged access should exist only when it is activated, not all the time, and Privileged Identity Management is the mechanism that makes time-bound, justified, approved elevation the default instead of the exception. Everything that follows, the eligible-versus-active distinction, the activation flow, the access reviews, the alerts, and the audit trail, is in service of that one rule. If you finish reading and remember nothing else, remember that least privilege has a time dimension, and that leaving an admin permanently assigned is a choice with a cost even when nothing has gone wrong yet.

What Privileged Identity Management actually is

Privileged Identity Management is a Microsoft Entra ID Governance capability that manages, controls, and monitors elevated access to Entra roles, Azure resource roles, and security groups. It does not invent a new permission system. It sits on top of the role-based access control model you already use and changes one thing about it: whether an assignment is permanently in force or has to be turned on before it works. That single change, applied consistently, is what converts a tenant from one where privilege is a static property of accounts to one where privilege is a transient, recorded event.

To use it you need a Microsoft Entra ID P2 license or a Microsoft Entra ID Governance license, and the same requirement is satisfied by Enterprise Mobility and Security E5, which includes P2. The license has to cover everyone who participates in the workflow, not just the people who hold roles: users who are eligible for any role managed through the tool, users who can approve activation requests, and users assigned as reviewers of an access review all consume a license. This is worth pricing out before you roll it out broadly, because a common surprise is discovering that the approver pool and the reviewer pool widen the license count beyond the obvious set of administrators. Flag the exact license entitlements against the current Microsoft licensing documentation before you commit a budget, because the editions and what each includes are revised periodically.

If you want the role model itself spelled out before going further, the Azure RBAC and ABAC breakdown covers roles, scope, and assignments in detail; this article assumes that foundation and concentrates on the time dimension that Privileged Identity Management layers on top of it.

What does Privileged Identity Management do that RBAC alone does not?

RBAC decides who can do what and at which scope. Privileged Identity Management decides when that authority is actually in force. RBAC alone leaves a privileged assignment active continuously; the governance layer makes it dormant until activated, time-limited once activated, and recorded every time it is used, which closes the window that a permanent assignment leaves open.

The distinction matters because RBAC is doing its job perfectly even when a tenant is wide open. A user with a permanent Owner assignment at the subscription scope has exactly the authority RBAC says they should have, all the time. Nothing is misconfigured in the RBAC sense. The problem is not the authority, it is the duration: the authority is in force during the long stretches when the person is not doing privileged work, which is most of the time. Privileged Identity Management does not narrow the authority. It narrows the duration. The same person can do the same things, but only inside a window they deliberately open, that closes on a timer, and that leaves a record behind. This is why the tool belongs in a least-privilege conversation even though it changes no permissions: it adds the axis that RBAC leaves unmanaged, which is how long a grant lasts.

Eligible versus active: the distinction the whole model rests on

Every assignment in Privileged Identity Management is one of two kinds, and getting the difference straight is the prerequisite for everything else. An active assignment is an ordinary RBAC assignment that is in force right now. The person holds the role; they can use its permissions immediately; nothing stands between them and the authority. An eligible assignment is a grant that is not in force yet. The person is allowed to hold the role, but they have to activate it first, and until they do, the permissions are not theirs to use. Eligibility is potential; activation realizes it.

The reason this two-state model matters is that it lets you grant broadly while exposing narrowly. You can make ten engineers eligible for a sensitive role and have zero of them holding it at any given moment, because none has activated. The set of people who could elevate is large and stable; the set of people who are elevated is small and changes minute by minute as work starts and finishes. An attacker who compromises one of those ten accounts inherits eligibility, not authority. To turn eligibility into authority they must complete the activation flow, which is where justification, multifactor challenges, and approval gates live, and which generates an alert and an audit record the moment it happens. Standing access gives the attacker the keys; eligible access gives them a request form that rings an alarm.

Both kinds of assignment can themselves be permanent or time-bound, which produces four combinations worth holding in your head. A permanent active assignment is the old default and the thing you are trying to eliminate: the role is in force forever. A time-bound active assignment is in force now but expires on a date, which suits a contractor with a fixed engagement. A permanent eligible assignment means the person can always activate when they need to, with no expiry on the eligibility itself, which suits a steady member of an operations team. A time-bound eligible assignment means the person can activate only until a certain date, after which even the eligibility lapses, which suits a project member whose involvement ends when the project does. The goal state for most privileged roles is permanent eligible with time-bound activation: the right to elevate persists, but each elevation is short.

Is an eligible assignment the same as having the role?

No, and treating it as the same is the most common misunderstanding of the model. An eligible assignment confers no live permission whatsoever. The holder cannot perform a single privileged action until they activate, and activation is a deliberate step with its own controls. Eligibility is the standing right to request elevation, not the elevation itself.

This is the hinge the security gain swings on, so it is worth being precise about what an eligible holder can and cannot do at rest. At rest, an eligible Owner cannot delete a resource group, cannot change an RBAC assignment, cannot read a secret that the role would grant, and would receive an authorization failure if they tried, the same failure an unprivileged user gets. If you have ever chased one of those failures, the AuthorizationFailed troubleshooting guide walks through reading them, and a denied action by an eligible-but-not-activated user is a legitimate cause that the guide accounts for. Only after activation does the assignment behave like an ordinary active role, and only for the duration the activation grants. When the activation expires, the holder silently returns to the at-rest state with no live permission, no manual cleanup, and no lingering grant. The reversion is the half of the model people forget: the security benefit comes not only from the gate on the way in but from the automatic close on the way out.

How just-in-time activation works

Activation is the act of converting an eligible assignment into a temporary active one. It is the moment the model earns its keep, because it is where you attach the conditions that a permanent assignment can never have: a reason, a challenge, a timer, and optionally a second person’s sign-off. Understanding the flow in detail is what lets you design it well rather than accepting the defaults.

When an eligible user wants to use a role, they open the Privileged Identity Management experience, select the role they are eligible for, and request activation. Depending on how the role is configured, the request triggers some combination of a multifactor authentication challenge, a justification field they must fill in, a ticket-number field, an approval routed to designated approvers, and a chosen duration up to a configured maximum. Once any required approval is granted and the challenges pass, the assignment becomes active for the requested window. The user does their work. When the window closes, the role deactivates automatically. They can also deactivate early if they finish sooner, though the system enforces a short minimum hold so that an activation cannot be immediately reversed; in practice you cannot deactivate within the first few minutes after activating.

Each of those conditions exists to answer a specific question that a permanent assignment leaves unanswered. The multifactor challenge answers “is this the genuine account holder and not someone who stole a session.” The justification answers “why does this person need this power right now,” and it becomes part of the audit record so the answer survives the moment. The approval answers “does someone other than the requester agree this is warranted,” which matters most for the roles that can do the most damage. The duration answers “for how long,” and it is the lever that keeps the exposure window short. None of these has a counterpart in a standing assignment, which is granted once and then answers no questions ever again.

How long can an activation last, and who decides?

Activation duration is set per role by whoever configures the role’s Privileged Identity Management settings, as a maximum the requester cannot exceed. The requester picks any duration up to that ceiling at activation time. A typical ceiling is a small number of hours, chosen so the role covers a work session without lingering, after which the role deactivates automatically.

The duration ceiling is one of the most consequential settings you will choose, and it rewards thinking in terms of the actual work rather than convenience. Set it too long and you have reinvented standing access with extra steps: an activation that lasts a full working day for a role used for a ten-minute change leaves the role live for hours after the work is done, which is most of the exposure of a permanent grant. Set it too short and you generate friction that pushes people to either reactivate constantly or pressure you to widen the ceiling, and friction that people route around is worse than no control. The right ceiling matches the natural unit of work for that role. A break-glass Owner used for emergency remediation might warrant a longer ceiling because emergencies run long and unpredictably. A routine operator role used for scheduled maintenance might warrant a tighter one because the work is bounded. The point is to choose deliberately per role, not to accept a single default across every role in the tenant.

The activation conditions in depth: justification, approval, MFA, and timing

The conditions you attach to activation are where policy meets practice, and each carries trade-offs that are worth examining rather than toggling blindly. The temptation is to turn everything on for every role in the name of security, but a workflow that is too heavy gets circumvented, and a circumvented control protects nothing.

Requiring multifactor authentication on activation is the cheapest strong control and should be on for essentially every privileged role. It costs the user a few seconds and a tap, and it defeats the entire class of attack where a stolen password or hijacked session tries to elevate. Because Privileged Identity Management can require the challenge at activation specifically, even a user who is already signed in has to prove possession of their second factor again at the moment they reach for privilege, which is exactly when you want the highest assurance. This is also where the control intersects with sign-in policy more broadly; the Conditional Access deep dive covers how the multifactor and risk signals that gate sign-in compose with the activation challenge, and the two together form a layered gate rather than a single point of trust.

Requiring justification turns every activation into a sentence of recorded intent. It is low friction and high value because it costs the user one line of text and it transforms the audit log from a list of who elevated into a record of why each person elevated. Months later, when a reviewer is deciding whether someone still needs eligibility, a history of justifications that all say “approving the quarterly storage migration” tells a story that a bare activation count never could. Pair justification with a ticket-number field where your operations process produces tickets, and the audit record links each elevation to the change it served.

Requiring approval is the heaviest control and the one to apply selectively. When activation requires approval, the requester’s elevation does not take effect until a designated approver signs off, which means a human other than the requester has agreed the elevation is warranted. This is the right gate for the roles that can cause the most harm, the subscription Owners and the User Access Administrators and the Global Administrators, and it is overkill for a low-impact role used dozens of times a day. The cost of approval is latency: if the approver is asleep or in a meeting, the requester waits, which is why approval and break-glass need to be reasoned about together. You do not want the approval requirement on the very role you would reach for in an incident at 3 a.m. when the approver is unreachable, so emergency-access roles are typically configured without approval but with heavy alerting, so that the activation is fast but loud.

Should every privileged role require approval to activate?

No. Approval is the right control for the highest-impact roles where a second person’s judgment is worth the latency, such as subscription Owner or Global Administrator. For frequently used lower-impact roles, approval adds delay without proportionate benefit, and for emergency break-glass roles it can block the very access an incident needs. Match the control to the role’s blast radius.

The discipline here is to rank your roles by what an activation of each could do at its worst, and to apply approval where the worst case justifies a second signature and to lean on multifactor, justification, and alerting where it does not. A role that can read non-sensitive monitoring data and a role that can delete the production subscription are not the same risk, and giving them the same activation workflow either over-controls the harmless one into disuse or under-controls the dangerous one into exposure. The findable artifact later in this article lays out a model for matching controls to roles so the workflow is proportionate rather than uniform.

Applying least privilege concretely: the no-standing-access target state

The principle of least privilege is usually taught as a question of breadth: give people the narrowest set of permissions that lets them do their job. Privileged Identity Management adds the dimension the breadth-only view misses, which is time. A permanent Owner assignment can be perfectly scoped to a single subscription and still violate least privilege, because the privilege is in force during all the hours the person is not exercising it. Least privilege in full is narrow in breadth and narrow in time: the smallest authority, in force for the shortest duration that the work requires. This time dimension is the thread that connects Privileged Identity Management to the broader posture described in the Zero Trust architecture guide, where “never trust, always verify” applies not only to each request but to the standing grants that make requests unnecessary.

The target state for a privileged role under this principle is concrete and worth stating plainly so you can measure your tenant against it. No human holds a permanent active assignment to a high-impact role. Every such role is held as eligible, permanent or time-bound as the person’s tenure warrants, with activation gated by multifactor and justification at minimum and by approval where the blast radius warrants it. Activations are short, scoped to the work, and recorded with their reasons. Break-glass accounts are the deliberate exception, kept as a small number of permanent active assignments precisely because they exist for the moments when the activation machinery itself might be unavailable, and they are watched closely enough that their use is impossible to miss. Everything else elevates just in time and deactivates on a timer.

What is the security gain from removing standing access?

The gain is that privilege exists only during the windows when work is happening, not continuously. A compromised eligible account inherits the right to request elevation, not live authority, so the attacker must complete an activation that triggers multifactor, justification, alerting, and possibly approval. The exposure window shrinks from permanent to occasional, and every elevation leaves a record.

To make the gain tangible, picture two tenants identical in every way except this one. In the first, twenty engineers hold permanent Owner. At any random instant, twenty accounts can delete production, and a phish against any one of them yields immediate, silent, unbounded authority. The audit of who can delete production is a list of twenty that has only ever grown. In the second tenant, those same twenty are eligible Owners who activate for a few hours when they have privileged work, which across the team averages perhaps one or two active at any instant. A phish against any one yields eligibility, which the attacker must convert through a gate that challenges, records, alerts, and possibly asks a second human. The audit of who is currently able to delete production returns one or two, not twenty, and the audit of who could activate returns a deliberately maintained list that access reviews prune. The permissions granted are identical. The exposure is an order of magnitude apart.

The misconfiguration that defines the problem: standing privileged access

Almost every privileged-access incident traces back to the same root: a high-impact role assigned permanently and actively to a human who does not need it most of the time. The configuration is not exotic. It is the default behavior of an ordinary RBAC assignment, and that is precisely why it is so common. You grant someone Owner to unblock them, the immediate problem resolves, and the grant outlives the reason for it by months or years because nothing in the platform prompts you to revisit it. Standing access is what you get by doing nothing, which is why removing it requires a deliberate practice rather than a one-time cleanup.

The breach this enables is not hypothetical and does not require an insider turning malicious. Consider the phishing path. An attacker compromises the credentials of an engineer who holds permanent Owner at the subscription scope. Because the assignment is active, the attacker has Owner the instant they have the session. There is no second gate, no justification to fabricate, no approver to fool, and no timer to wait out. They can disable logging, exfiltrate secrets the role can read, create persistence by adding their own assignments, and delete resources, all with the authority of an account that was supposed to be a trusted engineer. The only signal the defender gets is whatever ambient monitoring catches after the fact, because nothing about the elevation itself was anomalous; the account always had Owner, so using Owner is not an event.

Now replay the same compromise against an eligible Owner. The stolen session inherits eligibility. To do anything privileged, the attacker must activate, and activation forces a multifactor challenge that the stolen password alone does not satisfy, a justification that becomes evidence, an alert that fires the moment the request lands, and, if the role is configured for it, an approval from a second human who was not phished. Each of these is a place the attack can be stopped or, at minimum, made loud. The compromise is not prevented by Privileged Identity Management; credentials still leaked. What changes is that the leak no longer translates directly into privileged authority, and the attempt to translate it generates the signal that lets a defender respond before the damage is done.

Why is a permanent Owner assignment a risk even if no one misuses it?

Because risk is about exposure, not just intent. A permanent Owner is a continuously available target: it is what a phish, a leaked token, or a forgotten offboarding turns into immediate full authority. It also distorts audits, since the list of who can damage production never shrinks on its own, and it removes the natural checkpoint that activation provides.

The deeper issue is that standing access defeats the audit that is supposed to catch it. When privilege is permanent, “who can delete production” is answered by enumerating assignments, and that list only grows, because removing an assignment requires someone to notice it is stale, which requires a process that standing access does not create. When privilege is eligible and activated, the same question has two answers that are both more useful: who is elevated right now, which is a short and current list, and who could elevate, which is a list that access reviews actively prune on a schedule. The reason the eligible model produces a maintainable audit and the permanent model produces a sprawling one is that activation creates a recurring event to attach governance to, while a permanent assignment is a single event that recedes into the past and is never revisited unless someone goes looking.

The three scopes Privileged Identity Management governs

The tool manages elevation across three distinct kinds of assignment, and they behave consistently but apply to different parts of the platform. Knowing which scope a given piece of access lives in is what lets you bring it under governance, because a role you manage in one scope is invisible to the others.

Entra roles are the directory and tenant-level administrative roles: Global Administrator, Privileged Role Administrator, User Administrator, Security Administrator, and the rest of the roles that govern the identity platform itself. These are the highest-stakes roles in many tenants, because they control identity, and whoever controls identity can grant themselves anything else. Making these eligible rather than active is often the highest-value first move, because the worst outcomes in a tenant compromise run through directory roles. Global Administrator in particular is the role that should almost never be a permanent active assignment for a human, and the role most worth gating with approval and the heaviest alerting.

Azure resource roles are the RBAC roles assigned at management group, subscription, resource group, and resource scope: Owner, Contributor, User Access Administrator, and the many built-in and custom roles that govern resources. Privileged Identity Management for Azure resources lets you make these eligible at any of those scopes, so an engineer can be eligible Owner at one subscription and have nothing at another, activating only where and when they work. The scope hierarchy still applies, so eligibility at a management group cascades the way an active assignment would once activated, which means you should make people eligible at the narrowest scope that covers their work rather than high in the hierarchy out of convenience.

PIM for Groups extends the model to security groups, which is the lever that brings access beyond Azure roles under the same just-in-time discipline. By making membership or ownership of a group eligible rather than permanent, you can gate anything that group grants, including application roles, licenses, and access to systems that key off group membership. This is how you extend time-bound elevation past the boundary of Entra and Azure resource roles into the wider set of entitlements that groups drive, and it is the answer when someone asks how to apply the model to access that is not expressed as a role assignment at all.

Can Privileged Identity Management protect access that is not an Azure role?

Yes, through PIM for Groups. By making membership or ownership of a security group eligible rather than permanent, you bring whatever that group grants under just-in-time activation, including application access, licenses, and downstream systems that read group membership. This extends time-bound elevation beyond Entra and resource roles to any entitlement a group drives.

The practical consequence is that the question “what privileged access exists in this tenant” has to be asked across all three scopes, and a governance program that only addresses Azure resource roles will leave the directory roles and the group-driven entitlements standing. Many of the worst standing-access findings live in directory roles, because those are assigned during tenant setup and rarely revisited, and in groups, because group membership accretes as people move between teams and the old memberships are never removed. Bringing all three under the same eligible-and-activate discipline is what produces a tenant where privilege is genuinely time-bound rather than one where the Azure portal looks clean while the directory and the groups quietly hold permanent power.

Recurring patterns engineers report, and the control that fixes each

The same situations show up across tenants, and each maps to a specific Privileged Identity Management control. Treating them as patterns rather than one-off problems is what lets you build a standard response instead of improvising each time.

The permanent Owner that should be eligible is the canonical case. An engineer holds active Owner at a subscription from a project that ended. The fix is to convert the assignment from active to eligible, permanent eligibility if they remain on the owning team or time-bound if their involvement has an end date, and to configure activation with multifactor and justification. The engineer loses nothing they actually use, because they can activate whenever they have privileged work, and the tenant loses a continuously exposed Owner. This single conversion, repeated across every permanent high-impact assignment, is the bulk of the work in adopting the model.

The sensitive role that needs a second signature is the case for approval. A role can do enough damage that one person’s decision to elevate should not be sufficient, the subscription Owner used for destructive operations being the clearest example. The fix is to require approval on activation and to designate an approver pool that is reachable during the hours the role is used but does not include the requester. The cost is the latency of waiting for sign-off, which is why approval is reserved for the roles where a second judgment is worth the delay rather than applied uniformly.

The stale eligibility that no one removed is the case for access reviews. Over time, people accumulate eligibility for roles tied to projects, teams, and responsibilities they have moved on from, and eligibility, unlike activation, does not expire on its own when it is permanent. The fix is a recurring access review that asks the right person, the user, their manager, or a resource owner, to confirm that each eligible assignment is still needed, and that removes the ones that are not. Reviews are how the “who could elevate” list stays pruned rather than growing forever.

The out-of-hours activation that should be noticed is the case for alerts. An activation of a high-impact role at 3 a.m., or from an unusual location, or far more frequently than the role’s normal pattern, is exactly the signal a defender wants surfaced. The fix is to configure alerts on privileged activity so that activations, especially of the most sensitive roles, generate a notification that a security team sees, turning each elevation from a silent event into one that is observed in close to real time.

The cross-platform access that lives outside Azure roles is the case for PIM for Groups, applied as described above. And the audit question that arrives months later, “why did this person have this access on this date,” is answered by the justification recorded at activation, which is why making justification mandatory is the low-cost, high-value setting that pays off long after the activation itself is forgotten.

Access reviews: recertifying who still needs to elevate

Converting assignments to eligible solves the duration problem for the moments privilege is in force. Access reviews solve the accumulation problem for the eligibility itself. Eligibility is the standing right to activate, and a permanent eligibility does not lapse on its own, so without a recurring check the “who could elevate” list grows the same way the permanent-assignment list grew, just one step removed. An access review is the scheduled mechanism that asks, for each eligible assignment, whether it is still warranted, and that removes the ones that are not.

A review has a few moving parts that determine whether it produces a real decision or a rubber stamp. The scope is what is being reviewed: the eligible assignments to a particular role, or a set of roles, or group memberships. The reviewer is who makes the call, and the choice here matters more than any other setting. Self-review, where each user attests to their own continued need, is the lightest and the weakest, useful for low-impact roles where the user genuinely knows best and the stakes of an error are small. Manager review routes each decision to the user’s manager, which adds independence at the cost of asking managers to judge access they may not fully understand. Reviewer-designated review sends decisions to a named owner of the role or resource, which is usually the strongest option for high-impact roles because that owner understands what the access does and has a reason to keep the list tight. The recurrence is how often the review runs, monthly or quarterly being common, with more sensitive roles reviewed more often. And the auto-apply behavior decides whether the review’s outcome is enforced automatically when it completes or whether an administrator applies it manually.

The setting that separates a review that improves posture from one that quietly degrades it is the default for assignments a reviewer does not act on. If unreviewed assignments default to “approve,” a reviewer who ignores the request leaves all the access in place, and the review accomplishes nothing while creating the appearance of governance. If they default to “remove,” inaction prunes access, which is safer but can surprise people whose access vanishes because a busy reviewer never responded. The defensible choice for high-impact roles is to default to removal and to pair it with enough notice and a fast restoration path that an over-pruned user is unblocked quickly, because the failure mode of removing access someone needed is recoverable in minutes, while the failure mode of retaining access someone should have lost is a standing exposure that persists until the next review.

How often should privileged access reviews run?

Match the cadence to the role’s impact and the rate of organizational change. High-impact directory and Owner roles warrant monthly or quarterly reviews; lower-impact roles can run less often. Teams with frequent reorganizations, contractor turnover, or project churn need tighter cadences, because stale eligibility accumulates fastest where people and responsibilities move quickly.

The review is also where the justifications recorded at activation pay off a second time. A reviewer deciding whether an eligible assignment is still needed benefits enormously from seeing how the person has actually used it: an assignment activated weekly with clear, work-tied justifications is plainly still needed, while one that has not been activated in six months is a strong candidate for removal. This is why the activation justification and the access review are complementary rather than redundant controls. The justification captures intent at the moment of use; the review consumes that history to make a recertification decision that is grounded in behavior rather than guesswork. A program that requires justification but never reviews, or reviews but never required justification, leaves half the value on the table.

Alerts and the audit trail: making privileged activity observable

A control that no one watches is a control that fails silently. Privileged Identity Management produces two streams of observability that turn privileged activity from invisible to monitored, and configuring them is as much a part of adopting the model as the eligible assignments themselves.

Alerts fire on privileged activity that warrants attention. The tool ships with built-in alerts for conditions like too many administrators assigned to a role, roles activated too frequently, administrators not using their privileged roles, and activations occurring outside expected patterns. You can tune the thresholds to your environment, and you can route the alerts to the people who should act on them. The value of the alert is that it converts an activation, which is otherwise a routine event, into a signal a defender can evaluate: a Global Administrator activation at 3 a.m. from an unfamiliar location is exactly the thing you want a security analyst to see within minutes rather than discover during an incident review weeks later. Configuring alerts on the highest-impact roles is the difference between privileged activity being observed and privileged activity being merely logged.

The audit trail is the durable record of everything the system does: every assignment created or changed, every activation requested with its justification, every approval granted or denied, every review decision, and every alert. This record is what answers the questions that arrive long after the fact. When an auditor asks who had access to a subscription on a given date and why, the trail has the eligible assignments that were in force and the activations that occurred, each with its recorded reason. When an incident responder reconstructs what an attacker did, the trail shows whether a privileged role was activated, by whom, with what justification, and whether an approval was involved. Because the justification is captured at the moment of activation, the “why” survives even when the person who activated has forgotten the specifics, which is the property that makes the trail useful for governance rather than just forensics.

What does Privileged Identity Management record for each activation?

It records who activated, which role and at what scope, the time and duration requested, the justification text the user entered, any ticket number supplied, whether approval was required and who approved or denied it, and the result. This produces a per-activation account of who elevated, when, why, and with what oversight, retained in the audit log for later review.

The combination of alerts and audit trail is what lets you treat privileged activity as a monitored surface rather than a blind spot. Alerts give you the real-time signal to respond to anomalies; the audit trail gives you the durable history to investigate, recertify, and demonstrate compliance. Neither substitutes for the other. A tenant with eligible assignments but no alerts has made privilege time-bound but left its use unobserved, and a tenant with alerts but a never-examined audit trail has the signal without the memory. Configuring both, and routing the alerts to people who will act and reviewing the trail on a cadence, is what makes the governance real rather than nominal.

Verifying your privileged-access posture

Adopting the model is one thing; confirming it actually holds is another, and the confirmation is where many programs fall short because they assume the configuration matches the intent. The verification questions are concrete and worth running deliberately rather than trusting the dashboard.

The first question is whether any human still holds a permanent active assignment to a high-impact role. This is the single most important check, because a permanent active assignment is exactly the standing access the whole program exists to remove, and one that survives the rollout is a hole in the posture. The answer comes from enumerating active assignments to the sensitive roles and confirming that the only ones that remain are the deliberate break-glass exceptions. Anything else is a conversion that did not happen and should be completed.

The second question is whether the activation controls are actually configured on the roles that need them, not just intended. A role can be eligible-only and still be under-protected if its activation requires neither multifactor nor justification, because then activation is a formality that adds a click without adding assurance. Verifying the posture means reading the activation settings of each high-impact role and confirming that multifactor and justification are required, that approval is required where the blast radius warrants it, and that the duration ceiling is set to a sensible window rather than left long.

The third question is whether reviews are running and producing decisions. A configured-but-never-completed review is worse than no review, because it creates the appearance of governance without the substance. Verification means confirming that reviews exist for the high-impact roles, that they recur on an appropriate cadence, that they route to reviewers who actually respond, and that their outcomes are applied. The audit trail will show completed reviews and the decisions they produced, and a trail with no recent review activity for a sensitive role is a finding.

The fourth question is whether alerts are configured and reaching someone. An alert that fires into an unwatched mailbox is not observability. Verification means confirming that the alerts on the highest-impact roles are enabled, tuned to your environment so they are neither noisy nor silent, and routed to a team that will act on them. Running through these four questions on a schedule, rather than assuming the rollout stuck, is what keeps the posture from drifting back toward standing access as people, projects, and configurations change.

The InsightCrunch PIM model

The findable artifact for this article is a model that ties the pieces together into a decision you can apply per role: what kind of assignment to use, which activation controls to attach, how to review it, and where each choice reduces standing risk. Use it as a starting template and adjust the impact tier of any given role to your tenant.

Privileged Identity Management element	What it controls	Recommended setting by role impact	Where it reduces standing risk
Assignment type	Whether the role is in force or must be activated	High and medium impact: eligible. Break-glass only: active.	Removes continuous authority; a compromise inherits eligibility, not power
Eligibility duration	How long the right to activate persists	Steady team members: permanent eligible. Project or contract: time-bound eligible.	Time-bound eligibility lapses on its own when tenure ends
Activation duration ceiling	Maximum length of a single elevation	Routine roles: a few hours. Emergency roles: longer to cover incidents.	Bounds the exposure window per activation; auto-deactivation closes it
Multifactor on activation	Proof of possession at the moment of elevation	All privileged roles: required.	Defeats stolen-credential and hijacked-session elevation
Justification	Recorded reason for each activation	All privileged roles: required.	Creates the intent record that audits and reviews consume
Approval	Second-person sign-off before elevation	Highest impact (Global Admin, Owner): required. Lower impact: not required. Break-glass: not required, heavily alerted.	Adds independent judgment to the most damaging elevations
Access review	Recertification of who stays eligible	High impact: monthly or quarterly, reviewer-designated, default to remove. Lower impact: less frequent.	Prunes the “who could elevate” list so it stops growing
Alerts	Notification on privileged activity	Highest impact: enabled and routed to security.	Turns each elevation into an observed signal, not a silent event

The model’s organizing idea is proportionality. The controls are not free, and applying the heaviest ones uniformly produces a workflow people route around, while applying the lightest ones uniformly leaves the dangerous roles under-protected. Rank each role by what an activation of it could do at its worst, then read across the table to the column that matches. A monitoring-reader role and a subscription Owner sit in different rows of judgment even though they pass through the same machinery, and the model’s value is that it makes the difference explicit rather than leaving it to per-request improvisation.

Making it repeatable: Privileged Identity Management as code

Configuring eligibility, activation policy, and reviews by hand in the portal is fine for a first role and unworkable across a tenant. The configuration is data, and treating it as code is what makes the posture reproducible, reviewable, and resistant to drift. Two paths matter: declaring eligible assignments and policy in infrastructure templates, and driving the same operations through the Microsoft Graph API and PowerShell for automation and bulk work.

For Azure resource roles, eligible assignments are expressible as ARM and Bicep resources, which means you can put your privileged-access design in the same repository as the rest of your infrastructure and apply it through your normal deployment flow. A Bicep declaration of an eligible assignment names the principal, the role definition, the scope, and the schedule that makes it eligible rather than active:

// Eligible Azure resource role assignment via PIM
resource pimEligible 'Microsoft.Authorization/roleEligibilityScheduleRequests@2022-04-01-preview' = {
  name: guid(subscription().id, principalId, roleDefinitionId)
  properties: {
    principalId: principalId
    roleDefinitionId: roleDefinitionId
    requestType: 'AdminAssign'
    scheduleInfo: {
      startDateTime: utcNow()
      expiration: {
        type: 'NoExpiration'   // permanent eligibility; use 'AfterDateTime' for time-bound
      }
    }
    justification: 'Operations team standing eligibility for subscription Owner'
  }
}

The same surface is reachable through the Microsoft Graph API, which is the right path for Entra roles, for PIM for Groups, and for any operation you want to script across many principals at once. The role-management endpoints distinguish eligibility schedules from active assignment schedules, so creating an eligible assignment is a request against the eligibility schedule, and configuring the activation policy, the durations, the multifactor and justification requirements, and the approval settings, is a separate set of policy resources you can read and write programmatically. Driving it through Graph lets you reconcile the live state against your declared intent on a schedule and flag drift, which is the automated counterpart of the manual verification questions above.

# Create an eligible Entra role assignment through Microsoft Graph PowerShell
New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest `
  -PrincipalId $principalId `
  -RoleDefinitionId $roleDefinitionId `
  -DirectoryScopeId "/" `
  -Action "AdminAssign" `
  -Justification "Eligible for User Administrator; activate just in time" `
  -ScheduleInfo @{
      StartDateTime = (Get-Date)
      Expiration    = @{ Type = "NoExpiration" }
  }

The reason to invest in the code path rather than living in the portal is the same reason infrastructure as code wins generally: the configuration becomes something you can review in a pull request, diff over time, redeploy after an environment is rebuilt, and reason about as a whole rather than role by role. A team that recycles resource groups by tearing down and redeploying, for instance, loses any PIM resource-role configuration scoped to those groups when they vanish, and only a declarative definition reapplied on redeploy restores it reliably. The portal is where you learn the model and handle the occasional exception; the code is where the posture lives once you are operating it at scale. Treat any limit, schema version, or property name here as subject to change and verify the exact API version and resource shapes against the current Microsoft reference before you depend on them, since the role-management surface has evolved through several preview iterations.

Designing break-glass access alongside the model

The one place where standing active access is the correct choice is break-glass, and designing it well is part of designing the model rather than an exception to it. Break-glass accounts exist for the scenario where the activation machinery itself is unavailable: a federation outage, a Conditional Access misconfiguration that locks everyone out, or a failure in the identity platform that prevents normal elevation. If every privileged path requires activation and activation requires the very systems that are down, you have built a tenant you can be locked out of, which is its own catastrophic exposure.

The design that resolves this is a small number, typically two, of dedicated emergency-access accounts with permanent active Global Administrator, deliberately excluded from the Conditional Access and activation requirements that gate everyone else, with very long and complex credentials stored securely offline, and watched so closely that any sign-in is immediately visible to the security team. These accounts are not for daily use and not held by a named individual in their normal capacity; they are the deliberate, monitored exception that keeps the tenant recoverable. The tension between locking everything behind activation and retaining a recoverable path is resolved not by weakening the model but by carving out this explicit, heavily observed exception and treating any use of it as an event that demands immediate explanation.

The relationship between break-glass and approval is the reason emergency-access roles are configured without approval gates even though they are the highest-impact roles in the tenant. An approval requirement on the role you reach for during an incident, when the approver may be asleep or themselves locked out, turns the safety mechanism into a single point of failure. The substitute for approval on these accounts is alerting so loud that misuse cannot hide: every authentication should generate an immediate notification, and the expectation should be that any use is followed by a recorded justification after the fact. The principle holds, that privileged activity is observed, but it is enforced through detection rather than prevention, because prevention is the thing that fails precisely when you need the access most.

A sequence for rolling it out without breaking access

The order in which you adopt the model determines whether it lands smoothly or generates a wave of access failures that erode trust in the program. The instinct to convert everything to eligible at once is the instinct to avoid, because a tenant where every privileged path suddenly requires activation, before anyone has practiced activating, is a tenant where the first incident becomes the worst possible time to learn the workflow.

Start by taking inventory. Before changing anything, enumerate the standing privileged access across all three scopes: the active assignments to Entra roles, the active high-impact Azure resource roles at every scope, and the memberships of groups that grant privileged access. This inventory is the map of what you are converting, and it is usually larger than expected, because standing access accretes invisibly. The inventory also tells you which roles are high-impact enough to warrant approval and heavy alerting and which are routine, which is the input to applying the model from the artifact table proportionately.

Next, establish break-glass before you remove standing access, not after. The emergency-access accounts described above need to exist and be tested before you take away the permanent assignments people rely on, because the entire point of break-glass is to be the recoverable path when activation fails, and you do not want to discover during a lockout that you never set it up. Confirm the break-glass accounts can sign in and have the authority to fix a broken activation path, and store their credentials with the rigor that role demands.

Then convert in waves, starting with the roles where the security gain is highest and the disruption is lowest, which are usually the directory roles held by people comfortable with the workflow. Make the assignments eligible, configure activation with multifactor and justification, add approval and alerting where the impact warrants, and let the affected people practice activating for real work before moving to the next wave. Each wave teaches the team the workflow on roles where mistakes are recoverable, so that by the time you reach the most operationally sensitive roles, activation is a habit rather than a novelty.

Finally, stand up the reviews and the alerts and treat them as permanent operations rather than rollout tasks. The conversion to eligible is a project with an end; the reviews, the alert monitoring, and the periodic re-verification are a practice with no end, because the forces that create standing access, new projects, team changes, and convenience grants, never stop. A program that converts everything and then stops will drift back toward standing access within a year, because the conversion addressed the backlog but not the inflow. The practice is what addresses the inflow.

Common mistakes that hollow out the model

A tenant can have Privileged Identity Management fully deployed and still carry most of the risk it was meant to remove, because the model’s value lives in the settings and the practice rather than in the mere presence of eligible assignments. The mistakes below are the ones that turn a deployed control into a nominal one.

Setting activation durations too long is the most common way to reinvent standing access. An activation ceiling of a full working day for a role used in short bursts means the role is live for hours after the work is done, which is most of the exposure of a permanent grant with the added cost of a daily click. The duration ceiling should match the natural unit of work, and a ceiling that routinely leaves the role active long after the task finished is a ceiling set for convenience rather than security.

Skipping multifactor on activation is a quieter failure that defeats the headline benefit. If activation requires only a justification and no second factor, a stolen session can elevate by typing a plausible sentence, which is exactly the attack the model is supposed to stop. Multifactor on activation is the control that makes a compromised credential insufficient to elevate, and omitting it leaves the eligible assignment barely better than an active one against the most common attack path.

Configuring reviews that default to approve and routing them to reviewers who never respond produces governance theater. The review exists, runs on a schedule, and changes nothing, because inaction preserves all the access and the reviewers have learned that ignoring the request has no consequence. A review that defaults to remove and routes to an owner who understands the access is a review that prunes; anything else is a checkbox that consumes attention without improving posture.

Leaving directory roles and group memberships out of scope while converting only Azure resource roles addresses the visible third of the problem and leaves the rest. The worst standing access often lives in Global Administrator and in groups that accreted membership over years, and a program that makes Owner eligible while leaving Global Administrator permanently active has moved the lock to a side door while leaving the front door open. The model has to span all three scopes to span the actual risk.

Forgetting break-glass, or building it and never testing it, sets up the failure that is hardest to recover from. A tenant that has removed all standing access and has no working emergency path is a tenant one Conditional Access mistake away from a lockout with no way in. The break-glass accounts have to exist, have to be excluded from the gates that could lock them out, and have to be tested, because their entire purpose is to work when everything else does not.

Practicing the workflow before you need it

Reading about activation, eligibility, and reviews builds the model in your head; running them builds the reflexes that matter when a real role and a real deadline are involved. The gap between understanding the eligible-versus-active distinction and smoothly activating a role with a justification under time pressure is the gap that hands-on practice closes, and it is worth closing before the workflow is load-bearing.

This is where VaultBook fits the topic directly. Its Azure hands-on labs let you make a role eligible, run an activation end to end with justification and the multifactor challenge, configure an approval and experience both sides of the request, and set up and complete an access review, all in an environment where the stakes of a misstep are a reset rather than a production incident. Working through an activation that requires approval from the requester’s side and then from the approver’s side, for example, makes the latency trade-off concrete in a way that reading about it does not, and configuring a review that defaults to removal and watching it prune an unconfirmed assignment turns the abstract recommendation into a thing you have seen happen. The labs are the bridge from knowing the model to operating it, which is the bridge most teams cross during their first real incident if they have not crossed it deliberately beforehand.

How Privileged Identity Management composes with the rest of your security posture

The control is strongest as one layer in a posture rather than a standalone fix, and understanding how it composes with the adjacent controls is what keeps you from treating it as a silver bullet. It governs the duration of privilege; it does not govern the breadth of permissions, the conditions of sign-in, or the protection of the resources themselves, and each of those is a separate layer with its own mechanism.

The breadth of privilege is RBAC’s job, and the two are complementary rather than overlapping. RBAC says a person can be Owner of this subscription; Privileged Identity Management says they hold that role only when activated. A poorly scoped RBAC design, where someone is eligible for far more than they need, is not fixed by making the over-broad role eligible, because eligible over-broad access is still over-broad once activated. Get the scope right with RBAC first, then make the correctly scoped role eligible, so that the just-in-time elevation is to the right authority rather than to too much authority that is merely time-bound.

The conditions of sign-in are Conditional Access’s job, and the two form a layered gate. Conditional Access evaluates the sign-in itself, the user, the device, the location, the risk, and decides whether to allow it and under what challenges. The activation gate evaluates the moment of elevation specifically. A session that Conditional Access allowed can still be required to pass a fresh multifactor challenge at activation, which means even a session that cleared the front door faces a second gate at the moment it reaches for privilege. Designing the two together, so that the sign-in policy and the activation policy compose into a coherent set of challenges rather than a redundant or contradictory pair, is part of building the posture rather than the individual controls.

The protection of the resources is the job of the resource-level controls, the network restrictions, the data protections, the key management, and elevation governance does not replace them. Making an Owner role eligible does nothing to protect a storage account that is publicly exposed; it only ensures that the human authority to change that storage account is time-bound. The point is that Privileged Identity Management closes one specific gap, the gap of standing human privilege, and it closes it well, but a posture that relies on it alone has hardened the administrative path while potentially leaving the data path, the network path, and the breadth of permissions unaddressed. It is a layer in defense in depth, and its value is realized when the other layers are present rather than substituted for.

What the workflow feels like day to day

The model succeeds or fails on whether the people living inside it find it workable, so it helps to picture the experience from both sides of an activation rather than only from the policy view. The requester’s experience, when the role is configured sensibly, is short. They open the Privileged Identity Management experience, see the roles they are eligible for, select the one they need, fill in a justification, complete a multifactor challenge if they are not freshly authenticated, choose a duration within the ceiling, and submit. If the role does not require approval, the elevation is theirs within moments and they proceed with their work. The friction is a handful of seconds and one sentence of typing, and the habit forms quickly once a person has done it a few times for real tasks.

The approver’s experience, on the roles configured for approval, is a notification that a named person has requested a named role with a stated justification, and a decision to grant or deny with an optional comment. The information the approver needs to decide well is exactly what the requester supplied, the who, the what, and the why, plus whatever the approver knows about the current situation. A good approval process keeps the approver pool reachable during the hours the role is used, so the latency is minutes rather than hours, and it excludes the requester from approving their own elevation, which is the separation that gives the second signature its meaning. When approval latency becomes a complaint, the fix is usually to widen or rebalance the approver pool rather than to remove the approval requirement, because the requirement is doing real work on a high-impact role.

The experience that matters most, and that people overlook, is deactivation, because it is the part that happens automatically and silently. The requester does not have to remember to give back the role; it expires on the timer they chose, and they return to the eligible-at-rest state with no action and no live permission. This is the property that makes the model sustainable, because a control that depended on people remembering to relinquish access would fail the way standing access fails, through human forgetting. The timer is the thing that does not forget, and the automatic reversion is the quiet half of the security benefit that the activation gate gets the credit for.

Measuring whether the program is working

A privileged-access program that is not measured drifts, because the forces that create standing access are constant and the discipline that removes it is not self-sustaining. A small set of measures tells you whether the posture is holding or eroding, and tracking them on the same cadence as the reviews keeps the program honest.

The count of permanent active assignments to high-impact roles is the headline measure, and the target is zero outside the deliberate break-glass exceptions. This number going up between measurements means standing access is being created faster than it is being converted, which is a signal to find where the new permanent grants are coming from and to close that source rather than just cleaning up after it. A program that converts the backlog but lets the inflow continue will watch this number climb back toward where it started.

The activation patterns per role tell you whether the durations and ceilings are set sensibly and whether any role is behaving anomalously. A role activated constantly might be a candidate for a longer ceiling or might indicate that the work it serves is continuous enough to question whether just-in-time fits, while a role never activated is a candidate for removing eligibility entirely, because an eligibility that is never used is standing risk with no offsetting benefit. The activation history is also where you spot the out-of-pattern events, the unusual hours and locations and frequencies, that the alerts surface in real time and the audit trail preserves for review.

The review completion rate and outcomes tell you whether the recertification is real. Reviews that complete with reviewers actually making decisions, and that remove some non-trivial fraction of eligibilities over time, are doing their job. Reviews that complete only because they default to approve on inaction, or that never remove anything, are theater, and the measure that distinguishes the two is whether the reviewers are engaging and whether the eligible population is being pruned. A review program that has never removed an eligibility is almost certainly not finding the stale access that accumulates in every tenant. Taken together, these measures answer one question on a recurring basis: is the tenant trending toward time-bound privilege or quietly sliding back toward the standing access it started with. A program that watches the permanent-assignment count, the activation patterns, and the review outcomes catches the slide while it is still a handful of grants rather than a tenant-wide regression, which is the difference between a quick correction and a second full conversion a year later.

Edge cases and limits worth planning for

A few behaviors of the model surprise teams when they meet them mid-operation rather than reading about them first, and planning for them is cheaper than discovering them. The license-lapse behavior is the one with the largest blast radius. If the Entra ID P2 or Governance entitlement lapses or a trial ends, the features stop, and the way they stop matters: permanent active assignments are unaffected, time-bound active assignments become permanent active, eligible assignments are removed because users can no longer activate, and the management surfaces for activation, assignment, and reviews become unavailable. The practical consequence is that a lapse does not fail safe; it can leave you with newly permanent assignments and removed eligibilities, which is close to the opposite of the posture you built. Treating the license as a hard dependency of the security posture, not a soft convenience, is the lesson, and monitoring the entitlement is part of monitoring the control.

The scope cascade for Azure resource roles behaves as you would expect from RBAC, which means eligibility granted high in the hierarchy covers everything beneath it once activated. This is a convenience that becomes a risk when used carelessly, because making someone eligible at a management group to save the effort of granting at each subscription gives them, on activation, authority over every subscription under that management group. The discipline is to grant eligibility at the narrowest scope that covers the person’s actual work, the same discipline that applies to active RBAC assignments, because time-bounding over-broad access does not make it less broad while it is active.

The short minimum hold after activation, the few minutes during which a freshly activated role cannot be deactivated, occasionally confuses people who activate by mistake and want to immediately reverse it. It is a minor behavior rather than a problem, but it is worth knowing so that an accidental activation is handled by letting it expire or waiting out the hold rather than by assuming the deactivation is broken. PIM for Groups interacting with nested groups, and with systems that read group membership on a cache rather than live, is the edge case to test rather than assume: the time-bound membership is governed correctly, but a downstream system that caches membership may not reflect a deactivation immediately, which is a property of the consuming system rather than of the governance, and one to verify for any access path that matters. As with all platform specifics, verify the current behavior of these edge cases against the official documentation before you build a dependency on them, since the details are revised over time.

The verdict

Privileged Identity Management is the control that gives least privilege its missing dimension. Scope answers how much authority a person has; this answers how long they have it, and the honest target for any high-impact role is “only when activated, never continuously.” The mechanism is not complicated once the eligible-versus-active distinction is clear: grant the right to elevate, gate the elevation with multifactor and a recorded reason and, where the blast radius warrants, a second person’s approval, bound each elevation with a timer that closes it automatically, recertify who keeps the right to elevate through scheduled reviews, and watch the activity through alerts and the audit trail. Apply that across all three scopes, the directory roles, the Azure resource roles, and the group memberships, and a tenant’s privileged surface shrinks from continuous to occasional.

The work is real but bounded, and most of it is the one-time conversion of standing assignments to eligible ones plus the standing practice of reviews, alert monitoring, and periodic verification that keeps the inflow of new standing access from undoing the conversion. The two failure modes to guard against are deploying the machinery without the settings that give it teeth, long durations, skipped multifactor, and rubber-stamp reviews that hollow it out, and forgetting the break-glass path that keeps the tenant recoverable when the activation machinery itself is unavailable. Avoid those, and the result is a tenant where a compromised account inherits a request form rather than a master key, where the audit of who can damage production is a short and maintained list rather than a sprawling one, and where every elevation is a deliberate, recorded, time-bound event. That is the no-standing-access rule in practice, and it is one of the highest-value security improvements available in an Azure tenant for the effort it costs.

Frequently asked questions

Q: What is Privileged Identity Management in Azure?

Privileged Identity Management is a Microsoft Entra ID Governance capability that manages, controls, and monitors elevated access to Entra roles, Azure resource roles, and security groups. Rather than leaving privileged roles permanently assigned, it lets you make them eligible, so a person holds the right to activate a role but does not hold the role’s authority until they activate it. Activation can require a multifactor challenge, a recorded justification, an approval from a second person, and a time limit after which the role deactivates automatically. The capability also provides access reviews that recertify who should keep eligibility, alerts on privileged activity, and an audit trail of every assignment, activation, approval, and review. Its purpose is to remove standing privileged access in favor of time-bound, justified elevation, so that privilege exists only during the windows when work is happening rather than continuously.

Q: What is the difference between eligible and active assignments?

An active assignment is an ordinary role assignment that is in force right now; the person holds the role and can use its permissions immediately. An eligible assignment is a grant that is not in force yet; the person is allowed to hold the role but must activate it first, and until they do, the permissions are not theirs to use. Eligibility is potential authority, and activation realizes it. This two-state model is what produces the security gain: you can make many people eligible for a sensitive role while zero hold it at any given moment, so a compromised eligible account inherits only the right to request elevation, not the authority itself. Both kinds can be permanent or time-bound, giving four combinations, and the target state for most privileged roles is permanent eligible with time-bound activation, meaning the right to elevate persists while each elevation is short.

Q: How does role activation and justification work?

Activation converts an eligible assignment into a temporary active one. The eligible user opens the Privileged Identity Management experience, selects a role they are eligible for, and requests activation. Depending on the role’s configuration, the request triggers a multifactor challenge, a justification field they must complete, an optional ticket-number field, an approval routed to designated approvers, and a chosen duration up to a configured maximum. Once any required approval is granted and the challenges pass, the role becomes active for the requested window, and it deactivates automatically when the window closes. The justification is recorded in the audit trail, which turns the log from a record of who elevated into a record of why each person elevated. That recorded reason survives the moment and becomes evidence an access reviewer or an auditor can consume later, which is why making justification mandatory is a low-cost, high-value setting on every privileged role.

Q: How do access reviews fit Privileged Identity Management?

Access reviews recertify who should keep eligibility. Converting assignments to eligible solves the duration problem for the moments privilege is in force, but a permanent eligibility does not lapse on its own, so without a recurring check the population of people who could elevate grows over time. An access review is the scheduled mechanism that asks, for each eligible assignment, whether it is still needed, and removes the ones that are not. A review has a scope, a reviewer who makes the decision, a recurrence, and a default for unacted assignments. The most consequential choices are the reviewer, where a role owner who understands the access is stronger than self-attestation for high-impact roles, and the unacted-assignment default, where defaulting to removal prunes stale access while defaulting to approval lets inaction preserve everything. Reviews are how the “who could elevate” list stays pruned rather than accumulating indefinitely.

Q: How does Privileged Identity Management give just-in-time least privilege?

Least privilege is usually framed as breadth, giving the narrowest set of permissions, but it has a time dimension that breadth alone misses. A permanent Owner can be perfectly scoped and still violate least privilege, because the authority is in force during the long stretches when the person is not exercising it. Just-in-time access adds the time axis: the authority exists only inside a window the person deliberately opens, that closes on a timer, and that leaves a record. The person can do exactly the same things they could before, but only when they activate, only for the duration they need, and only with the controls activation imposes. This shrinks the exposure from continuous to occasional without narrowing the permissions, which is why the capability belongs in a least-privilege conversation even though it changes no permissions. Full least privilege is narrow in breadth and narrow in time, and this supplies the second half.

Q: How do approval and alerts work in Privileged Identity Management?

Approval and alerts are two separate controls that often pair on high-impact roles. Approval, when required on a role, holds an activation request until a designated approver signs off, so a human other than the requester agrees the elevation is warranted. It is the right gate for the most damaging roles, such as subscription Owner or Global Administrator, and overkill for frequently used low-impact roles where the latency outweighs the benefit. Approvers should be reachable during the hours the role is used and should never include the requester. Alerts fire on privileged activity worth noticing, such as too many administrators on a role, activations outside expected patterns, or unusual frequency. The built-in alerts can be tuned to your environment and routed to a security team so that activations of sensitive roles are observed in close to real time rather than discovered later. Together they add independent judgment before the fact and observability during and after it.

Q: Do I need a special license for Privileged Identity Management?

Yes. The capability requires a Microsoft Entra ID P2 license or a Microsoft Entra ID Governance license, and the same requirement is met by Enterprise Mobility and Security E5, which includes P2. The license has to cover everyone who participates in the workflow, not only the people who hold roles. Users who are eligible for any managed role, users who can approve activation requests, and users assigned as reviewers in an access review all consume a license, which often widens the count beyond the obvious set of administrators. It is worth pricing this out before a broad rollout, because the approver and reviewer pools can expand the entitlement requirement unexpectedly. Treat the license as a hard dependency of the security posture rather than an optional add-on, and monitor the entitlement, because if it lapses the features stop in a way that can leave newly permanent assignments and removed eligibilities behind. Verify current edition details against Microsoft’s licensing documentation before budgeting.

Q: What happens to my roles if the Privileged Identity Management license lapses?

The features stop, and the way they stop does not fail safe. Permanent active assignments are unaffected and remain in force. Time-bound active assignments become permanent active, meaning they stop expiring on their schedule. Eligible assignments are removed, because users can no longer activate them. The management surfaces for activation, assignment, and access reviews become unavailable across Entra roles, Azure resource roles, and groups. The net effect is close to the opposite of the posture you built: you can end up with assignments that are now permanently active and eligibilities that have vanished, rather than the time-bound model you configured. This is why the license should be treated as a hard dependency and the entitlement monitored alongside the rest of the security posture. A lapse is not a graceful degradation; it is a reversion toward standing access, and planning for it means ensuring the entitlement does not lapse unnoticed and that break-glass remains intact through any transition.

Q: Can Privileged Identity Management manage access that is not an Azure role?

Yes, through PIM for Groups. By making membership or ownership of a security group eligible rather than permanent, you bring whatever that group grants under just-in-time activation. Because many entitlements key off group membership, including application roles, licenses, and access to systems that read groups, this extends time-bound elevation well beyond Entra and Azure resource roles. It is the answer when access you want to govern is not expressed as a role assignment at all. The same activation controls apply: a person can be made eligible for a group, and activating their membership can require multifactor, justification, and approval, with the membership deactivating automatically when the window closes. One edge case to test is downstream systems that cache group membership rather than reading it live, since a deactivation may not propagate to such a system immediately; that is a property of the consuming system rather than of the governance, and worth verifying for any access path that matters.

Q: Should every privileged role require approval to activate?

No. Approval is the right control for the highest-impact roles, where a second person’s judgment is worth the latency it adds, such as subscription Owner, User Access Administrator, or Global Administrator. For frequently used lower-impact roles, approval adds delay without proportionate benefit and can push people to find ways around the workflow. For emergency break-glass roles, an approval requirement is actively harmful, because it can block the very access an incident needs when the approver is unreachable. The discipline is to rank roles by what an activation could do at its worst and apply approval where the worst case justifies a second signature, while relying on multifactor, justification, and alerting for the roles where it does not. Applying approval uniformly either over-controls harmless roles into disuse or, more often, leads teams to weaken it everywhere because it is painful on the roles where it does not belong. Proportionality is what keeps the control credible.

Q: How long should an activation last?

Match the duration ceiling to the natural unit of work for the role rather than to convenience. A ceiling set too long reinvents standing access, because the role stays live for hours after the work is done, which is most of the exposure of a permanent grant. A ceiling set too short generates friction that pushes people to reactivate constantly or to pressure you to widen it, and a control people route around protects nothing. Routine operational roles used in short bursts often warrant a ceiling of a few hours, enough to cover a work session without lingering. Emergency or break-glass roles may warrant a longer ceiling, because incidents run long and unpredictably and you do not want the access expiring mid-remediation. The requester picks any duration up to the ceiling at activation time, so a sensible ceiling lets people choose short windows for short tasks while still covering the occasional longer one. Set the ceiling per role deliberately rather than accepting one default across the tenant.

Q: How is Privileged Identity Management different from RBAC?

RBAC decides who can do what at which scope; Privileged Identity Management decides when that authority is actually in force. RBAC alone leaves a privileged assignment active continuously, so a user with permanent Owner has exactly the authority RBAC grants, all the time, which is correct in the RBAC sense but leaves the authority exposed during the long periods the person is not using it. The governance layer does not narrow the authority; it narrows the duration, making the assignment dormant until activated, time-limited once activated, and recorded each time it is used. The two are complementary rather than competing: you still design the role and its scope with RBAC, getting the breadth right, and then make the correctly scoped role eligible so the elevation is just-in-time. Making an over-broad role eligible does not fix the breadth problem, because eligible over-broad access is still over-broad once activated, so get the scope right first, then add the time dimension.

Q: Which roles should I convert to eligible first?

Start with the highest-impact directory roles, particularly Global Administrator and the other Entra roles that govern identity, because the worst outcomes in a tenant compromise run through whoever controls identity, and these roles are often assigned during setup and never revisited. They are usually also held by people comfortable with the activation workflow, so the disruption of converting them is low while the security gain is high. From there, convert the high-impact Azure resource roles, the subscription and management-group Owners and User Access Administrators, then work outward to the broader set of privileged roles and the group memberships that grant privileged access. Convert in waves rather than all at once, letting each wave practice the workflow on roles where mistakes are recoverable before reaching the most operationally sensitive ones. Establish and test break-glass access before removing standing assignments, so the recoverable path exists before you take away the permanent one people currently rely on.

Q: Does Privileged Identity Management prevent account compromise?

No, and it is important to understand what it does and does not do. It does not prevent a credential from leaking or a session from being hijacked; phishing and token theft still succeed against the account. What it changes is the consequence of the compromise. Against a permanent active assignment, a stolen session inherits live privileged authority immediately, with no further gate and no signal, because the account always had the role so using it is not an event. Against an eligible assignment, the stolen session inherits only eligibility, and to do anything privileged the attacker must complete an activation that triggers a multifactor challenge the stolen password alone does not satisfy, a recorded justification, an alert that fires immediately, and possibly an approval from a second human who was not compromised. The compromise is not prevented, but it no longer translates directly into privileged authority, and the attempt to translate it generates the signal a defender needs to respond.

Q: What is break-glass access and why does it stay permanent?

Break-glass access is a small number of dedicated emergency-access accounts kept as permanent active Global Administrator, deliberately excluded from the Conditional Access and activation requirements that gate everyone else. They exist for the scenario where the activation machinery itself is unavailable, such as a federation outage or a Conditional Access misconfiguration that locks everyone out. If every privileged path required activation and activation required the systems that are down, the tenant could lock you out entirely, which is its own catastrophic exposure. These accounts stay permanent precisely because their purpose is to work when normal elevation does not, and they are configured without approval because an approval gate on the role you reach for during an incident becomes a single point of failure when the approver is unreachable. The substitute for the controls they bypass is alerting so loud that any use is immediately visible, plus the expectation of a recorded justification after the fact. They are the deliberate, heavily watched exception that keeps the model recoverable.

Q: Can I manage Privileged Identity Management as code?

Yes. The configuration is data and can be treated as code, which makes it reproducible, reviewable, and resistant to drift. For Azure resource roles, eligible assignments are expressible as ARM and Bicep resources, so you can keep your privileged-access design in the same repository as the rest of your infrastructure and apply it through your normal deployment flow. The Microsoft Graph API and the Graph PowerShell module reach the same surface and are the right path for Entra roles, for PIM for Groups, and for bulk or scripted operations across many principals. The role-management endpoints separate eligibility schedules from active assignment schedules, and the activation policy, durations, multifactor and justification requirements, and approval settings are configurable through their own resources, so you can reconcile live state against declared intent and flag drift automatically. This matters for teams that recycle environments, because configuration scoped to torn-down resource groups is lost on teardown and only a declarative definition reapplied on redeploy restores it reliably. Verify the exact API versions and resource shapes against current documentation, as the surface has evolved through several preview iterations.

Q: How do I verify that standing access has actually been removed?

Run four checks deliberately rather than trusting the dashboard. First, enumerate active assignments to the high-impact roles and confirm the only ones remaining are the deliberate break-glass exceptions; any other permanent active assignment to a sensitive role is a conversion that did not happen. Second, read the activation settings of each high-impact role and confirm multifactor and justification are required, approval is required where the blast radius warrants it, and the duration ceiling is a sensible window rather than left long, because an eligible-only role with no real activation controls is barely better than an active one. Third, confirm reviews exist for the sensitive roles, recur appropriately, route to reviewers who respond, and have their outcomes applied, since a configured-but-never-completed review is governance theater. Fourth, confirm alerts on the highest-impact roles are enabled, tuned, and routed to a team that acts on them, because an alert into an unwatched mailbox is not observability. Run these on a schedule, since posture drifts back toward standing access as people, projects, and configurations change.

Q: What are the most common mistakes when adopting Privileged Identity Management?

The recurring mistakes hollow out the model while leaving it nominally deployed. Setting activation durations too long reinvents standing access, because the role stays live for hours after the work is done. Skipping multifactor on activation defeats the headline benefit, because a stolen session can then elevate by typing a justification, which is exactly the attack the model should stop. Configuring reviews that default to approve and routing them to reviewers who never respond produces governance theater, because inaction preserves all the access. Converting only Azure resource roles while leaving Global Administrator and privileged group memberships permanently active addresses the visible third of the problem and leaves the rest, and the worst standing access often lives in those directory roles and groups. Forgetting break-glass, or building it and never testing it, sets up a lockout with no recoverable path. Avoiding these comes down to making the settings match the role’s impact, spanning all three scopes, keeping the reviews real, and treating the program as an ongoing practice rather than a one-time project.

This article covers a security and identity topic; treat any license detail, API version, default duration, or platform behavior described here as subject to change, and verify the specifics against the current official Microsoft documentation before you depend on them in production.