The problem

You've done everything right.

The user is eligible for Global Admin through PIM.

Conditional Access requires MFA.

The PIM role requires MFA on activation.

On paper, that's textbook least privilege.

Then you actually test it. You activate the role.

No prompt.

Direct elevation to Global Admin.

Why this happens

Require MFA is a claim check. Not an action.

If the user already authenticated with MFA earlier in the session, the claim is present. PIM looks at the claim, sees it, and says "good enough."

No new verification happens at the moment of elevation.

Which means:

• A user who logged in 30 minutes ago gets a free elevation.
• A token-stealing attacker who already passed MFA gets a free elevation too.

The whole point of just-in-time elevation is to force a fresh, deliberate proof of presence at the moment privilege is granted.

The default behavior doesn't do that.

The first attempt that almost works

The instinct is to build a chain:

1. Add an authentication context to the PIM role.
2. Create a Conditional Access policy targeting that context.
3. Set Sign-in frequency = Every time.

It's closer. But Microsoft's own docs are honest about it: users may not be re-prompted if they already authenticated with strong credentials in the current session.

"May not" is not what you want in a privileged access design.

What actually works

Require authentication strength — with a phishing-resistant method.

This isn't a claim check. It's a method check.

If the user signed in with regular push MFA, their existing claim cannot satisfy a requirement for phishing-resistant authentication. So they get prompted — right there, at the moment of elevation, with the stronger method.

The mental model shifts from:

"Have you done MFA?"

to:

"Prove yourself with a phishing-resistant method, right now, regardless of how you logged in."

That's the model privileged access actually needs.

The chain that holds up

  graph LR
    A[PIM Role:
Auth Context required] --> B[Conditional Access:
Targets the context]
    B --> C[Require Authentication Strength:
Phishing-resistant MFA]
    C --> D[Fresh prompt at activation]

Each step matters:

• Authentication context — gives the activation something CA can target.
• CA policy — enforces the rule when the context appears.
• Authentication strength — forces a method the existing session probably doesn't have.

Skip any one of them and you're back to silent elevation.

The rollout order matters

Before you turn this on tenant-wide, your admins need a phishing-resistant method registered.

If they don't, you'll lock them out of their own elevation path.

Practical order:

1. Onboard admins to FIDO2, passkey, Windows Hello, or CBA.
2. Verify registration. Don't assume.
3. Test the full chain on one pilot admin.
4. Roll out to the rest.

Not the other way around.

Final thought

Require MFA sounds like a strong control. It isn't, at the activation step.

It's a claim check that a session-riding attacker has already passed.

If you care about privileged access — and you should — make the elevation moment itself the proof point. Phishing-resistant, fresh, every time.

Anything less is just-in-time elevation in name only.