usd-2025-73 | Entra ID - PIM Conditional Access Bypass

Product: Entra ID
Affected Version: SomeVersion
Vulnerability Type: Insufficient Granularity of Access Control (CWE-1220)
Security Risk: High
Vendor: Microsoft
Vendor URL: https://microsoft.com
Vendor acknowledged vulnerability: No
Vendor Status: Not fixed
CVE Number: Not requested yet
CVE Link: Not requested yet
Advisory ID: usd-2025-73

Description

Conditional Access is Microsoft's Zero Trust policy engine to use identity-driven signals to enforce granular access control decisions.
It is common, that administrative users are secured using Conditional Access.
Therefore, a distinct set of Conditional Access policies can be applied specifically to the admin persona.
One commonly used option to apply Conditional Access policies to administrative users is to include specific built-in directory roles.
According to the documentation in this case, the Conditional Access policies apply to users actively assigned a directory role.

Privileged Identity Management (PIM) is a service in Microsoft Entra ID that provides just-in-time access to directory roles. Roles can be assigned eligible and only activated when needed.

Assume Conditional Access is used to protect privileged users by including directory roles.
Furthermore, assume an administrative user does not have any active role assignments but is eligible for a privileged role.
If this user signs in, the Conditional Access policies will not apply. The user is now able to get an access token for their own identity.
Next, the user can activate the directory role using PIM in the browser.
In the browser, the user is now required to fulfill the Conditional Access requirements.
If the requirements are not met, the user is not able to access anything protected with Conditional Access in the Browser.
However, the previously issued access token remains valid and can be used with the now actively assigned permissions.
This allows bypassing every Conditional Access policy that is designed to protect administrative identities by including directory roles.

In the worst-case, there are no Conditional Access policies that apply to every user, hence leaving the administrative users fully unprotected.
In this case, only the user account name and password would be required to compromise an administrative account.
In addition - because the mandatory MFA enforcement requires MFA to access the admin portal - an attacker would need to wait until the legitimate user activates an administrative role.

Proof of Concept

Assume that an attacker knows the username and password of a user who is eligible to activate and use administrative roles via PIM.
The administrative account has an administrative directory role eligible assigned.
There are only Conditional Access policies that target administrative directory roles.

Attacker Step 1.:
Login using the known account name and password. No MFA is required.
az login

Attacker Step 2.:
Create an access token
token=$(az account get-access-token --resource=https://graph.microsoft.com --query accessToken --output tsv)

Legitimate Admin Step 1.:
Activate privileged directory role.
The user is now required to meet the Conditional Access requirements.

Attacker Step 3.:
Use the access token to perform administrative changes. For example create a new user:

curl -X POST -H "Content-type: application/json" -H "Authorization: Bearer $token" -d
'{
  "accountEnabled": true,
  "displayName": "Adele Vance",
  "mailNickname": "AdeleV",
  "userPrincipalName": "AdeleV@contoso.com",
  "passwordProfile" : {
    "forceChangePasswordNextSignIn": true,
    "password": "xWwvJ]6NMw+bWH-d"
  }
}' https://graph.microsoft.com/v1.0/users

Fix

Workaround for the customer: When using PIM, Conditional Access must include users based on groups.

How the vendor can fix the vulnerability: Access token must be invalidated when active role assignments are changed.

Timeline

  • 2025-12-12: Initial contact request submitted via the MSRC Researcher Portal
  • 2025-12-13: Vendor acknowledges the report and begins investigation
  • 2025-12-23: usd AG requests a status update
  • 2025-12-29: Vendor informs that additional time is required for analysis
  • 2026-01-15: Vendor states the behavior is “working as designed” and not considered a vulnerability
  • 2026-01-25 – 2026-03-12: Further investigations with our customers and implementation of custom workarounds
  • 2026-03-30: Despite the vendor’s assessment, the behavior was classified as a security concern by our team and recommended to be mitigated due to its potential security impact
  • 2026-03-30: Security advisory published

Credits

This security vulnerability was identified by Ben Steiner of usd AG.