In April 2026 the last real gap in Privileged Identity Management closed. Until then, the strongest thing a role could demand at activation was a multifactor claim the session was probably already carrying, which meant elevation cost an attacker holding a stolen session precisely nothing. It can now cost a security key, freshly presented, every time. This is the most consequential change available to a PIM deployment this year, and almost every article written about the subject predates it.
What the gate was actually worth
Set a role to require multifactor authentication on activation and you have made a statement that feels like a control. Microsoft’s documentation quietly tells you it is not: users might not be prompted for multifactor authentication if they authenticated with strong credentials or provided multifactor authentication earlier in the session. The setting inspects a claim. If the claim is present, activation proceeds with no interaction at all.
Line that up against the threat you are actually defending against. The realistic compromise of a privileged account in 2026 is not somebody guessing a password. It is an adversary-in-the-middle phish that captures a session in which multifactor authentication has already been satisfied, or a token stolen from a device. In both cases the attacker inherits the claim along with the session. They walk up to your activation gate carrying exactly the credential it asks for, and it opens as silently for them as it does for the legitimate administrator two floors away. The control was never checking whether the person elevating was who they claimed to be at the moment of elevation. It was checking whether somebody had proved that at some point earlier, which is a different and much weaker question.
A gate that accepts a credential the attacker already stole is not a gate. It is a receipt.
I want to be fair to the setting. Against a careless insider, or against somebody who has a password and nothing else, it does real work. It is simply not the control that a tenant-wide administrative role deserves, and until this spring there was nothing better generally available, so a great deal of otherwise good architecture was built on top of it.
A claim you have to go and earn
The alternative is to bind activation to a Conditional Access authentication context, and Microsoft is now explicit that this is the fix rather than a variant: if your goal is to ensure that users must provide authentication during activation, use 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. That last clause is the whole argument in one line.
An authentication context is a small, almost content-free object. It has a display name, a description, a switch that publishes it to applications, and a short read-only identifier. It carries no requirements itself. Its entire purpose is to be a label that a Conditional Access policy can be pointed at, so that a specific action, rather than a whole application, can be made to carry its own conditions. You create them under Conditional Access, and a tenant can hold a good number of them, though I would avoid printing an exact ceiling: the portal documentation and the developer guide both describe a range up to c99, while the Graph reference for the same object states that the allowed values run only to c25. Both pages are current. Design as though the supply is generous and finite, name them carefully, and do not build anything that depends on the hundredth one existing.
The mechanics matter because they explain the behaviours further down. When a role’s activation is bound to a context, PIM will not proceed unless the user’s token carries a claim asserting that context. If the claim is absent, the user is bounced back through Entra sign-in, where the Conditional Access policy targeting that context evaluates and enforces whatever it demands. Satisfy it and the token comes back carrying the claim, and the activation continues. What the user sees is a banner reading that a Conditional Access policy is enabled and may require additional verification, and an invitation to continue, followed by a redirect. The important structural point is that the requirement is not enforced by PIM at all. PIM only asks for evidence. A policy you write, and can change, decides what counts as evidence, which is what makes this composable with everything else you do in Conditional Access, and also what makes it fragile in the specific ways the next section describes.
What phishing-resistant actually admits
The evidence worth demanding is an authentication strength, and there are three built in: a multifactor strength, a passwordless strength, and a phishing-resistant strength. They cannot be modified, and Microsoft updates them as new methods ship, which is an argument for using a built-in rather than hand-rolling a custom strength that will slowly fall behind the platform.
The phishing-resistant strength currently admits exactly three things: Windows Hello for Business or a platform credential, a FIDO2 security key, and Entra certificate-based authentication at multifactor level. That is the list, and it is worth reading for what is absent. An Authenticator push does not satisfy it. A text message does not. A phone call does not. A one-time passcode does not. The defining property of the admitted methods, in Microsoft’s own framing, is that they require an interaction between the authentication method and the sign-in surface, which is exactly the property that an adversary-in-the-middle proxy cannot forge, because the credential is cryptographically bound to the thing it is signing in to.
That is the substantive change. Bind Global Administrator activation to a context, point a policy at that context requiring the phishing-resistant strength, and the credential that unlocks the most powerful role in the tenant becomes a categorically different and stronger thing than the credential that started the user’s workday. The user signs in at nine with a password and a push. At eleven, to become an administrator, they touch a key. A stolen session does not contain that key, and a proxy sitting between the user and Entra cannot replay it.
One limitation shapes deployment and it strands real people. A strength never constrains the first-factor sign-in, only the step-up. So a user who has only registered Windows Hello for Business, and who signed in with a password, hits a dead end at the challenge: the documented remedy is that they must restart the session, choose sign-in options, and pick a method the strength requires. That is a genuinely poor experience discovered at the worst possible moment, and it is why credential registration has to lead the rollout rather than follow it. A related known issue is worth carrying: a strength and a sign-in frequency requirement can be satisfied at two different times, so the two controls are not as tightly coupled as they look. And one hard constraint for anyone editing policies: you cannot combine the classic require-multifactor-authentication grant with a require-authentication-strength grant in the same policy, because the built-in multifactor strength is the equivalent of the former.
Three traps, stated plainly
This design has three failure modes that are documented, non-obvious, and capable of leaving you believing you have a control you do not have.
The first is the fallback, and it is the dangerous one. Microsoft built a safety net: if there are no Conditional Access policies in the tenant targeting the authentication context configured in PIM settings, then during activation ordinary multifactor authentication is required instead, as though the simpler setting had been chosen. Sensible. But the net is deliberately narrow, and the documentation says so: this backup is not triggered if the policy is turned off, is in report-only mode, or has an eligible user excluded from it. It exists only to cover the configuration mistake of wiring PIM to a context before the policy exists.
Read those two sentences together and the consequence is uncomfortable. I should be clear that Microsoft states the non-trigger conditions and does not spell out what follows; the following is my reading, and I am confident in it. If your policy is in report-only mode, or disabled, or if a user sits in an exclusion group, then there is a policy targeting the context, so the fallback stays asleep, and the policy itself is not enforcing anything for that user. The activation proceeds with neither the strength nor the ordinary multifactor challenge. A misconfigured exclusion is therefore strictly worse than having built none of this at all, because the tenant with no policy at least falls back to something. This is the single most important thing in this article to test rather than assume, and it is why the build sheet enables the policy before wiring PIM to the context, in that order, which is also Microsoft’s documented instruction.
A report-only policy on an activation context is not a safe first step. It is a gate that has been removed and looks installed.
The second trap is scoping, and it is the one people build wrong on the first attempt because the wrong version seems tighter. Do not create a Conditional Access policy scoped to both an authentication context and a directory role. During activation the user does not have the role yet, so the policy will not apply. The identical logic holds for groups: scope a policy to the context and to the group being activated, and it will not apply, because membership is exactly the thing the user is in the middle of acquiring. Scope by users, or by a group that the eligible administrators are permanent members of, and never by the privilege being requested.
The third is a window rather than a hole, but it will surprise you during testing. When a user reauthenticates for one activation, a ten-minute window applies, and a second activation inside that window prompts nothing. The window spans all three providers, so an Entra role activation can silently satisfy an Azure resource role activation ninety seconds later. This is deliberate and mostly humane. It also means the tester who activates twice in quick succession and sees a challenge only once has not found a bug, and the person designing tiered elevation should understand that the price is paid per ten minutes rather than strictly per activation.
To force a fresh challenge every time, add a session control: Microsoft’s current recommendation is to set sign-in frequency to Every time on the policy targeting the context. Two caveats travel with it. Every time means full reauthentication when the session is evaluated, not a continuous demand, and the platform allows five minutes of clock skew so that users are not prompted more often than once every five minutes.
Activation is not use
The context gates the moment of activation and nothing after it. Microsoft’s own illustration is the one to internalise: a user might activate from an Intune-compliant device, satisfying everything you asked, and then sign in from a different, non-compliant device and use the activated role from there. Nothing stops them. The role is active on the account, not on the session that earned it.
The documented answer is two policies rather than one. The first targets the authentication context and specifies what a user must satisfy to activate. The second targets directory roles and specifies what they must satisfy to sign in while holding an activated role. The two can demand the same things or different things. Most estates want the same strength on both and a device condition on the second, so that elevation requires a key and using the elevation requires a managed machine. If you build only the first policy, you have built a strong front door into a room with an open window, and it is a room you can see into from the internet.
Worth knowing before you go looking: this two-policy pattern is documented on the Entra roles page. The Azure resource roles and PIM for Groups pages offer only the weaker suggestion of scoping policies at eligible users directly. The reasoning transfers cleanly, but if you are checking my work against the source, that is where it lives.
Who can switch it off
Because the requirement lives in a Conditional Access policy rather than in PIM, the people who administer Conditional Access can dismantle it. Microsoft says so directly: principals who can manage Conditional Access policies, such as Conditional Access Administrators or Security Administrators, can change the requirements, remove them, or block eligible users from activating, and should be considered highly privileged and protected accordingly.
This is the point at which this article and the role model article become one argument. There is no value in requiring a security key to become Global Administrator if a dozen people hold standing Security Administrator and can quietly relax the policy that requires it. Those roles belong in PIM, under the same discipline, before this control means anything. It is also the strongest case I know for protected actions, which can bind Conditional Access policy management itself to an authentication context so that editing the policy carries its own price at the moment of editing.
Two automation notes that follow from the same architecture. Activating a bound role through Graph or PowerShell fails, because an interactive Graph token does not carry the claim the activation demands, and it fails with an error code that appears nowhere in Microsoft’s documentation. There is a community workaround and there are open issues against both SDKs; the build sheet covers what is actually known and what is not. And whether the claim must still be fresh when an approver acts hours later is simply undocumented. I expect not, since the step-up happens at submission, but I have not seen it stated and I will not assert it.
Where this sits relative to the framework
Readers running the VCIO Conditional Access framework will want to know how this composes with it, and the honest answer is that it sits alongside rather than inside, for now. The framework already governs how administrators authenticate; this policy governs one specific privileged act. I am treating the activation policy as an adjacent recommended policy: a standalone Conditional Access policy you create for the PIM activation pattern, named descriptively and kept separate from the numbered VCIO CA Framework rather than adopted into it, and not triggering a framework version bump. Adoption is a deliberate, separate revision, the same call I made for the Global Secure Access compliant-network policy, and doing it properly means renumbering and re-testing rather than quietly appending.
Two compositions are worth flagging while you are here. You can layer the network condition onto an activation policy, requiring the elevating user to be on the tenant’s compliant network through Global Secure Access, and it should work because this is an ordinary Conditional Access policy. I want to be precise that no Microsoft page documents that specific combination; the PIM pages name authentication strengths, Intune-compliant devices and terms of use as the examples, and network is my extrapolation from how policies compose. It is on my list to verify in a lab before I would put it in a build sheet.
And it is worth noticing where Microsoft itself is pushing. The Microsoft 365 admin center’s Baseline security mode ships a setting to protect admin access to Microsoft admin portals with phishing resistant authentication, which creates a Conditional Access policy to that effect in your tenant. The direction of travel is not subtle. Phishing-resistant authentication for administrators is becoming the assumed floor, and what this article describes is that floor applied to the sharpest moment in an administrator’s day rather than to the whole of it.
The build sheet that follows takes the headline scenario end to end: a standing User Administrator activates Global Administrator and is forced through a passkey to do it. It is the most useful thing in this wave.
Governance
‹ Previous: [PIM 3.1] Build Sheet: PIM for Groups End to End
Next: [PIM 4.1] Build Sheet: Phishing-Resistant Activation for Global Administrator ›
