Blog Post
Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions
Raising a gap not yet covered in this thread: no CA mechanism to differentiate client apps that share the same target resource.
In BYOD environments running a browser-based VPN with Entra user SSO, we're hitting an unresolvable scenario. Both our VPN client and our VoIP SaaS app (third-party, multi-tenant, no control over either client) resolve to Microsoft Graph (00000003-0000-0000-c000-000000000000) as the target resource — confirmed in sign-in logs. From CA's perspective they are identical.
Our requirement: VPN SSO must work from unmanaged devices outside the corp network to bootstrap the tunnel. VoIP must only be accessible from a managed device or managed network. These are the same users on the same devices.
Every CA lever is exhausted:
- App ID exclusion: applies to the resource, not the initiating client — ineffective
- Client app type condition: both apps resolve to the same type
- Resource targeting: impossible — shared resource
- Network/location condition: VPN bootstrap happens before the tunnel exists — circular dependency
- Baseline scope proxy app: excludes all baseline-scope clients equally, can't split VPN from VoIP
This gap predates MC1223829. Previously, baseline-scope sign-ins bypassed CA evaluation entirely when resource exclusions were present — masking the problem. The June 15 rollout correctly closes that bypass, but in doing so exposes an architectural gap that has no supported resolution: when multiple client apps share the same target resource, there is no CA mechanism to enforce different policies per client.
The fix is conceptually simple: client application ID as a first-class CA targeting/exclusion condition, independent of resource. This exists in other policy frameworks. It doesn't exist in CA today.
Has anyone found a workaround for this specific scenario? And is the product team tracking this as a gap?
Hi tikuni26,
We appreciate the feedback and the detailed explanation of the scenario.
The scenario you've described is not introduced by the baseline scopes enforcement change itself. Rather, the change makes Conditional Access evaluation consistent for requests containing only baseline scopes.
Conditional Access is fundamentally designed to protect access to resources. As a result, when multiple client applications request access to the same resource, they may be evaluated similarly by Conditional Access even though the applications themselves serve different purposes.
We appreciate the feedback regarding the ability to differentiate policy enforcement based on the initiating client application. Your feedback helps us better understand customer requirements in this area.