Every meaningful decision Privileged Identity Management lets you make about a role lives on one settings page, and most tenants have never read it. The defaults are not published, the three-way choice at the top of the page is the difference between a real control and a decorative one, and the approval section behaves differently depending on which provider you are standing in. This is the vocabulary the rest of the wave assumes.
One policy per role, and what that constrains
PIM’s configuration surface for Microsoft Entra roles is a per-role policy, one policy per role, tenant-wide. Every assignment of that role shares it. There is no per-user variation, no per-scope variation, and no way to say that this particular person gets a longer window than that one. Editing the policy requires at least Privileged Role Administrator, which is itself a statement about how sensitive these settings are.
The one-policy-per-role rule is the first design constraint you meet, and it is more consequential than it sounds. If two populations need the same role under different conditions, say a small trusted group who should get four hours without approval and a wider group who should get one hour with approval, the Entra role policy cannot express that. You either accept the stricter setting for everyone, or you stop using the role directly and reach for a group as the unit of assignment, which is where the next article in this wave goes. Recognising which of those two you are in, early, saves a lot of rework. The Azure resource side plays by different rules again, with settings that are per role and per resource and do not inherit down the scope tree, and that gets its own article because the operational consequences are entirely different.
The page itself divides into three groups, and it is worth naming them clearly because people conflate the first two constantly. Activation settings govern what happens when an eligible person turns the role on. Assignment settings govern what kinds of assignment an administrator is allowed to hand out in the first place. Notification settings govern who hears about any of it. Only the first group is about the just-in-time story. The second is quietly the more strategic one.
The three-way choice, and why the middle option is the weak one
At the top of the activation settings sits the control that decides what an activation actually costs, and it resolves to one of three postures: require nothing beyond whatever justification and ticket fields you have turned on, require multifactor authentication, or require a Microsoft Entra Conditional Access authentication context. The two named settings are documented individually, they are mutually exclusive, and the choice between them is the most consequential one on the page. Almost every tenant I have inherited sits on the middle option, almost every published checklist recommends the middle option, and the middle option is the one that does the least work.
The reason is in Microsoft’s own documentation rather than in any independent research: users might not be prompted for multifactor authentication if they authenticated with strong credentials or provided multifactor authentication earlier in the session. That is a concession that the setting does not guarantee a challenge. It checks whether the session already carries a satisfied multifactor claim, and if it does, activation proceeds silently. For the ordinary case of an administrator who signed in at nine in the morning and is elevating at eleven, no prompt appears at all. The control that reads like a gate is, in that common case, an assertion about something that already happened.
Requiring multifactor authentication on activation does not require anything at activation. It inspects a claim the session was already carrying.
That matters because of who you are defending against. Against a careless insider, claim reuse is fine and the setting does its job as a speed bump. Against the actual threat model for a privileged role, which is an attacker holding a stolen session in which multifactor authentication has already been satisfied, it does nothing whatsoever. They inherit the claim along with the session. The gate opens for them exactly as smoothly as it opens for the legitimate user, which is to say silently.
The third option is the one that changes the physics, and Microsoft now says so directly: if your goal is to ensure that users must provide authentication during activation, use Conditional Access authentication context together with authentication strengths, because those options require users to authenticate during activation using methods different from the one they used to sign in to the machine. The activation becomes a claims challenge rather than a claims inspection, and a Conditional Access policy you control decides what satisfies it. That is a real control with a real price attached, and it went generally available in April 2026. It has its own doctrine article and its own build sheet later in this wave, and it is the single highest-value change you can make to a PIM deployment this year.
The remaining activation settings are simpler and mostly self-describing. Require justification on activation puts a free-text box in front of the user. Require ticket information on activation collects a ticket number and a ticketing system name, and it is worth knowing exactly what that is worth: correlation with information in any ticketing system is not enforced. The field is a prompt for honesty and a useful thing to have in the audit record when you are reconstructing an incident, not a validated link to a change record. Treat it as documentation rather than as control, and it is genuinely useful. Treat it as control and you have built a compliance story on a text box.
Approval is a design problem wearing the costume of a checkbox
Turning on Require approval to activate takes one click and creates an operational commitment that outlives whoever made it. The mechanics constrain the design more than the interface suggests, so it is worth laying them out before recommending anything. Approvers need no particular role to approve, which means the approver population is a design choice rather than a privilege consequence. Any approver can resolve the request; the first one to act decides it. Nobody can approve their own request. Requests expire after twenty-four hours and that window is not configurable, so an expired request has to be resubmitted from scratch. There is no multi-step approval, so the idea of a manager approving and then a security lead confirming does not exist here. Service principals cannot be approvers, and approval of extend and renew requests is not supported through the Graph API at all, which quietly rules out automating that half of the lifecycle. And every approver consumes a licence from the pool whether or not they ever hold the role themselves.
Then there is the behaviour that most published guidance gets wrong, because it states one rule globally when there are actually two. If you require approval on an Entra role and select no specific approvers, the active Privileged Role Administrators and Global Administrators become the default approvers. If you do the same thing on an Azure resource role or on a PIM-managed group, there are no default approvers at all and you must select at least one. The same checkbox, the same wording, and two entirely different failure modes: on Entra roles you get a silent fallback to the most privileged population in the tenant, and on the other two providers you get a configuration that will not let you proceed. Anyone who has learned the rule on one provider and applied it to another has learned it wrong.
The silent fallback deserves a second look, because it is the one that produces a bad design without complaining. Falling back to Global Administrators means the approval gate for a role is being staffed by the population you are least likely to want doing routine approvals, and it quietly makes the answer to “who approved this” depend on who happened to be looking. Select your approvers deliberately. Microsoft recommends at least two and so do I, for the ordinary reason that one approver is a holiday away from being an outage. The deployment plan’s own example for Global Administrator names the approver population as another Global Administrator, which is the right instinct: the approval only adds signal if the approver could plausibly refuse and would understand what they were refusing.
An approval gate is only worth its friction if a human somewhere could realistically say no. If they always say yes, you have not built a control, you have built a delay.
Which is the argument for using approval sparingly. Every approval is a delay in someone’s day and a decision on someone else’s, and the approval emails do not arrive instantly: Microsoft’s own figure is that ninety percent land within three to ten minutes, with some tenants seeing up to fifteen. Put approval on the roles where a second human genuinely adds judgement, meaning the tenant-wide and the destructive ones, and leave it off the roles a helpdesk uses forty times a week, where the only thing it produces is an approver who has learned to click yes without reading. There is also a documented way to get this catastrophically wrong that is worth stating plainly: if every Global Administrator and Privileged Role Administrator is eligible-only, approval is required, and no approvers are configured, then nobody can approve anything and tenant administration is locked. That specific scenario is one of the reasons emergency access accounts exist, and they get their own treatment later in this wave.
Assignment settings, which is where the strategy actually lives
The second group of settings gets much less attention and deserves more. Allow permanent eligible assignment and Allow permanent active assignment are the two switches that decide whether an administrator can hand out an assignment with no end date at all, and when they are off, the companions Expire eligible assignment after and Expire active assignment after set the ceiling. These are the settings that stop your carefully designed just-in-time estate from being undone six months from now by someone with Privileged Role Administrator and a deadline.
Think about what they enforce. Turning off permanent active assignment on a sensitive role means nobody, including the person configuring it, can grant standing access to that role without the grant carrying an expiry date. Turning off permanent eligible assignment means even eligibility has to be renewed, which sounds pedantic until you have inherited a tenant where forty people are eligible for roles they were given for a project that ended in 2023. Eligibility is not free. It is a smaller liability than a standing assignment, but it is still an assignment, and it still shows up in the blast radius of a compromised account.
Two more settings in this group are easy to misread. Require multifactor authentication on active assignment challenges the administrator who is creating a direct active assignment, at the moment they create it. It does not challenge the person receiving the role, and it does not challenge anyone when the role is used. Microsoft is explicit that PIM cannot enforce multifactor authentication when the user actually uses their role assignment. Require justification on active assignment works the same way, capturing a reason from the administrator making the grant. Both are about the provenance of the assignment, not about the use of the privilege, and reading them the other way leads to a false sense of coverage.
Expiry, extension, and the thirty-day tail
Time-bound assignments end, and the plumbing around their ending is more thoughtful than most people notice. Notification emails go out fourteen days before an assignment expires, one day before, and at expiry. An expired assignment does not vanish from view: it stays visible and renewable for up to thirty days, which is a sensible piece of humane design, because the most common time to discover that an assignment mattered is shortly after it stopped existing.
The two verbs are distinct and the distinction is not decorative. Extend becomes available to the user within fourteen days of expiry, while the assignment is still alive. Renew is what you do afterwards, from the expired roles view, inside that thirty-day tail. Either way, when the user initiates it, the request needs approval from a Global Administrator or a Privileged Role Administrator, which is exactly right: a user should not be able to indefinitely self-renew the thing whose whole purpose was to expire. An administrator initiating an extension does not need approval but does generate notifications to the other administrators, which is the correct trade. One exception catches people: an assignment inherited through group membership never offers Extend, because the assignment does not belong to the user, it belongs to the group.
The defaults you cannot look up
Here is the part of this article I would most like to be wrong about. Microsoft does not publish the out-of-box values of these settings. Not the default activation maximum duration, not the default eligible assignment expiry, not the default active assignment expiry. The numbers you will find quoted everywhere, eight hours for activation, a year for eligible, six months for active, are folklore. They may well be correct in your tenant. They are not sourced on current documentation, and I am not going to print them as fact.
It gets slightly worse, and this one is a genuine unreconciled conflict rather than an omission. The portal documentation for all three PIM providers describes the activation maximum duration as a slider covering one to twenty-four hours. The Microsoft Graph overview for privileged identity management states that activation is always time-bound for a maximum of eight hours. Both sentences are live on current Microsoft Learn, neither page acknowledges the other, and no page reconciles them. I have not been able to resolve it from documentation, and I would rather tell you that than pick the number that sounds more confident.
The practical response is short and it is the only durable one: never trust a slider you have not read in your own tenant. Before you design activation windows, open the policy for the roles you care about and record what is actually set, per role, as it exists today. Do that even for roles you have no intention of changing, because the numbers you find become the baseline you are arguing against, and because a policy someone tuned two years ago for a reason nobody remembers is exactly the kind of thing that survives a redesign by being invisible. The build sheet that follows this article makes reading the current state its first step for precisely this reason.
Whatever the defaults turn out to be, the duration you set is not the duration the administrator experiences. As the anchor article covered, workloads outside the directory lag, sometimes by minutes and in one documented pattern by far longer, so a window that is technically correct can still be operationally useless. Set durations per role against how the workload behaves rather than picking one number for the tenant, and expect the roles that reach into Exchange, SharePoint and Purview to need more room than the ones that stay inside the directory.
Notifications, and the ceiling nobody plans for
The third group lets you decide, per email type, whether notifications go out at all, whether they are limited to specific addresses, whether extra recipients are added, and whether only critical emails are sent. The most useful thing you can do with it is unglamorous: point the activation and assignment notifications at a monitored mailbox rather than at whoever happens to be a Global Administrator, so the record lands somewhere a human is accountable for reading.
There is one hard limit worth carrying in your head. A single event notifies at most one thousand recipients, and only the first thousand receive an email. Permissions are unaffected, and there is no documented mechanism that warns you the cut happened. In a small tenant this will never matter. In a large one, where a notification is configured to reach a broad distribution group and someone is relying on that reach as a detective control, it matters a great deal, and it fails quietly, which is the worst way for a detective control to fail.
That is the settings surface. Read in the right order it is a coherent argument: the assignment settings decide what kinds of privilege may exist, the activation settings decide what it costs to pick that privilege up, the approval design decides who else has to agree, and the notifications decide who finds out. The build sheet that follows takes a tenant with standing assignments and turns it into one that works this way, for a first, deliberately small set of roles.
Governance
‹ Previous: [PIM 1] Privileged Identity Management: The End of Standing Privilege
Next: [PIM 2.1] Build Sheet: Making Entra Roles Eligible ›
