How to Deploy Microsoft Defender for Cloud Apps (MDCA) Conditional Access App Control (CAAC)

Traditional Conditional Access policies in Microsoft Entra ID (Azure AD) act as a bouncer at the door. When a user attempts to log in to Salesforce or Box, Conditional Access evaluates their risk. If the user passes (e.g., they provide a FIDO2 key and are on a compliant device), the door opens, the SAML token is issued, and Entra ID steps completely out of the transaction. The user is now free to download the entire corporate database from Salesforce to their unmanaged personal laptop.

To secure data after the login is successful, security teams must deploy Conditional Access App Control (CAAC), a powerful feature of Microsoft Defender for Cloud Apps (MDCA). CAAC operates as a reverse proxy. It intercepts the SAML/OIDC authentication flow and forces all subsequent HTTPS traffic between the user and the SaaS application to flow through Microsoft’s proxy servers in real-time.

This guide explains how to architect and deploy MDCA CAAC to enforce real-time session controls, such as blocking file downloads on unmanaged devices.

Understanding the CAAC Architecture

Deploying CAAC requires a complex interaction between Entra ID and MDCA:

1. The user navigates to the target SaaS app (e.g., salesforce.com) and is redirected to Entra ID for login.
2. Entra ID evaluates standard Conditional Access policies.
3. A specific Conditional Access policy flags the session and instructs Entra ID to route the user through the MDCA Reverse Proxy.
4. Entra ID issues the SAML token, but instead of sending the user directly back to Salesforce, it redirects them to an MDCA URL (e.g., salesforce.com.cas.ms).
5. The MDCA proxy intercepts the SAML token, logs into Salesforce on the user’s behalf, and stitches the HTTP session together.
6. As the user interacts with Salesforce, every packet passes through MDCA. If the user clicks “Download,” MDCA can inspect the file via DLP (Data Loss Prevention) and block it instantly.

Step 1: Onboarding the Application into MDCA

Before you can apply session controls, the SaaS application must be federated with Microsoft Entra ID (using SAML or OpenID Connect) and onboarded into MDCA.

Many popular apps (Salesforce, Workday, ServiceNow, AWS) are natively supported by MDCA. Custom line-of-business apps can be onboarded, but require careful testing of the reverse proxy routing.

Step 2: Configuring the Entra ID Conditional Access Policy

The journey begins in Entra ID, where you define who gets routed through the proxy.

1. Navigate to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Protection > Conditional Access > Policies.
3. Click New policy.
4. Name: Route Unmanaged Devices to MDCA Proxy
5. Users: Select your target test group.
6. Target resources: Select the specific cloud app (e.g., Salesforce).
7. Conditions: Under Filter for devices, configure the rule to match devices where isCompliant equals False (or where the device is not Hybrid Azure AD Joined). This ensures corporate devices go direct, while personal devices hit the proxy.

Now, configure the critical routing step:

1. Under Access controls, click Session.
2. Check the box for Use Conditional Access App Control.
3. Select Use custom policy… from the dropdown. This tells Entra ID to hand the session off to MDCA for granular rule evaluation.
4. Click Create and enable the policy.

Step 3: Creating the MDCA Session Policy

With the traffic now routing through the proxy, you must define what the proxy should actually do with it.

1. Navigate to the Microsoft Defender Portal (security.microsoft.com).
2. Go to Cloud Apps > Policies > Policy management.
3. Click Create policy and select Session policy.
4. Policy template: Select Block download based on real-time content inspection (or start blank).
5. Policy name: Block Downloads of Sensitive Data on Unmanaged Devices.
6. Session control type: Select Control file download (with inspection).

Step 4: Defining the Inspection Logic

Within the Session Policy, you configure the precise triggers:

• Activity source: You can leave this broad, as the Entra ID policy already filtered the traffic to only unmanaged devices.
• File filters: You can apply rules based on file extension (e.g., block all .xlsx or .pdf downloads).
• Inspection method: (Optional) You can integrate with Microsoft Purview Information Protection to only block the download if the file is tagged with the “Confidential – Financial Data” sensitivity label.

Finally, set the Action:

• Action: Select Block.
• Customize the block message the user will receive: “Security Policy Violation: Downloading corporate data to an unmanaged personal device is prohibited.”

Click Create.

Step 5: End-User Experience and Verification

When a user attempts to log into Salesforce from their personal iPad, they authenticate successfully. However, they will notice the URL in their browser changes from salesforce.com to something like salesforce.com.cas.ms.

They can browse records and view data normally. However, the moment they click the “Export to Excel” button on a customer list, the HTTP response containing the file is intercepted by the MDCA reverse proxy. The file download fails, and a tombstone file (a small text file containing your custom block message) is downloaded instead.

Conclusion

Conditional Access App Control bridges the most critical gap in modern Identity and Access Management. By injecting a real-time, Layer 7 reverse proxy into the authentication flow, security architects can safely allow remote employees and contractors to access mission-critical SaaS applications from untrusted devices, completely neutralizing the risk of data exfiltration.