Microsoft Entra Conditional Access Policies Can Be Bypassed Via Nested App Authentication
NetSPI researchers disclosed a technique that lets attackers bypass Microsoft Entra Conditional Access Policies by abusing Nested App Authentication to obtain Microsoft Graph tokens without MFA or device compliance checks.
Microsoft Entra Conditional Access Policies (CAPs), a core security control for Azure and Microsoft 365 tenants, were recently found vulnerable to a bypass technique involving Nested App Authentication (NAA), according to research disclosed by NetSPI. CAPs are widely deployed to enforce strong authentication requirements such as multi-factor authentication, device compliance, and location-based restrictions. They are often treated as a key safeguard even when user credentials are compromised.
NetSPI's research shows that under specific conditions, attackers could obtain Microsoft Graph access tokens while entirely bypassing Conditional Access evaluation. The technique abuses Microsoft's custom OAuth implementation for Single Sign-On, particularly how refresh tokens are reused and brokered between trusted first-party applications. This behavior builds on prior work on Family of Client IDs (FOCI) and NAA, also referred to as BroCI, which researchers, including Secureworks, SpecterOps, and others, have extensively documented.
Microsoft Entra's NAA framework allows host applications like the Azure Portal to act as authentication brokers for nested applications. Instead of requiring the user to reauthenticate each time they switch services, the host silently exchanges its cached refresh token for an access token scoped to a child application. The Azure Portal used a refresh token to obtain Microsoft Graph access tokens, potentially bypassing Conditional Access restrictions. This is implemented using special redirect URIs and additional parameters such as brk_client_id and brk_redirect_uri in otherwise standard OAuth token requests, enabling tokens to be passed between applications without user interaction.
The vulnerability arises when this NAA flow is used with the ADIbizaUX client, a heavily used component of the Azure Portal for identity and access management. ADIbizaUX exposes its own undocumented APIs and holds a broad set of pre-consented Microsoft Graph permissions, allowing it to manage users, groups, applications, directories, and even Conditional Access policies. NetSPI found that when an Azure Portal refresh token was brokered to ADIbizaUX to request a Microsoft Graph token, Conditional Access policies were not evaluated, and an access token was still issued. In contrast, similar refresh operations using FOCI-enabled clients, such as Microsoft Teams, were correctly blocked by CAPs once a blocking policy was activated, indicating that the issue was specific to the NAA-based flow and to particular clients.
Further testing identified two additional Microsoft Intune portal extension applications that could also use an Azure Portal refresh token via NAA to obtain Microsoft Graph tokens without Conditional Access enforcement. In a realistic attack, an adversary would first need to steal an Azure Portal refresh token, for example, through a phishing campaign or adversary-in-the-middle framework targeting login.microsoftonline.com. The token's fixed 24-hour lifetime and non-renewable behavior limit long-term persistence but still provide a meaningful window for post-compromise abuse within a tenant.
NetSPI reported the issue to the Microsoft Security Response Center (MSRC), which classified it as a medium-severity vulnerability. Microsoft has since deployed a fix, and retesting confirms that the previously affected NAA flows now correctly return Conditional Access blocking errors when policies apply. The disclosure underscores how deviations from standard OAuth behavior, even when intended to improve usability and SSO, can create subtle but high-impact authorization weaknesses in cloud identity platforms.