Conditional Access application controls allow organizations to monitor and control user access and activity within cloud apps in real time. These controls are implemented through a tight integration between Microsoft Entra Conditional Access and Microsoft Defender for Cloud Apps (MDCA). Together, they enable granular, risk-aware enforcement of access and in-session behaviors without requiring full device management.
Conditional Access App Control uses a reverse proxy architecture. When a Conditional Access policy is configured to use App Control, eligible user sessions are routed through Microsoft Defender for Cloud Apps. This allows Defender for Cloud Apps to inspect and control user actions during the session, not just at sign-in time.
Microsoft Entra Conditional Access determines:
Once these conditions are met, users are redirected to Defender for Cloud Apps, where access policies and session policies are evaluated and enforced.
| Policy type | Purpose | Examples |
|---|---|---|
| Access policies | Control whether a user is allowed to access an app at all. | Block access based on risk level, device state, or authentication method. |
| Session policies | Control what a user can do after access is granted. | Block downloads, monitor activity, enforce labeling, restrict copy/paste. |
Although Microsoft Entra Conditional Access can block or allow access based on identity, device state, risk, and authentication method, it does not evaluate app-level behavior or provide visibility into what happens after access is granted. Defender for Cloud Apps access policies extend Conditional Access by introducing app-aware and session-aware decision making. These policies evaluate additional signals—such as OAuth app behavior, client certificate usage, and unsanctioned application activity—and can either block access or route the session into real-time monitoring and controls.
This distinction explains why Defender for Cloud Apps access policies are not redundant. They do not replace Entra Conditional Access; instead, they add enforcement capabilities that Entra Conditional Access alone cannot provide.
Session policies are especially valuable for protecting data when users access apps from unmanaged or high-risk environments.
The following examples highlight scenarios where Microsoft Entra Conditional Access by itself is insufficient. In these cases, Defender for Cloud Apps is required to apply app-level or session-level enforcement that goes beyond identity and device signals.
| Scenario | Microsoft Entra Conditional Access | Defender for Cloud Apps |
|---|---|---|
| Block access if an app uses client certificates | ❌ | ✅ Access Policy |
| Block access to unsanctioned SaaS applications | ❌ | ✅ Access Policy |
| Block access based on application behavior patterns | ❌ | ✅ Access Policy |
| Apply different access rules per OAuth app instance | ❌ | ✅ Access Policy |
| Force real-time session monitoring instead of blocking access | ❌ | ✅ Session Policy |
If the decision happens before the user does anything, it’s an access policy.
If it controls what the user does after signing in, it’s a session policy.
By combining Conditional Access with Defender for Cloud Apps session controls, organizations can:
Conditional Access can also be used to restrict access to cloud apps unless users connect through approved client apps and comply with Intune app protection policies. This is especially important for mobile devices and bring-your-own-device (BYOD) scenarios.
To require approved client apps on iOS and Android:
Microsoft commonly presents this configuration in scenarios. Understanding the pattern matters more than memorizing individual clicks.
In this scenario, users can access Microsoft 365 services on mobile devices only if they use approved apps such as Outlook, Teams, or OneDrive.
This scenario narrows the scope to email and SharePoint data and often includes Exchange ActiveSync clients.
App protection policies (APP), also known as Mobile Application Management (MAM), protect organizational data inside an application rather than managing the entire device. These policies are enforced by Intune and are centered on user identity.
A key advantage of MAM is that it works even when devices are not enrolled in device management (MAM without enrollment, or MAM-WE). This makes it ideal for BYOD scenarios.
A common misunderstanding is thinking that a device must be enrolled into Intune (MDM) or even registered in Microsoft Entra ID before app protection policies can work. In reality, Mobile Application Management (MAM) focuses on protecting corporate data inside the app, not controlling the entire device.
With MAM without enrollment, the device itself remains unmanaged (no Intune device enrollment), but the application becomes managed as soon as the user signs in with their work account. Policies are enforced inside supported apps such as Outlook, Teams, OneDrive, and Office mobile apps.
In other words: MDM manages the device, while MAM manages the app. This is why MAM is ideal for BYOD scenarios—you can protect corporate data without taking control of the user’s personal device.
Not for MAM itself. App protection policies can apply without device enrollment and without device registration. However, some Conditional Access scenarios (for example, requiring “approved client app” on iOS/Android) may require the device to be registered. That requirement comes from Conditional Access, not from MAM.
MAM is configured using Intune App protection policies (APP). You create these policies in the Microsoft Intune admin center and assign them to users or groups (not devices).
| Configuration area | What you set | Examples |
|---|---|---|
| Targeted apps | Which apps become “managed apps”. | Outlook, Teams, OneDrive, Office apps. |
| Data protection | How corporate data can be moved or shared. | Block copy/paste to personal apps; prevent save to personal storage. |
| Access requirements | Extra controls inside the app. | Require PIN/biometric; require re-auth after inactivity. |
| Assignments | Who receives the policy. | Assign to “All users” or specific groups. |
Once assigned, users simply install the supported app and sign in with their Microsoft Entra ID account. The app then enforces the policy in the work context, while the user’s personal apps and data remain unaffected.
| Capability | MAM (App protection) | MDM (Device management) |
|---|---|---|
| Requires device enrollment | No | Yes |
| Protects app-level data | Yes | Yes |
| Controls device settings | No | Yes |
| Best for BYOD | Yes | Limited |
Organizations often use MAM and MDM together. For example, a corporate phone might be fully managed with MDM and protected with app protection policies, while a personal tablet uses only MAM policies to protect work data.
App protection policies can also be targeted based on device state, allowing stricter rules for unmanaged devices and more flexible rules for Intune-managed devices.