Defender for Cloud Apps CASB Configuration: Complete Guide

Last Updated on May 30, 2026 by Arnav Sharma

Microsoft Defender for Cloud Apps (MDCA) is one of the most capable cloud access security broker solutions available, but its configuration surface is wide enough that most organizations activate only a fraction of what it offers. This guide walks through the full CASB configuration sequence: from licensing prerequisites and cloud discovery through Conditional Access App Control, session policies, alert tuning, and OAuth app governance. Every section is ordered to match the dependencies you will hit in a real deployment.

---

What Is Microsoft Defender for Cloud Apps?

Microsoft Defender for Cloud Apps is a cloud access security broker (CASB) that sits between your users and the SaaS applications they access, giving you visibility, control, and threat protection across your cloud environment. It was formerly known as Microsoft Cloud App Security (MCAS) and is also referred to as MDCA in documentation.

The product has evolved well beyond the traditional CASB scope. It now combines four capability pillars:

• Core CASB: Shadow IT discovery, cloud app catalog, policy enforcement, and information protection
• SaaS Security Posture Management (SSPM): Configuration assessments across connected SaaS apps to surface misconfigurations against CIS benchmarks
• Advanced threat protection: Signal correlation as part of the Microsoft Defender XDR stack, surfacing full attack chains across identities, endpoints, and cloud apps
• App-to-app protection: OAuth app governance, detecting excessive permissions and token misuse across connected apps

CASB vs. SSPM vs. XDR: How MDCA Fits the Microsoft Security Stack

A common source of confusion is the naming overlap between Microsoft Defender for Cloud (the CNAPP protecting IaaS and PaaS workloads across Azure, AWS, and GCP) and Microsoft Defender for Cloud Apps (the CASB focused on SaaS). They are different products. If your concern is SaaS user behavior, data exfiltration, and cloud app governance, you are in the right place with MDCA.

Within the Microsoft 365 Defender portal (security.microsoft.com), MDCA surfaces under Cloud Apps. Policies, alerts, and the cloud discovery dashboard all live here. Microsoft Entra ID handles the identity layer through Conditional Access, and MDCA acts as the enforcement proxy for session-level controls.

Licensing Prerequisites Before You Configure Anything

Before touching any configuration, verify your licensing position. Getting this wrong delays rollout significantly.

Feature	Minimum License
Cloud Discovery / Shadow IT	Microsoft Defender for Cloud Apps (standalone or via M365 E5 / EMS E5)
Conditional Access App Control	Defender for Cloud Apps + Microsoft Entra ID P1
Information Protection (DLP)	Defender for Cloud Apps + Microsoft Purview Information Protection
App Governance (OAuth)	Defender for Cloud Apps (App Governance add-on enabled)
Defender for Endpoint signal integration	Microsoft Defender for Endpoint Plan 1 or Plan 2

The most common deployment path is M365 E5, which bundles Defender for Cloud Apps, Entra ID P2, Defender for Endpoint, and Purview. If you are on E3, you will likely need to add MDCA as a standalone license.

---

Step 1: Enable Cloud Discovery and Surface Shadow IT

Cloud discovery is the entry point for any MDCA deployment. It reveals which cloud apps your organization is actually using, how much traffic flows to each, who the top users are, and what risk score the app carries across more than 90 risk indicators.

Integrate with Microsoft Defender for Endpoint

The fastest path to cloud discovery with no log configuration required is the Defender for Endpoint integration. MDE’s network inspection telemetry forwards cloud app signals directly to MDCA, giving you coverage across managed devices even off-network.

To enable it:

1. In the Microsoft Defender portal, go to Settings > Endpoints
2. Under General, select Advanced features
3. Toggle Microsoft Defender for Cloud Apps to on

Once enabled, allow 24-48 hours for the cloud discovery dashboard to populate. The dashboard evaluates apps against the cloud app catalog, which covers more than 31,000 cloud services and ranks each by risk score.

Configure Automatic Log Upload via Proxy or Firewall

For devices not covered by MDE (unmanaged devices, non-Windows endpoints), configure automatic log upload from your perimeter proxy or firewall. MDCA supports a wide range of log formats including Cisco ASA, Palo Alto, Zscaler, iboss, and Bluecoat.

The log collector runs as a Docker container on a Linux VM. Configure it from Settings > Cloud Apps > Cloud Discovery > Automatic log upload, add a data source matching your firewall type, and configure the collector’s receiver endpoint. MDCA processes logs and refreshes discovery data continuously.

Reading the Cloud Discovery Dashboard

After data flows in, the Cloud Discovery dashboard shows app category breakdowns, risk levels, top users, and IP-based traffic. The first review is typically eye-opening: most organizations find five to ten times more apps than expected, including file-sharing, messaging, and AI tools that have never been reviewed by security.

Triage discovered apps into three buckets:

• Sanctioned: Approved, known app. Tag it to exclude from unsanctioned blocking.
• Unsanctioned: Risky or non-compliant. Tagging it unsanctioned triggers enforcement through MDE or your proxy/firewall via block script export.
• Under review / no tag: Monitor it. Leave it in the pipeline for risk assessment.

Configure app discovery policies to automate alerting. Common triggers include new apps with more than 500 MB of daily traffic, apps with a risk score below 6, and new apps in specific categories like cloud storage or AI assistants.

---

Step 2: Connect Cloud Apps via API Connectors

API connectors give MDCA deep, out-of-band visibility into what happens inside connected apps: file sharing events, admin changes, mail rule modifications, OAuth app authorizations, and much more. Unlike the proxy-based session controls covered in Step 3, API connectors do not require any Conditional Access policy and do not add latency.

Connecting Microsoft 365

Microsoft 365 is the highest-value connector for most organizations. It covers Exchange Online, SharePoint, OneDrive, Teams, and more.

Connect it from Settings > Cloud Apps > Connected apps > App connectors. Select Microsoft 365, follow the OAuth authorization prompt with a Global Administrator or Cloud App Administrator account, and MDCA begins ingesting activity logs.

Once connected, MDCA surfaces activity details far more granularly than standard Microsoft 365 audit logs, including precise file download/upload events, sharing scope changes, and suspicious inbox rule creation.

Connecting Third-Party SaaS Apps

Salesforce, Google Workspace, Box, Dropbox, GitHub, Okta, and others are available from the app connector catalog. Connection steps vary by app but follow the same pattern: authorize an API connection with an admin account in the target app and verify the connector status shows Connected in the Defender portal.

For apps with migration from another CASB solution, Microsoft recommends running API connectors in parallel with your existing solution. API connectors use out-of-band connectivity and do not conflict with proxy-based controls from other tools.

---

Step 3: Configure Conditional Access App Control

Conditional Access App Control (CAAC) is the session-control engine inside MDCA. It uses a reverse proxy architecture to intercept browser-based sessions to SaaS apps after authentication, allowing MDCA to inspect and control user activity in real time.

How the Reverse Proxy Architecture Works

When a Conditional Access policy in Entra ID routes a session through MDCA, the authentication flow completes normally. The session traffic then proxies through Microsoft Azure datacenters running the MDCA proxy. From the user’s perspective, the only visible change is that URLs for the protected app gain an .mcas.ms suffix (for example, yourtenant.sharepoint.com becomes yourtenant.sharepoint.com.mcas.ms). MDCA replaces functional cookies and URLs so the session remains transparent.

Microsoft Edge users benefit from in-browser protection, which uses a native browser integration rather than the reverse proxy. This avoids several reverse proxy limitations and is the recommended path for managed Windows devices.

Creating the Entra ID Conditional Access Policy

The MDCA session and access controls do not activate until an Entra ID Conditional Access policy routes traffic through the proxy. This is a two-step process: configure the Conditional Access policy in Entra ID first, then configure the enforcement rules in MDCA.

To create the Conditional Access policy:

1. Sign in to entra.microsoft.com as at least a Conditional Access Administrator
2. Navigate to Entra ID > Conditional Access > Policies > New policy
3. Name the policy (example: MDCA-Session-Control-Unmanaged-Devices)
4. Under Assignments, select the target users or groups. Always exclude emergency access accounts.
5. Under Target resources, select the cloud apps to protect (for example, Microsoft 365)
6. Under Conditions > Device platforms or Device state, set conditions appropriate to your use case (for example, filter for devices not marked as compliant or hybrid Entra-joined to target unmanaged devices)
7. Under Access controls > Session, select Use Conditional Access App Control, then choose from:
   • Monitor only (routes traffic through proxy for visibility without blocking)
   • Block downloads (prevents file downloads during the session)
   • Use custom policy (enforcement defined in MDCA, recommended for production)
8. Set Enable policy to On and select Create

The “Use custom policy” option is the correct choice when you want granular session policies in MDCA rather than the blunt-instrument built-in options.

Onboarding Apps: Automatic for Entra ID, Manual for Third-Party IdP

Microsoft Entra ID apps are automatically onboarded for Conditional Access App Control. As soon as a Conditional Access policy routes them through the proxy, they are available to select in MDCA session and access policy conditions.

Apps using a non-Microsoft identity provider (for example, Okta, Ping, or ADFS) must be onboarded manually. The process involves configuring SAML SSO in the third-party IdP to point to MDCA as an intermediary, then signing in while the Conditional Access policy is active. MDCA detects the session and catalogs the app. Verify the app status in Settings > Cloud Apps > Conditional Access App Control apps.

For apps with custom domains or plug-ins, add associated custom domains to the app entry in the cloud app catalog to prevent URL rewriting failures.

---

Step 4: Build Access Policies and Session Policies

With Conditional Access App Control configured, you can now create the enforcement rules in MDCA. There are two policy types at play here: access policies (controlling whether a session is allowed at all) and session policies (controlling what a user can do within a session).

Access Policy: Block Unmanaged Device Login

An access policy controls access at the point of authentication. It can allow, block, or audit access based on user, device, location, and app.

To create a basic unmanaged device block:

1. In the Microsoft Defender portal, navigate to Cloud Apps > Policies > Policy management > Conditional Access tab
2. Select Create policy > Access policy
3. Name the policy and set the severity
4. Under Activities matching all of the following, set filters for:
   • App: target app (for example, Microsoft 365)
   • Device tag: does not equal Compliant, does not equal Hybrid Azure AD Joined
5. Under Actions, select Block
6. Select Create

Access policies apply at login and are evaluated before the session begins. Session policies, by contrast, are evaluated during an active session.

Session Policy: Block Sensitive File Downloads

This is the most common production use case for MDCA in organizations with BYOD or unmanaged device scenarios.

1. Navigate to Cloud Apps > Policies > Policy management
2. Select Create policy > Session policy
3. Name the policy (example: Block-Download-Unmanaged-Devices-SharePoint)
4. Set Session control type to Control file download (with inspection)
5. Under Activity source, configure:
   • App: target app
   • Device tag: does not equal Compliant (to target unmanaged devices only)
6. Under Files matching all of the following, configure sensitivity filters:
   • Sensitivity labels: select relevant Microsoft Purview labels (for example, Confidential)
   • Or use Content inspection to enable the built-in DLP engine to scan for sensitive content patterns
7. Under Actions, select Block
8. Customize the block message users see
9. Select Create

The session policy takes effect only for sessions routed through the Conditional Access policy created in Step 3. If the Conditional Access policy is scoped to unmanaged devices, managed devices bypass the proxy entirely and are not affected.

Session Policy: Monitor User Activities in Real Time

For lower-risk scenarios or initial rollout phases, a monitor-only session policy captures all user activity without blocking anything. This populates the activity log for investigation and alert triage.

Set Session control type to Monitor only. Note that this control type monitors only the login activity by default. To monitor downloads, uploads, and other activities, you need at least one block-per-activity policy active alongside the monitor policy.

Session Control Type Reference

Session Control Type	Use Case
Monitor only	Visibility without enforcement; activity logging
Block activities	Block specific actions (print, copy, paste)
Control file download (with inspection)	Block or audit downloads, scan file content
Control file upload (with inspection)	Block or audit uploads, scan for malware or sensitive data
Require step-up authentication	Trigger MFA for sensitive actions mid-session
Protect (apply sensitivity label on download)	Apply Purview label to files downloaded to unmanaged devices

Important limitation: Session policies apply to files up to 50 MB. For files larger than 50 MB, configure the default behavior in Settings > Conditional Access App Control > Default behavior to either allow or block the file regardless of policy matching.

---

Step 5: Configure Alerts and Threat Detection

MDCA ships with a set of built-in anomaly detection policies enabled by default. After an initial learning period (typically 7 days), MDCA baselines user behavior and starts generating alerts when deviations occur.

Built-In Anomaly Detection Policies

Out-of-the-box policies include:

• Activity from anonymous IP addresses
• Impossible travel (login from two geographically distant locations in an implausible time window)
• Activity from infrequent countries
• Suspicious inbox forwarding rules
• Mass download
• Ransomware activity
• Malware detected (via file scanning)

Each policy is tunable. Initially, expect alert volume to be high. Suppress alerts for known patterns (for example, the executive who travels internationally every week generating impossible travel alerts) using the Scope and Exclusionsconfiguration in each policy.

For new risky cloud apps in your environment, configure app discovery policies:

1. In the Microsoft Defender portal, navigate to Cloud Apps > Policies > Policy management
2. Select Create policy > App discovery policy
3. Use a template (New high-volume app or New popular app) as a starting point
4. Customize filters: risk score threshold, app category, minimum number of users
5. Set governance actions: alert only, or tag as unsanctioned automatically

Alerts generated by MDCA surface in the Microsoft Defender XDR alerts queue with standard incident priority and MITRE ATT&CK tactic tags, making them consumable by your SOC without a separate investigation workflow.

OAuth App Governance

OAuth apps represent a significant and underappreciated attack surface. When a user consents to an OAuth app, that app may receive persistent access to email, files, or calendar data without triggering conditional access policies or MFA challenges. A malicious actor who registers a convincing OAuth app can establish persistent access to your tenant with no credential to steal.

App Governance, available as part of MDCA, surfaces all OAuth apps that have been authorized in your tenant. Navigate to Cloud Apps > App governance to see the full list.

For each app, App Governance shows:

• Permission scope (for example, Mail.ReadWrite.All, Files.ReadWrite.All)
• Community trust score
• Last used date
• Certification status

Predefined App Governance policies detect anomalous and malicious OAuth app behaviors using machine learning and behavioral analytics. Note that Microsoft disabled several of these predefined policies in April 2025 due to high false-positive rates, so review which are currently active in your tenant.

Create a custom OAuth app policy to alert on newly authorized apps with high permissions and low community trust:

1. Navigate to Cloud Apps > Policies > Policy management
2. Select Create policy > OAuth app policy
3. Set filters: Permission level equals High and Community use equals Rare
4. Set governance action: Alert (start here; use auto-disable with caution as it can break legitimate workflows)

Disable any OAuth app that has not been used in 90 days and carries high permissions. You can always re-enable it if a user reports access issues.

---

Step 6: Information Protection and DLP Integration

Defender for Cloud Apps integrates with Microsoft Purview Information Protection to extend data loss prevention policies into your SaaS sessions and connected cloud apps.

Enable File Monitoring

File monitoring must be explicitly enabled before MDCA can scan and alert on file content. Navigate to Settings > Cloud Apps > Information Protection and toggle Enable file monitoring to on.

Once enabled, MDCA scans files in connected apps against your Purview sensitivity labels and built-in DLP templates. File policies can automatically quarantine, apply labels, or generate alerts when sensitive content is found in cloud storage.

Apply Microsoft Purview Sensitivity Labels in Session Policies

The Protect session control type applies a Purview sensitivity label to files as they are downloaded during a monitored session. This is particularly valuable for unmanaged device scenarios: a user can view a sensitive file in the browser, but the downloaded copy receives a Confidential label that Purview enforces, restricting where it can be opened or shared.

To apply labels in session policies:

1. Create a session policy with control type Control file download (with inspection)
2. Under Actions, select Protect
3. Select the sensitivity label to apply (for example, Confidential – Internal)

This requires that Microsoft Purview Information Protection is configured in your tenant and the relevant sensitivity labels are published to users.