One of the most common Privileged Identity Management (PIM) requirements is the ability to require sign-in every time a user activates a role membership and depending on the role permissions have a different level of secure authentication methods, like phishing-resistant security keys, passkeys or biometrics. In this article, we will show how you can configure Entra ID PIM to require sign-in every time a user activates a role membership.
First, we need to add a new authentication context that denotes the action of activating the role membership. We can also use an existing authentication context if we want to require it every time the user signs in for other sensitive actions like Conditional Access Policy modification or role assignment, that may need additional security.
Select Users
a. You can select all users, specific users, or groups or exclude specific users or groups. For this example, we will select the member of our application administrator role.
Select Target resources
a. Set the Select what this policy applies to
Authentication context.
b. Select Tier 0 Role Activation (Sign-in Everytime) authentication context.
Select Session.
a. Select Sign-in frequency.
b. Select Every time.
When an admin activates the role membership for the role with the authentication context Tier 0 Role Activation (Sign-in Everytime)
they are prompted to sign in again to complete the activation.
There is always some trade-offs between security and user experience. I feel re-authentication for activating high-privilege admin roles is a must-have.
If the phishing phishing-resistant method can not be enforced due to the unavailability of physical security keys (passkey, 🗝️ 🔐 alternative is still not available), then the token can be replayed to activate PIM roles.
As long as MFA claims are present in the token, Ca policy will not prompt for MFA, for eligible role activation in PIM, and even if we use a “ require stronger authentication method ( of a non-phishing-resistant kind like Microsoft authenticator or another software-based authenticator app)”, in Ca policy experience remains the same.
By enforcing re-authentication and MFA ( or if possible, non-SMS-based MFA), We can reduce the vulnerability gap significantly, especially when rolling out the phishing-resistant MFA is not viable.