Defender for Cloud Apps: What Actually Works in Production

We have deployed Defender for Cloud Apps (MDCA) across a mix of hybrid Microsoft 365 tenants and watched it go from "CASB checkbox on the E5 invoice" to actual signal. Getting there required understanding what the product does well, what it does poorly, and where the defaults will burn you in a real SOC.

This is what we learned.

What MDCA Actually Is (and Is Not)

Microsoft rebranded the product from Microsoft Cloud App Security in late 2022. The name changed; the architecture mostly did not. MDCA is three overlapping capabilities bundled under one license tier:

1. A cloud access security broker (CASB) that sits between your users and cloud services
2. A user and entity behavior analytics (UEBA) engine fed by Microsoft Graph signals
3. An app governance layer for OAuth consent abuse detection

What it is not: a firewall replacement, a DLP engine that works without Purview integration, or a substitute for endpoint detection on managed devices. We have seen customers buy E5 expecting MDCA to handle data loss end to end. It does not. The DLP policies are session-scoped and proxy-dependent. Purview still owns the labeling and classification plane.

Shadow IT Discovery: The Easiest Win

If you have Defender for Endpoint deployed at any meaningful scale, shadow IT discovery is essentially free. MDCA ingests the network telemetry MDE already collects and scores discovered apps against its 31,000-app catalog. Each app gets a risk score (0-10) based on factors like SOC 2 attestation, data residency controls, breach history, and GDPR posture.

The catalog scores are imperfect. We have seen legitimate enterprise tools score 4/10 because the vendor has not filled out the Microsoft questionnaire. The scores are a starting point, not a verdict. Build a sanction/unsanction workflow around them, not an automatic block.

For organizations running Cisco Umbrella or Zscaler alongside MDE, the log upload path (automated via syslog receiver or manual CSV) works but produces 24-48 hour lag compared to the real-time MDE telemetry stream. If you are triaging an incident, that lag matters.

Conditional Access App Control: The Hard Part

This is where most deployments stall. Conditional Access App Control (CAAC) proxies user sessions through Microsoft's reverse proxy to enforce session policies: block download, watermark, restrict paste, limit print. The capability is real. The prerequisites are annoying.

To proxy a session, the user must arrive at the app via an Entra Conditional Access policy that routes them through MDCA. That works cleanly for Microsoft 365 apps and the catalog of 100-ish pre-integrated apps. For custom or line-of-business apps, you need to onboard the app manually: configure SAML federation with Entra as IdP, test the proxy routing, verify certificate trust. Each app is a project.

The Edge integration changes some of this for managed Windows devices. When Microsoft Edge is the browser and the device is Entra-joined or hybrid-joined, MDCA can enforce session policies without the reverse proxy hop. The user experience improves, and the proxy-related TLS inspection issues disappear. But this only helps for the Edge-on-managed-device population. Browser diversity and BYOD scenarios still hit the full proxy path.

One hard lesson: session policy enforcement breaks apps that use certificate pinning or non-standard TLS stacks. We have hit this on financial services SaaS apps. The fix is either exclusion (which defeats the policy) or working with the vendor to accept the MDCA certificate chain.

OAuth App Governance: The Signal People Ignore

App governance is the least-used capability we see in production. That is a mistake.

Every time a user grants OAuth consent to a third-party app, that grant creates a persistent credential path into your tenant. App governance surfaces these grants, scores them for anomalous behavior (bulk mailbox reads, unusual API call patterns, first-seen consent scope), and can revoke them automatically or generate an alert.

This maps directly to MITRE ATT&CK T1550.001 (Application Access Token) and is one of the cleaner detection angles for post-compromise lateral movement via OAuth. The attacker phishes a user, lands a malicious OAuth app consent, and then operates from the app credential without touching the user account again. Traditional identity detections miss this because the sign-in logs show only the user's initial consent, not the ongoing app activity.

Set the following app governance policy as a baseline:

// Sentinel: Detect OAuth apps with broad mail and files scope consented in the last 7 days
OAuthConsents_CL
| where TimeGenerated > ago(7d)
| where PermissionScope has_any ("Mail.ReadWrite", "Files.ReadWrite.All", "Directory.ReadWrite.All")
| summarize 
    consent_count = count(),
    users = make_set(UserPrincipalName),
    app_ids = make_set(AppId)
    by AppDisplayName, PublishedBy
| where consent_count >= 1 and PublishedBy != "Microsoft Services"
| extend risk_flag = iff(array_length(users) > 5, "broad_adoption", "targeted")
| project TimeGenerated = now(), AppDisplayName, PublishedBy, consent_count, users, risk_flag
| order by consent_count desc

This query ingests from the custom table produced by the MDCA Sentinel connector. If you are not running the connector, replace OAuthConsents_CL with the CloudAppEvents table and filter on ActionType == "OAuthConsentGranted".

MDCA Alerts in Sentinel: Tuning Before You Drown

The default MDCA alert policies generate significant noise. Out of the box, you will see "Activity from anonymous IP address" fire on every VPN user and every developer running a Tor exit node test. You will see "Impossible travel" fire on service accounts that have legitimate multi-region activity.

The tuning process is not glamorous but it is necessary. We typically run three passes:

First, suppress alerts on known service account UPNs and shared mailboxes. These accounts by definition travel impossible distances and operate at odd hours. Tag them with a custom attribute in Entra and build a suppression filter in MDCA.

Second, configure IP range tagging. Mark your corporate egress IPs, your named VPN ranges, and your cloud build agent IPs as "corporate." Impossible travel and anonymous IP alerts factor this tagging into their scoring. Alert volume drops 40-60% in most tenants after this step alone.

Third, raise alert sensitivity thresholds on the behavioral analytics detections only after you have a week of baseline data. MDCA's threat detection learns per-user baselines over 7 days. Alerts generated in that first week are high-noise by design.

After tuning, MDCA genuinely catches things. Mass download events on departing employees, OAuth consent to newly-registered apps, simultaneous logins from geographically separated IPs that survive the impossible-travel logic. These are real signals that map to real incidents.

Connecting MDCA to Your Detection Pipeline

MDCA integrates with Microsoft Sentinel via the native connector (one click, near-real-time). It also supports syslog/CEF export for third-party SIEMs, but the schema normalization on the CEF side is incomplete. We use the native Sentinel path and ingest into the SecurityAlert and CloudAppEvents tables.

The CloudAppEvents table is the most useful raw table for custom detections. It captures session-level activity: file downloads, OAuth grants, admin consent, MDCA policy matches. Combined with IdentityLogonEvents and DeviceNetworkEvents from MDE, you get a cross-domain view that catches lateral movement patterns the per-product alerts miss individually.

For teams running the full detection engineering stack on Sentinel, MDCA becomes a high-value telemetry source rather than just an alert generator. The alert-centric view of the product undersells it.

What We Would Do Differently

On every deployment we wish we had done these earlier:

Start the app governance review in read-only mode before touching session policies. You need to understand your OAuth footprint before you can prioritize proxy onboarding.

Do not try to onboard more than three custom apps to CAAC in the first month. Each one is an integration project. Sequence them by data sensitivity, not by stakeholder urgency.

Set up the MDCA API log collector on-prem before relying on firewall log uploads. The collector is a Docker container, the setup takes an afternoon, and the reliability is significantly better than scheduled CSV uploads.

Budget time for the Purview integration. MDCA without Purview labels is visibility without enforcement. The two products are meant to work together and the combined capability is worth the configuration investment.

If you want help scoping an MDCA deployment, tuning the detection stack, or building the MDCA-to-Sentinel pipeline for your environment, reach out to us at /contact.