Microsoft Defender for Cloud Apps explained

Microsoft Defender for Cloud Apps (MDA) — formerly Microsoft Cloud App Security — is Microsoft's Cloud Access Security Broker (CASB). It discovers what SaaS apps your users are using, monitors what they're doing in those apps, and provides controls to limit risk.

The three jobs of MDA

MDA fits the classic CASB model:

1. Discovery (Shadow IT)

By analysing traffic logs from firewalls and proxies — or signals from Defender for Endpoint on managed devices — MDA identifies which cloud apps are being used. It rates each app on dozens of risk factors (compliance certifications, hosting region, security features, data ownership). The result is a cloud discovery dashboard that tells you which apps you didn't know about and how risky they are.

2. SaaS Security Posture Management (SSPM)

For sanctioned apps, MDA evaluates the security configuration: are MFA settings correct, are admin permissions reasonable, are integrations safe. App connectors plug MDA into Microsoft 365, Salesforce, ServiceNow, Box, Google Workspace, Dropbox, AWS, GCP, and many more. SSPM is becoming the centre of MDA's value — it tells you where misconfiguration creates risk.

3. Real-time controls (Conditional Access App Control)

For apps integrated with Entra ID for SSO, MDA can proxy session traffic via Conditional Access App Control: route the user's session through MDA after sign-in, then enforce session controls — block download, prevent copy/paste, require step-up auth on sensitive actions, monitor and log.

File scanning and DLP

MDA also scans content in connected SaaS apps and applies Purview Information Protection labels and DLP policies. If a confidential document lands in Box or Dropbox, MDA detects it and can quarantine, remove sharing, or alert.

Integration with Defender XDR

MDA's alerts flow into Defender XDR, correlating SaaS-side anomalies (impossible travel, suspicious download volume, OAuth app risk) with endpoint, identity, and email signals.

Licensing

MDA is included in Microsoft 365 E5, Microsoft 365 E5 Security, and Enterprise Mobility + Security E5. Some discovery features are available in lower tiers via Defender for Endpoint's Cloud Discovery.

What good looks like

A typical mature deployment:

• Cloud Discovery integrated with the corporate proxy / firewall and MDE.
• App connectors for every sanctioned SaaS app.
• SSPM recommendations on the patching backlog.
• Conditional Access App Control for high-risk apps on unmanaged devices.
• OAuth app governance restricting which third-party apps users can consent to.

For organisations with significant SaaS sprawl, MDA is the only Microsoft product that gives a coherent view across the lot.

Decision matrix — do you actually need MDA?

| Situation | Verdict | |---|---| | You have E5 and 20+ SaaS apps outside M365 | Yes — connect the top ten by API and turn on cloud discovery. | | You have E5 but almost everything runs inside M365 | SSPM for Microsoft 365 and OAuth app governance are still worth turning on; skip Conditional Access App Control. | | You are on E3 and cannot buy Defender for Cloud Apps standalone | Get cloud discovery via Defender for Endpoint P2 and lean on Purview DLP for the rest; MDA-lite by another name. | | You use a third-party CASB (Netskope, Zscaler) already | Do not run both as the primary CASB. Use MDA for its native M365 signal (OAuth apps, SSPM for M365) and let the third-party CASB own the reverse proxy. | | You want to block file downloads from Copilot on unmanaged devices | Session policies via Conditional Access App Control is exactly this pattern. |

Wrong-fit warnings

• MDA is not endpoint DLP. For "block copy to USB" you still need Purview Endpoint DLP; MDA session control only reaches browser sessions routed through the proxy.
• The reverse proxy has friction. Some SaaS apps do not tolerate it well (uploads that use signed URLs, thick clients that bypass the browser). Test the exact user journey you want to control before promising it.
• Cloud Discovery is not real-time. Log ingestion has minutes-to-hours latency, so use it to spot patterns, not to block during the incident.
• OAuth app governance covers M365 consent grants only. Third-party OAuth ecosystems (Google, Slack) need their own review.

Worked example — a mid-size firm hitting Copilot readiness

Scenario: 800 users on Microsoft 365 E5. Security wants to answer "where is corporate data leaving?" before the Copilot rollout adds another exfiltration surface.

• Week 1: Turn on Cloud Discovery, feed it firewall logs plus Defender for Endpoint's cloud app signal. Baseline emerges within a week — usually a long tail of sanctioned but unmanaged SaaS.
• Week 2: Sanction the top five (typically Slack, Zoom, Miro, Notion, a CRM) and connect them by API. SSPM findings on those five get prioritised into the security backlog.
• Week 3: Turn on OAuth app governance in report-only for a week; then start revoking risky consented apps with unused permissions.
• Week 4: Session policy for the two apps that hold customer data: block download on unmanaged devices, watermark sensitive labels.
• Week 5: Wire alerts into Defender XDR so an impossible-travel alert on Salesforce correlates with the sign-in risk in Entra.

FAQ for MSPs

• Multi-tenant management? Defender for Cloud Apps has no first-class multi-tenant view. Managed hunting queries can be shared via advanced hunting exports, but each customer tenant needs its own MDA portal login. Lighthouse does not surface MDA alerts yet.
• Do MSP alerts merge with customer alerts? No — MDA alerts are always scoped to the tenant they fire in. Send them to the customer's SIEM or to your XDR via API.
• Which MDA feature buys the fastest MSP win? OAuth app governance. A single afternoon usually surfaces a dozen unused-but-consented apps with excessive permissions.
• Do we need the Defender for Cloud Apps portal or is XDR enough? The XDR portal shows the alerts and unified activity log; the MDA portal is still where policy is authored and SSPM findings are triaged.