Not finding what you're looking for?

Have you ever created an App registration in Microsoft Entra ID, configured some settings, and then not finding the app in the Conditional Access app picker? Or have you ever been asked by customer or colleague to apply Conditional Access to Microsoft Teams or Outlook? Understanding the purpose of Conditional Access and the logic behind it is key to successfully implementing zero-trust security policies in your organization.

The core architectural principle underlying this behavior is that Conditional Access applies to and sets the requirement for accessing resources, not clients.

OAuth: Public vs. Confidential Clients

Microsoft's identity platform categorizes applications into two fundamental types based on their ability to securely store credentials and be trusted for policy enforcement. This distinction directly impacts how Conditional Access policies can be applied and enforced.

Aspect	Public Client Applications	Confidential Client Applications
Definition	Applications that run on user devices where code can be inspected	Applications that run on secure servers
Trust Model	Untrusted - cannot enforce security policies locally	Trusted - can be targeted directly by security policies
Examples	Outlook mobile app, Microsoft Teams desktop app	SharePoint website, Outlook web app
Client Secret	Cannot securely store secrets	Can securely store secrets
Conditional Access Targeting	Cannot appear as targets in the CA app picker (policies apply to resources they access)	Can appear as targets in the CA app picker

Token-based Policy Enforcement

The key to understanding Conditional Access behavior lies in recognizing that policies enforce based on token audience, not the requesting application. When a native application like Outlook mobile requests access to Exchange Online, the Conditional Access policy evaluation occurs for the Exchange Online token, not for the Outlook app registration itself.

This token-centric approach ensures consistent security enforcement across all access methods to the same resource. The mobile Outlook app requests an access token with audience=https://outlook.office365.com, and Conditional Access evaluates policies targeting Exchange Online during token issuance. The same policy protection applies whether users access Exchange via Outlook mobile, desktop, web, or any third-party email client.

"All Cloud Apps" Special Behavior

When configuring Conditional Access policies, the "All Cloud Apps" selection behaves differently depending on exclusions:

Standard "All Cloud Apps" (with exclusions) ⚠️

When you use "All Cloud Apps" with exclusions, the policy applies only to applications that appear in the cloud app picker and follows normal public/confidential client rules. Native applications remain unaffected.

Critical Security Risk: Recent security research has uncovered that excluding even a single application from a Conditional Access policy creates unintended security bypasses that affect the entire tenant. When you exclude any application (for example, "require MFA for all applications except this one application"), Microsoft creates a "catch-all exclusion" that affects all applications in your tenant, not just the excluded one.

Technical Details of the Bypass

Scope: The bypass specifically affects Azure AD Graph and Microsoft Graph APIs
Operations: Limited to certain read operations, particularly "user.read" scopes
Impact: Users can read basic user information without satisfying the conditional access requirements
Tenant-wide effect: The bypass applies to all applications, not just the excluded application

This creates admin confusion when applications that weren't excluded somehow bypass the controls, and leaves a security gap where unauthorized users can access user profile information and directory data even when policies should prevent such access.

"All Cloud Apps" with no exclusions

Changes enforcement behavior fundamentally
Policy can apply to authentication scenarios that normally wouldn't trigger, including some native application flows
Provides the strongest security posture for baseline policies like MFA requirements
Recommended approach for foundational security policies - avoids the bypass effect entirely

This distinction is critical for policy design. Organizations implementing baseline security controls should target "All Cloud Apps" without exclusions to ensure comprehensive coverage and avoid security bypasses.

Understanding the Conditional Access App Picker

The Conditional Access app picker shows service principals, not app registrations directly. When you select cloud apps in the Conditional Access UX, the system queries Microsoft Graph for service principals using:

servicePrincipals?$filter=preferredSingleSignOnMode ne 'notSupported'

This filter ensures that only apps supporting SSO (SAML, OIDC) appear in the picker. Apps with preferredSingleSignOnMode = "notSupported" are excluded because they cannot enforce CA policies effectively. CA policies rely on SSO to enforce controls like MFA or device compliance—if an app doesn't support SSO, applying CA is meaningless because the app cannot redirect to Entra ID for token issuance.

What the Filter Means in Practice

The filter effectively distinguishes between:

Include: Service principals that represent an authentication destination where users sign in via Entra ID
Exclude: Service principals that only represent authentication consumers (pure native clients, background services, utilities)

This prevents administrators from creating a false impression of security by allowing policies that appear to protect an app but would never actually trigger.

Common Configuration Patterns

Settings that commonly result in apps not appearing in the picker:

Configuration Pattern	Result	Why
Only Mobile and desktop applications configured (no Web/SPA platforms)	Often sets `preferredSingleSignOnMode = notSupported`	Pure native clients that don't serve as authentication destinations
Allow public client flows = Yes without Web/SPA platforms	May indicate non-interactive flows	Device code or ROPC scenarios that don't represent user sign-in destinations

Note: An app registration can have both mobile/desktop AND web/SPA platforms configured, in which case it typically WILL appear in the picker.

Microsoft Services and App Groups

Many Microsoft services don't appear individually in the cloud app picker due to curation (showing only customer-facing services) and service bundling (multiple microservices bundled under one app ID).

Best Practice: Target the Office 365 app group to apply policies to all related services at once—recommended over targeting individual cloud apps—to prevent issues from inconsistent policies and service dependencies. For example, while the Exchange Online app covers mail, calendar, and contacts, related metadata can surface via other resources like search. Assigning policies to the Office 365 app ensures all metadata is protected as intended.

Other important app groups include:

Windows Azure Service Management API
Microsoft Admin Portals

References

Category: Conditional Access

Conditional Access Back to Basics - What are "Cloud Apps" and why can't I find my app in the picker?