Security Azure

Taming Shadow IT and Risky SaaS: Microsoft Defender for Cloud Apps and Session Policies

May 20, 2026 15 min read Advanced Vinod

Your users are already in the cloud you didn’t sanction. Someone uploaded a customer list to a free PDF converter, a contractor is on a personal OneDrive, and three teams quietly stood up SaaS trials that never went through procurement. A Cloud Access Security Broker (CASB) closes that gap, and in a Microsoft estate the CASB is Defender for Cloud Apps (MDA). This walkthrough takes you from zero visibility to inline session control and OAuth governance, with the wiring that actually makes it work.

1. Where MDA fits in the Zero Trust stack

A CASB delivers four classic pillars: visibility (what apps and data are in use), compliance (are sanctioned apps configured safely), data security (DLP across SaaS), and threat protection (anomalous and malicious behavior). MDA implements these through four delivery modes, and you should understand which mode you are configuring at all times:

Mode What it sees How Latency
Cloud Discovery Shadow IT, app risk Ingests firewall / proxy / MDE traffic logs Near real-time to daily
API connectors Sanctioned app content, settings, users App vendor APIs (Graph, etc.) Minutes to hours (out of band)
Conditional Access App Control Live user sessions Reverse proxy in the auth flow Real-time (inline)
App governance OAuth app consent and behavior Microsoft Graph app telemetry Continuous

MDA does not stand alone. It is the SaaS plane of Microsoft’s Zero Trust architecture: Entra ID Conditional Access decides who gets routed to MDA, MDA decides what they can do in session, Microsoft Purview supplies the sensitivity labels and DLP classifiers, and Microsoft Defender XDR / Sentinel consumes the alerts. Treat MDA as one node in that graph, not a silo.

Licensing matters before you start. Cloud Discovery and basic policies ship with several plans, but app governance and the full set of connectors and session controls require Defender for Cloud Apps standalone or a suite such as Microsoft 365 E5 / E5 Security. Confirm entitlement in the portal before designing around a feature you can’t turn on.

2. Cloud Discovery: turn firewall and MDE logs into a shadow IT map

Discovery answers “what SaaS is my org actually using, and how risky is it?” by parsing egress traffic logs against MDA’s catalog of 30,000+ apps, each scored 0-10 on roughly 90 risk factors (data residency, compliance certifications, security posture, legal terms).

You have two ingestion paths. Pick both if you can.

Option A: Defender for Endpoint integration (recommended)

If your endpoints run Microsoft Defender for Endpoint (MDE), flip one toggle and every onboarded device becomes a discovery sensor - no log shipping, no parser, and you get coverage off the corporate network. In MDE, enable the Cloud App Security integration:

Microsoft Defender portal -> Settings -> Endpoints
  -> Advanced features -> "Microsoft Defender for Cloud Apps" -> On

Discovered traffic then flows into MDA and appears under the Cloud Discovery dashboard, machine-by-machine. This is by far the cleanest signal because it is device-attributed and does not depend on perimeter chokepoints.

Option B: Upload firewall / proxy logs

For network-edge visibility, feed MDA your egress logs. For continuous coverage, deploy a log collector (a Docker container) that receives syslog/FTP from your appliances and forwards to MDA. First create the data source and collector in the portal under Cloud Discovery -> Automatic log upload, then run the container the portal provisions:

# The portal generates this command with your tenant-specific values.
# It pulls the Microsoft-published log collector image.
docker run --name mda-log-collector \
  -p 21:21 -p 20000-20099:20000-20099 \
  -e "PUBLICIP=10.10.0.40" \
  -e "PROXY=" \
  -e "CONSOLE=<tenant>.portal.cloudappsecurity.com" \
  -e "COLLECTOR=<collector-name>" \
  --security-opt apparmor:unconfined \
  --cap-add=SYS_ADMIN \
  --restart unless-stopped \
  -v /var/log/mda:/var/adallom/syslog \
  mcr.microsoft.com/mcas/logcollector

Then point the firewall (Palo Alto, Fortinet, Zscaler, etc.) at the collector using the matching built-in log parser you selected. For a quick one-off assessment without a collector, use a snapshot report - manually upload a log file and MDA parses it on the spot.

Once data lands, work the dashboard top-down: sort discovered apps by risk score, tag the obvious sanctioned ones, and mark the dangerous unsanctioned ones as Unsanctioned. Tagging an app unsanctioned can drive automatic blocking if you export the block list back to your proxy/firewall or rely on MDE-based blocking.

3. Connect sanctioned apps via API connectors

Discovery sees traffic; connectors see content. App connectors use the vendor’s API to pull files, sharing state, accounts, and activity logs out of band, and to remediate (quarantine a file, suspend a user). Connect your crown-jewel SaaS first - Microsoft 365, then the big third parties (Salesforce, ServiceNow, Box, Google Workspace, AWS, GitHub).

Microsoft Defender portal -> Settings -> Cloud Apps
  -> Connected apps -> App connectors -> + Connect an app

For Microsoft 365 the connection is largely a consent click. For third parties you typically register an OAuth app or service account in the target SaaS and paste its credentials. After connecting, MDA backfills history and then streams activity. Two things to verify before you trust it:

Connectors are reactive by design - they act after an event is committed to the SaaS (a file was already shared, then quarantined seconds later). For prevention in the moment, you need the reverse proxy in the next section.

4. Conditional Access App Control: route sessions through the reverse proxy

This is the part teams get wrong. To block a download as it happens, MDA inserts itself into the authentication flow as a reverse proxy. Entra Conditional Access (CA) hands the session to MDA after sign-in; the user’s traffic to that app is then suffixed (contoso.sharepoint.com becomes contoso.sharepoint.com.mcas.ms) and proxied so MDA can enforce in real time.

Create a CA policy that targets the apps and conditions you care about, then set the session control:

Entra admin center -> Protection -> Conditional Access -> + New policy
  Users:        target group (pilot first!)
  Target resources: e.g. Office 365 / SharePoint Online / specific apps
  Conditions:   Device platforms, Client apps = Browser
                (optionally) Filter for devices: device is NOT compliant
                                              and NOT Hybrid Azure AD joined
  Session:      Use Conditional Access App Control
                -> "Use custom policy..."

Selecting Use custom policy routes matching sessions through MDA, where your session policies then apply. Critical scoping facts to internalize:

5. Session policies: block downloads, label, and step-up auth on unmanaged devices

With sessions flowing through the proxy, author session policies under Cloud Apps -> Policies -> Policy management -> Conditional access. The highest-value pattern: let unmanaged/BYOD devices view corporate SaaS in the browser but block download of sensitive content, so data never lands on an uncontrolled disk.

A typical “block download of labeled data on unmanaged devices” policy:

Field Value
Policy type Session policy
Session control type Control file download (with inspection)
Activity source Device tag is not Compliant, Hybrid Azure AD joined, or Intune-managed
File filter Sensitivity label equals Confidential (or Content Inspection match)
Action Block
User notification Custom message: “Downloads of Confidential data are blocked on unmanaged devices.”

Other session controls you will reach for:

Inspection has limits: content inspection caps file size and can’t read strongly encrypted or some proprietary formats. Lean on sensitivity labels (which travel with the file and are evaluated cheaply) rather than only on real-time content scanning.

6. File policies and DLP integration for exfiltration detection

File policies scan content discovered through API connectors (the at-rest plane) and act on it. They are how you catch “a file labeled Confidential is shared with the whole internet” after the fact. MDA’s native DLP includes built-in templates (PII, PCI, financial), and it natively understands Microsoft Purview sensitivity labels, so your existing classification taxonomy carries straight into SaaS governance.

Build a file policy under Policies -> Policy management -> Information protection:

For the strongest classification, route MDA inspection through Microsoft Purview Data Loss Prevention so the same DLP policies and sensitive-information types that protect Exchange, SharePoint, and endpoints also evaluate third-party SaaS content via MDA - one policy authority, consistent verdicts. Avoid maintaining two divergent DLP rule sets; pick Purview as the source of truth and let MDA consume it.

7. App governance: rein in risky OAuth consent and overprivileged apps

The most overlooked SaaS attack surface is OAuth app consent. A user clicks “Accept” on a third-party app requesting Mail.ReadWrite and offline_access, and now an external app has a persistent token into your tenant - no password, immune to your MFA. App governance in MDA monitors OAuth apps registered against Microsoft 365 / Entra and flags risk by permission scope, publisher verification, usage, and behavioral anomalies (sudden spikes in data access, dormant apps that wake up).

Enable it under Microsoft Defender portal -> Settings -> Cloud Apps -> App governance, then:

  1. Triage the inventory. Sort apps by privilege and data access. Look for overprivileged scopes (*.ReadWrite.All, Directory.ReadWrite.All), unverified publishers, and apps with many users but little legitimate purpose.
  2. Write app governance policies that alert or act - for example, “flag any new app granted high-privilege Graph permissions by a non-admin,” or “disable apps from unverified publishers accessing more than N users’ mailboxes.” Governance actions can disable the app, cutting its tokens immediately.
  3. Close the front door in Entra so consent can’t run wild: restrict user consent to verified publishers and low-risk scopes, and stand up an admin consent workflow so risky requests queue for review instead of being auto-granted.
Entra admin center -> Identity -> Applications -> Enterprise applications
  -> Consent and permissions
     -> User consent settings:
        "Allow user consent for apps from verified publishers,
         for selected permissions"
     -> Admin consent requests: enable, assign reviewers

This pairing is the win: Entra prevents most risky consents up front, and MDA app governance catches what slips through and lets you kill it after the fact.

8. Anomaly detection, alert tuning, and feeding Sentinel

MDA ships anomaly detection policies out of the box - impossible travel, activity from infrequent countries, mass download, mass delete, ransomware activity, suspicious inbox rules, suspicious OAuth app activity. They self-baseline per user over an initial learning period (so expect a quieter first week or two while profiles build).

Two operational disciplines separate a useful deployment from an ignored one:

Microsoft Sentinel -> Configuration -> Data connectors
  -> "Microsoft Defender XDR" -> Open connector page
     -> Connect incidents & alerts
     -> Under "Connect events", enable CloudAppEvents
        (raw MDA activity for hunting)

With CloudAppEvents in the Defender/Sentinel advanced hunting schema, you can write KQL across the SaaS plane - here, surfacing potential mass-download exfiltration to correlate with your DLP and identity signals:

CloudAppEvents
| where Timestamp > ago(1d)
| where ActionType == "FileDownloaded"
| summarize Downloads = count(),
            Apps = make_set(Application)
    by AccountDisplayName, bin(Timestamp, 1h)
| where Downloads > 200
| sort by Downloads desc

Enterprise scenario

A financial-services client rolled out the “block download of Confidential data on unmanaged devices” session policy to a pilot ring and it worked perfectly in testing. Two days into a wider ring, the help desk lit up: SharePoint and Teams web were intermittently slow, and a subset of users saw the .mcas.ms banner while others on the same unmanaged laptops did not. The policy was inconsistent.

Root cause was the gotcha in Conditional Access App Control scoping: it only governs browser sessions, and the org had a separate “require compliant device” CA policy that, for some app/client combinations, was evaluated such that non-browser (Office desktop, Teams thick client) traffic never hit the proxy at all. Users were silently round-tripping through the desktop client and pulling Confidential files straight to disk - the exact exfiltration path the policy was meant to close. The “inconsistency” was browser users getting blocked while desktop users walked through the side door.

The fix was a companion CA policy, not a session-policy tweak. They added a policy targeting the same apps with Client apps = Mobile apps and desktop clients and a device filter for non-compliant, non-Hybrid-joined devices, set to Block:

Entra -> Conditional Access -> + New policy
  Users: pilot ring
  Target resources: Office 365
  Conditions:
    Client apps: Mobile apps and desktop clients   (NOT Browser)
    Filter for devices: device.trustType -ne "ServerAD"
                        and device.isCompliant -ne True
  Grant: Block access

Browser sessions still route through MDA for view-only with download blocking; desktop/mobile clients on unmanaged devices are denied outright. One coherent control surface, no side door.

Verify

Prove each plane is live before you call it done:

Rollout checklist

Pitfalls to avoid

Defender for Cloud AppsCASBDLPConditional AccessShadow ITApp Governance
VH

Written by Vinod

Senior Cloud Architect with 22+ years of experience. Sharing practical knowledge from production environments.

Comments

// more articles

Keep Reading

Security Jun 8, 2026

Stopping Token Theft: Conditional Access Token Protection and Authentication Context

Defeat pass-the-cookie and token-replay attacks on Microsoft Entra with device-bound token protection, authentication context tags, and protected actions that gate your highest-value operations.

16 min read Read
Security Jun 8, 2026

Defender EASM: Discovering and Reducing Your Internet-Facing Attack Surface

A principal engineer's step-by-step guide to Microsoft Defender EASM - seeding discovery, claiming and de-duplicating inventory, triaging exposures, and feeding findings into Defender XDR exposure management and Sentinel.

16 min read Read
Security Jun 8, 2026

Defender for Cloud Attack Path Analysis: Custom Recommendations and Governance Rules

Operationalize the Defender for Cloud security graph to prioritize attack paths, author custom KQL recommendations, and drive remediation with governance rules, owners, and SLAs across Azure, AWS, and GCP.

15 min read Read