Require phishing-resistant MFA on every PIM activation

Privileged Identity Management has always been able to require MFA on activation. The problem is that a user who already signed in with MFA often isn't challenged again, and any MFA method counts, including weaker ones. Requiring a Conditional Access authentication context on activation fixes both: you decide exactly what the user must prove, and it's checked every time they activate.

How it fits together

• Authentication context is a label, such as "Privileged activation", that apps and services can request.
• A Conditional Access policy targets that label and sets the requirements, for example phishing-resistant MFA from a compliant device.
• PIM requests the label when someone activates a role, so the policy is enforced at that moment.

Setting it up

1. Create the context. In the Entra admin center, go to Conditional Access → Authentication contexts and create one, for example Privileged role activation. Make sure it's published to apps.
2. Create the policy. Make a new Conditional Access policy targeting your admins. Under Target resources, choose Authentication context and select it. Under Grant, require the Phishing-resistant MFA authentication strength. Optionally add a compliant device requirement and a sign-in frequency of every time.
3. Test in report-only mode, then switch it on.
4. Configure PIM. Go to Identity governance → Privileged Identity Management → Microsoft Entra roles → Settings, pick a role and choose Edit. Under activation, select On activation, require Microsoft Entra Conditional Access authentication context and choose your context.
5. Repeat for each high-value role, starting with Global Administrator, Privileged Role Administrator, Security Administrator and Conditional Access Administrator.

Things to watch

• Make sure admins have a passkey first. If you require phishing-resistant MFA, admins without a passkey or security key can't activate. Use a registration campaign or passkey profile ahead of time.
• Exclude your break-glass accounts from the policy, and monitor their sign-ins separately.
• Apply it to PIM for Groups too if you use groups to grant privileged access. The same setting exists in group role settings.

• Exclude break-glass accounts from the policy
• Make sure every admin has a phishing-resistant method registered first
• Test in report-only mode, then use What If
• Apply the context to every privileged role, not just Global Administrator
• Check scripted activations still work, since the token must satisfy the context