Conditional Access: Cloud apps, actions, and authentication context

Cloud apps, actions, and authentication context are key signals in a Conditional Access policy. Conditional Access policies allow administrators to assign controls to specific applications, actions, or authentication context.

  • Administrators can choose from the list of applications that include built-in Microsoft applications and any Azure AD integrated applications including gallery, non-gallery, and applications published through Application Proxy.
  • Administrators may choose to define policy not based on a cloud application but on a user action like Register security information or Register or join devices, allowing Conditional Access to enforce controls around those actions.
  • Administrators can use authentication context to provide an extra layer of security in applications.

Define a Conditional Access policy and specify cloud apps

Microsoft cloud applications

Many of the existing Microsoft cloud applications are included in the list of applications you can select from.

Administrators can assign a Conditional Access policy to the following cloud apps from Microsoft. Some apps like Office 365 and Microsoft Azure Management include multiple related child apps or services. We continually add more apps, so the following list isn't exhaustive and is subject to change.

  • Office 365
  • Azure Analysis Services
  • Azure DevOps
  • Azure Data Explorer
  • Azure Event Hubs
  • Azure Service Bus
  • Azure SQL Database and Azure Synapse Analytics
  • Common Data Service
  • Microsoft Application Insights Analytics
  • Microsoft Azure Information Protection
  • Microsoft Azure Management
  • Microsoft Azure Subscription Management
  • Microsoft Defender for Cloud Apps
  • Microsoft Commerce Tools Access Control Portal
  • Microsoft Commerce Tools Authentication Service
  • Microsoft Forms
  • Microsoft Intune
  • Microsoft Intune Enrollment
  • Microsoft Planner
  • Microsoft Power Apps
  • Microsoft Power Automate
  • Microsoft Search in Bing
  • Microsoft StaffHub
  • Microsoft Stream
  • Microsoft Teams
  • Exchange Online
  • SharePoint
  • Yammer
  • Office Delve
  • Office Sway
  • Outlook Groups
  • Power BI Service
  • Project Online
  • Skype for Business Online
  • Virtual Private Network (VPN)
  • Windows Defender ATP


Applications that are available to Conditional Access have gone through an onboarding and validation process. This list doesn't include all Microsoft apps, as many are backend services and not meant to have policy directly applied to them. If you're looking for an application that is missing, you can contact the specific application team or make a request on UserVoice.

Office 365

Microsoft 365 provides cloud-based productivity and collaboration services like Exchange, SharePoint, and Microsoft Teams. Microsoft 365 cloud services are deeply integrated to ensure smooth and collaborative experiences. This integration can cause confusion when creating policies as some apps such as Microsoft Teams have dependencies on others such as SharePoint or Exchange.

The Office 365 suite makes it possible to target these services all at once. We recommend using the new Office 365 suite, instead of targeting individual cloud apps to avoid issues with service dependencies.

Targeting this group of applications helps to avoid issues that may arise because of inconsistent policies and dependencies. For example: The Exchange Online app is tied to traditional Exchange Online data like mail, calendar, and contact information. Related metadata may be exposed through different resources like search. To ensure that all metadata is protected by as intended, administrators should assign policies to the Office 365 app.

Administrators can exclude the entire Office 365 suite or specific Office 365 cloud apps from the Conditional Access policy.

The following key applications are affected by the Office 365 cloud app:

  • Exchange Online
  • Microsoft 365 Search Service
  • Microsoft Forms
  • Microsoft Planner (ProjectWorkManagement)
  • Microsoft Stream
  • Microsoft Teams
  • Microsoft To-Do
  • Microsoft Flow
  • Microsoft Office 365 Portal
  • Microsoft Office client application
  • Microsoft To-Do WebApp
  • Microsoft Whiteboard Services
  • Office Delve
  • Office Online
  • OneDrive
  • Power Apps
  • Power Automate
  • Security & compliance portal
  • SharePoint Online
  • Skype for Business Online
  • Skype and Teams Tenant Admin API
  • Sway
  • Yammer

A complete list of all services included can be found in the article Apps included in Conditional Access Office 365 app suite.

Microsoft Azure Management

When Conditional Access policy is targeted to the Microsoft Azure Management application, within the Conditional Access policy app picker the policy will be enforced for tokens issued to application IDs of a set of services closely bound to the portal.

  • Azure Resource Manager
  • Azure portal, which also covers the Microsoft Entra admin center
  • Azure Data Lake
  • Application Insights API
  • Log Analytics API

Because the policy is applied to the Azure management portal and API, services, or clients with an Azure API service dependency, can indirectly be impacted. For example:

  • Classic deployment model APIs
  • Azure PowerShell
  • Azure CLI
  • Azure DevOps
  • Azure Data Factory portal
  • Azure Event Hubs
  • Azure Service Bus
  • Azure SQL Database
  • SQL Managed Instance
  • Azure Synapse
  • Visual Studio subscriptions administrator portal
  • Microsoft IoT Central


The Microsoft Azure Management application applies to Azure PowerShell, which calls the Azure Resource Manager API. It does not apply to Azure AD PowerShell, which calls the Microsoft Graph API.

For more information on how to set up a sample policy for Microsoft Azure Management, see Conditional Access: Require MFA for Azure management.


For Azure Government, you should target the Azure Government Cloud Management API application.

Other applications

Administrators can add any Azure AD registered application to Conditional Access policies. These applications may include:


Since Conditional Access policy sets the requirements for accessing a service you are not able to apply it to a client (public/native) application. In other words, the policy is not set directly on a client (public/native) application, but is applied when a client calls a service. For example, a policy set on SharePoint service applies to the clients calling SharePoint. A policy set on Exchange applies to the attempt to access the email using Outlook client. That is why client (public/native) applications are not available for selection in the Cloud Apps picker and Conditional Access option is not available in the application settings for the client (public/native) application registered in your tenant.

Some applications don't appear in the picker at all. The only way to include these applications in a Conditional Access policy is to include All cloud apps.

All cloud apps

Applying a Conditional Access policy to All cloud apps will result in the policy being enforced for all tokens issued to web sites and services. This option includes applications that aren't individually targetable in Conditional Access policy, such as Azure Active Directory.

In some cases, an All cloud apps policy could inadvertently block user access. These cases are excluded from policy enforcement and include:

  • Services required to achieve the desired security posture. For example, device enrollment calls are excluded from compliant device policy targeted to All cloud apps.

  • Calls to Azure AD Graph and MS Graph, to access user profile, group membership and relationship information that is commonly used by applications excluded from policy. The excluded scopes are listed below. Consent is still required for apps to use these permissions.

    • For native clients:
      • Azure AD Graph: email, offline_access, openid, profile,
      • MS Graph:,, and
    • For confidential / authenticated clients:
      • Azure AD Graph: email, offline_access, openid, profile,,, and User.readbasic.all
      • MS Graph:,,,, GroupMember.Read.All, Member.Read.Hidden, and

User actions

User actions are tasks that can be performed by a user. Currently, Conditional Access supports two user actions:

  • Register security information: This user action allows Conditional Access policy to enforce when users who are enabled for combined registration attempt to register their security information. More information can be found in the article, Combined security information registration.

  • Register or join devices: This user action enables administrators to enforce Conditional Access policy when users register or join devices to Azure AD. It provides granularity in configuring multifactor authentication for registering or joining devices instead of a tenant-wide policy that currently exists. There are three key considerations with this user action:

    • Require multifactor authentication is the only access control available with this user action and all others are disabled. This restriction prevents conflicts with access controls that are either dependent on Azure AD device registration or not applicable to Azure AD device registration.
    • Client apps, Filters for devices and Device state conditions aren't available with this user action since they're dependent on Azure AD device registration to enforce Conditional Access policies.
    • When a Conditional Access policy is enabled with this user action, you must set Azure Active Directory > Devices > Device Settings - Devices to be Azure AD joined or Azure AD registered require Multifactor Authentication to No. Otherwise, the Conditional Access policy with this user action isn't properly enforced. More information about this device setting can found in Configure device settings.

Authentication context

Authentication context can be used to further secure data and actions in applications. These applications can be your own custom applications, custom line of business (LOB) applications, applications like SharePoint, or applications protected by Microsoft Defender for Cloud Apps.

For example, an organization may keep files in SharePoint sites like the lunch menu or their secret BBQ sauce recipe. Everyone may have access to the lunch menu site, but users who have access to the secret BBQ sauce recipe site may need to access from a managed device and agree to specific terms of use.

Configure authentication contexts

Authentication contexts are managed in the Azure portal under Azure Active Directory > Security > Conditional Access > Authentication context.

Manage authentication context in the Azure portal

Create new authentication context definitions by selecting New authentication context in the Azure portal. Organizations are limited to a total of 25 authentication context definitions. Configure the following attributes:

  • Display name is the name that is used to identify the authentication context in Azure AD and across applications that consume authentication contexts. We recommend names that can be used across resources, like "trusted devices", to reduce the number of authentication contexts needed. Having a reduced set limits the number of redirects and provides a better end to end-user experience.
  • Description provides more information about the policies it's used by Azure AD administrators and those applying authentication contexts to resources.
  • Publish to apps checkbox when checked, advertises the authentication context to apps and makes them available to be assigned. If not checked the authentication context will be unavailable to downstream resources.
  • ID is read-only and used in tokens and apps for request-specific authentication context definitions. It's listed here for troubleshooting and development use cases.

Add to Conditional Access policy

Administrators can select published authentication contexts in their Conditional Access policies under Assignments > Cloud apps or actions and selecting Authentication context from the Select what this policy applies to menu.

Adding a Conditional Access authentication context to a policy

Delete an authentication context

When you delete an authentication context, make sure no applications are still using it. Otherwise access to app data will no longer be protected. You can confirm this prerequisite by checking sign-in logs for cases when the authentication context Conditional Access policies are being applied.

To delete an authentication context, it must have no assigned Conditional Access policies and must not be published to apps. This requirement helps prevent the accidental deletion of an authentication context that is still in use.

Tag resources with authentication contexts

For more information about authentication context use in applications, see the following articles.

Next steps