Defender for Cloud Apps (MCAS): CASB Configuration for Zero Trust

The OAuth App Problem Your Conditional Access Policies Don't Solve

Walk into any M365 tenant that's been running for three or more years and pull the OAuth app consent list. The number is almost always higher than anyone on the security team knows. Apps authorized by users: calendar integrations, productivity tools, AI writing assistants, meeting schedulers: each holding delegated or application permissions on Exchange, SharePoint, or Microsoft Graph. Most were authorized before your current Conditional Access policies existed. None of them go through Conditional Access when they make API calls, because Conditional Access protects the authentication event, not the ongoing delegated token.

Defender for Cloud Apps, the product Microsoft rebranded from Cloud App Security (MCAS) in 2022, addresses three gaps that Conditional Access leaves open:

• What users do inside sanctioned cloud applications after authenticating
• Which unsanctioned cloud applications exist across the organization
• Which OAuth apps have been granted permissions to tenant data and how they're using those permissions

The CASB architecture sits between users and cloud applications. In session proxy mode (Conditional Access App Control), it proxies browser sessions, enabling real-time inspection and enforcement. In API-connected mode, it reads activity logs and file metadata from connected apps without requiring traffic redirection. Both modes provide visibility and control that authentication-time checks cannot.

This article covers the complete zero trust configuration: Cloud Discovery, Conditional Access App Control session policies, information protection, OAuth app governance, and KQL queries to monitor enforcement.

CASB Integration Architecture

Defender for Cloud Apps integrates with cloud apps in three modes. The mode determines which controls are available. Building a policy against an app that isn't in the right integration mode produces no enforcement effect without surfacing an error.

For zero trust posture, the priority order is:

1. App connectors for sanctioned SaaS apps: visibility into post-auth activity and OAuth governance
2. Session proxy (CAAC) for data-sensitive applications: real-time enforcement at the session layer
3. Defender for Endpoint integration: replaces manual log uploads with automatic continuous discovery

Cloud Discovery: Enable Continuous Visibility via Defender for Endpoint

Manual log uploads provide historical snapshots with a 24-hour lag and require log infrastructure to maintain. The integration between Defender for Endpoint and Defender for Cloud Apps enables real-time cloud discovery without any additional log infrastructure: devices enrolled in MDE stream cloud traffic metadata automatically.

Enable the integration in the Microsoft Defender portal at Settings > Endpoints > Advanced Features > Microsoft Defender for Cloud Apps, toggle to On.

Within 24 to 48 hours, the Cloud Discovery dashboard populates with discovered apps, user counts, transaction volumes, and risk scores. The risk score (1 to 10) factors in approximately 80 attributes: encryption in transit and at rest, GDPR compliance claims, data retention policies, legal jurisdiction, and security certification status. Any app scoring below 5 warrants review for blocking.

For devices not enrolled in MDE (servers, legacy systems, IoT devices), deploy a Docker-based log collector to receive syslog output from your firewall or proxy:

docker pull mcr.microsoft.com/mcas/logcollector:latest

docker run -d \
  --name casb-log-collector \
  --restart always \
  -p 514:514/udp \
  -p 601:601/tcp \
  -e COLLECTOR_TOKEN="<token-from-defender-portal>" \
  mcr.microsoft.com/mcas/logcollector:latest

Configure your Palo Alto, Fortinet, or Zscaler proxy to syslog-forward to the collector's IP on port 514 (UDP) or 601 (TCP). The collector parses vendor-specific log formats and streams enriched app metadata to the Defender for Cloud Apps backend.

Classifying and Blocking Unsanctioned Apps

Cloud Discovery surfaces what's running. The next step is classification. Set every discovered app to Sanctioned, Monitored, or Unsanctioned. Unsanctioned with block enabled pushes a block indicator to MDE-enrolled devices and compatible proxy integrations.

Block an app using the Defender for Cloud Apps REST API:

curl -X POST "https://<tenant>.portal.cloudappsecurity.com/api/v1/discovered_apps/unsanction" \
  -H "Authorization: Token <api-token>" \
  -H "Content-Type: application/json" \
  -d '{"appId": 12345, "block": true}'

For MDE-integrated devices, the block signal propagates to Windows Defender SmartScreen and Network Protection within approximately 2 hours. For proxy-based environments, download the generated block list from Settings > Cloud Discovery > Block scripts and import it into your Palo Alto or Zscaler URL category policy.

For detecting shadow AI tools specifically (unapproved ChatGPT wrappers, coding assistants that upload code to external services), search Cloud Discovery by category "AI" or tag "Generative AI". The full shadow AI detection and governance workflow is covered in the [shadow AI governance guide](/blog/shadow-ai-enterprise-detection-governance-2026).

Conditional Access App Control: Session-Level Enforcement

CAAC is the inline session proxy capability. When a user authenticates to a SAML or OIDC app via Entra ID, CAAC rewrites the reply URL to route the browser session through Microsoft's reverse proxy. From the user's perspective, the app behaves normally. From the security team's perspective, every HTTP request is inspectable and enforceable.

Prerequisites:

• The target app must use Entra ID as the identity provider via SAML or OIDC
• A Conditional Access policy must route the app through CAAC
• The app must render without strict frame-busting headers that block proxy injection

Conditional Access policy configuration for CAAC:

In the Entra ID Conditional Access portal, modify the policy governing the target app. Under Sessions > Use Conditional Access App Control:

• Select "Monitor only" during the rollout phase: traffic is proxied and logged but no blocking occurs
• Switch to "Use custom policy" when session policies are tested and ready to enforce

Session policy: block download from unmanaged devices

In Defender for Cloud Apps under Policies > Session policies, create:

Policy name: Block-SharePoint-Download-UnmanagedDevice
Session control type: Control file download (with inspection)
Applications: Microsoft SharePoint Online
User filter: All users
Device tag: NOT "Intune compliant", NOT "Hybrid Azure AD joined"
Action: Block
Alert severity: Medium
Send alert to: security-team@contoso.com

This policy stops the scenario where a user on a personal device accesses SharePoint via a mobile browser and mass-downloads files outside the device compliance check. Conditional Access verified the device (or didn't) at authentication time; the session proxy enforces the download restriction at the HTTP layer regardless of how the session was established.

Session policy: watermark downloads from managed devices

For managed devices where download is permitted but a forensic trail is needed:

Policy name: Watermark-SharePoint-Download-ManagedDevice-Confidential
Session control type: Control file download (with inspection)
Applications: Microsoft SharePoint Online
File filter: Sensitivity label is "Confidential" OR "Highly Confidential"
Device tag: "Intune compliant" OR "Hybrid Azure AD joined"
Action: Protect (apply label and watermark)
Watermark text: "[User.Mail] [Date]"

The proxy applies the watermark to the downloaded copy only. The original file in SharePoint is unchanged. This creates a forensic trail linking the document to the specific user and session without requiring an endpoint agent or custom DRM infrastructure.

Information Protection: File Policies for Stored Data

File policies scan files stored in connected apps continuously, not just at the time of download or upload. They catch data that arrived before the policies were created, which is critical for any tenant with years of unscanned SharePoint content.

File policy: detect unprotected PII in SharePoint

Policy name: Detect-UnprotectedPII-SharePoint
Applications: Microsoft SharePoint Online
Inspection method: Built-in DLP
Content match: "Credit Card Number" OR "U.S. Social Security Number" OR "IBAN"
File filter: Sensitivity label is NOT "Confidential" AND NOT "Highly Confidential"
Action: Apply sensitivity label "Confidential"
Governance: Notify file owner
Alert severity: High

File policy: detect sensitive files shared externally

Policy name: Detect-ExternalShare-Confidential
Applications: Microsoft SharePoint Online, Microsoft OneDrive
File filter: Sensitivity label is "Confidential" OR "Highly Confidential"
Collaborators: External users have access (domain NOT in approved partner list)
Action: Remove external collaborator access
Governance: Quarantine file, notify file owner, email compliance team
Alert severity: High

These policies complement Purview endpoint DLP. Purview endpoint DLP covers files accessed from managed Windows endpoints. Defender for Cloud Apps file policies cover the same files when accessed via browser on any device, or via third-party apps connected through OAuth grants. Both layers are required for full coverage of regulated data.

OAuth App Governance

App Governance is included with Microsoft 365 E5 and Defender for Cloud Apps plans. Access it at Microsoft Defender portal > Cloud Apps > App Governance.

The highest-priority view is Apps > High privilege. Filter for apps that have:

• Files.ReadWrite.All: full read/write access on all SharePoint and OneDrive content in the tenant
• Mail.ReadWrite: full read/write access on all Exchange mailboxes in the tenant
• Directory.ReadWrite.All: permission to modify any Entra ID object

These three permission scopes in an unrecognized or community-rare app are the clearest signals of a compromised OAuth token or a malicious consent grant attack (also called illicit consent grant).

Create an App Governance policy for high-privilege apps with anomalous activity:

Policy name: Alert-HighPrivilege-LowUsage-Apps
Trigger: App has Files.ReadWrite.All OR Mail.ReadWrite
AND: Publisher is not Microsoft-verified
AND: Community use is less than 5%
AND: API call rate exceeds 300 calls/day with fewer than 5 active users
Action: Alert (high severity), Generate incident in Defender portal

Revoke consent for confirmed suspicious apps:

Connect-MgGraph -Scopes "Application.Read.All", "AppRoleAssignment.ReadWrite.All", "DelegatedPermissionGrant.ReadWrite.All"

# Revoke all app role assignments for a service principal
$spId = "<service-principal-object-id>"
$assignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $spId
foreach ($assignment in $assignments) {
    Remove-MgServicePrincipalAppRoleAssignment \
        -ServicePrincipalId $spId \
        -AppRoleAssignmentId $assignment.Id
}

# Revoke delegated permission grants
$grants = Get-MgOauth2PermissionGrant -Filter "clientId eq '$spId'"
foreach ($grant in $grants) {
    Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $grant.Id
}

# Disable the service principal to prevent new token issuance
Update-MgServicePrincipal -ServicePrincipalId $spId -AccountEnabled $false

Zero Trust Policy Coverage Map

The following matrix maps each policy type to the zero trust principle it enforces and the specific threat it addresses:

Enable all built-in anomaly detection policies under Settings > Cloud Apps > Anomaly Detection. The policies to verify as active: Impossible travel, Activity from anonymous IP addresses (Tor, VPN, anonymizer services), Ransomware activity detection, and Mass download.

Monitoring with KQL

When Defender for Cloud Apps alerts are forwarded to Microsoft Sentinel via the Microsoft Defender XDR data connector, these queries provide hunting and alert coverage:

Download block events by user and policy:

CloudAppEvents
| where ActionType == "BlockedAccessAttempt"
| where Application in ("Microsoft SharePoint Online", "Microsoft OneDrive")
| extend PolicyName = tostring(RawEventData.BlockingPolicyName)
| extend DeviceType = tostring(RawEventData.DeviceType)
| summarize BlockCount = count() by AccountDisplayName, PolicyName, DeviceType, bin(Timestamp, 1h)
| where BlockCount > 3
| order by BlockCount desc

Anomalous OAuth app API call volume:

CloudAppEvents
| where ActionType == "OAuthAppActivityByServicePrincipal"
| extend AppName = tostring(RawEventData.AppName)
| extend ScopesUsed = tostring(RawEventData.Scopes)
| where ScopesUsed has_any ("Mail.ReadWrite", "Files.ReadWrite.All", "Directory.ReadWrite.All")
| summarize DailyCallCount = count() by AppName, AccountId, bin(Timestamp, 1d)
| where DailyCallCount > 500
| order by DailyCallCount desc

Impossible travel alert triage:

SecurityAlert
| where ProductName == "Microsoft Cloud App Security"
| where AlertName has "Impossible travel"
| project TimeGenerated, CompromisedEntity, Description, Severity, ExtendedProperties
| order by TimeGenerated desc

For integration with the broader zero trust posture, see the [zero trust security guide](/blog/what-is-zero-trust-security-complete-guide) and the [non-human identity governance guide](/blog/non-human-identities-nhi-ai-agent-security-2026) for the service account and managed identity layer that CASB controls complement.

CAAC Rollout Strategy

Rolling CAAC into production without a test phase causes user-visible disruption. Common failure modes:

• Apps with strict Content-Security-Policy headers that block the proxy's JavaScript injection: visible as a blank page or console errors about refused frame embedding
• Single-page applications using custom authentication libraries outside standard OIDC redirects: the reply URL rewrite may fail silently and redirect users to an error page
• Apps behind split-tunnel VPN where some traffic bypasses the proxy: session policies appear to apply but download restrictions don't trigger for tunneled traffic

Recommended rollout sequence:

1. Deploy CAAC in Monitor Only mode for two weeks, observing session activity without blocking
2. Review the CloudAppEvents table in Sentinel for access patterns that would have triggered blocking under enforcement policies
3. Test session policies against a pilot group of 10 to 20 users before tenant-wide rollout
4. Switch to enforcement mode for the pilot group and monitor support ticket volume for proxy-related rendering issues
5. Expand to full tenant in batches by department over two weeks

For the full zero trust architecture these controls fit into, including the [Defender for Cloud vs. Wiz CSPM comparison](/blog/best-cspm-tools-2026-defender-for-cloud-vs-wiz-vs-orca-vs-prisma-cloud) for cloud workload posture coverage.

Hardening Checklist

• [ ] Defender for Endpoint integration enabled for real-time cloud discovery without log upload infrastructure
• [ ] All discovered apps classified as sanctioned, monitored, or unsanctioned within 30 days of initial discovery
• [ ] Unsanctioned apps with risk score below 5 blocked via MDE or proxy integration
• [ ] CAAC session policies deployed for SharePoint, OneDrive, and Exchange OWA: downloads blocked from unmanaged devices
• [ ] Watermarking policy active for managed-device downloads of Confidential-labeled documents
• [ ] App connectors configured for all sanctioned SaaS: M365, Salesforce, Box, GitHub Enterprise, AWS
• [ ] File DLP policies active: scanning SharePoint and OneDrive continuously for unprotected PII
• [ ] External sharing detection active: removing access when Confidential files are shared outside the approved domain list
• [ ] App Governance enabled with high-privilege app policies configured and alerting
• [ ] All anomaly detection policies enabled: impossible travel, anonymous IP, mass download, ransomware detection
• [ ] CASB alerts forwarded to Sentinel via Microsoft Defender XDR data connector
• [ ] KQL alert rules deployed for download blocks, OAuth call volume anomalies, and impossible travel events
• [ ] CAAC tested in monitor-only mode for each target app before switching to enforcement
• [ ] Quarterly OAuth app review scheduled: audit apps with write permissions every 90 days and revoke stale consent

Frequently Asked Questions

What is the difference between Conditional Access and Defender for Cloud Apps?

Conditional Access controls the authentication event: it decides whether a sign-in is allowed, blocked, or requires MFA based on signals like location, device compliance, and risk. Defender for Cloud Apps (the CASB formerly called MCAS) controls what happens after authentication: it monitors activity inside the app, enforces session-level controls like blocking downloads, and governs OAuth apps that hold delegated permissions to tenant data. Conditional Access App Control is the bridge between the two, routing a Conditional Access policy into a Defender for Cloud Apps session proxy.

How does Cloud Discovery work without deploying a log collector?

If devices are enrolled in Microsoft Defender for Endpoint, enabling the integration at Settings > Endpoints > Advanced Features > Microsoft Defender for Cloud Apps streams cloud traffic metadata automatically, with the Cloud Discovery dashboard populating within 24 to 48 hours. A Docker-based log collector is only needed for devices not enrolled in MDE, such as servers, legacy systems, or IoT devices, where it receives syslog output from a firewall or proxy instead.

What permissions make an OAuth app high risk in App Governance?

The three permission scopes that most often indicate a compromised token or a malicious consent grant attack are Files.ReadWrite.All (full read/write on all SharePoint and OneDrive content), Mail.ReadWrite (full read/write on all Exchange mailboxes), and Directory.ReadWrite.All (permission to modify any Entra ID object). An app holding one of these scopes from a publisher that is not Microsoft-verified, with low community usage and an API call rate disproportionate to its active user count, is the clearest signal to investigate and potentially revoke consent.

Why does Conditional Access App Control break some applications?

CAAC works by rewriting the reply URL so the browser session is proxied through Microsoft's reverse infrastructure, which requires the app to render without strict frame-busting headers. Apps with strict Content-Security-Policy headers can block the proxy's JavaScript injection, showing a blank page or frame-embedding errors. Single-page applications using custom authentication libraries outside standard OIDC redirects can fail the reply URL rewrite silently. This is why CAAC should run in Monitor Only mode for at least two weeks before enforcement, and be tested against a pilot group before a tenant-wide rollout.

Do Defender for Cloud Apps file policies replace Purview endpoint DLP?

No, they cover different access paths and both are needed for full coverage of regulated data. Purview endpoint DLP applies to files accessed from managed Windows endpoints. Defender for Cloud Apps file policies scan files stored in connected apps continuously and apply when the same files are accessed via a browser on any device or through a third-party app connected via OAuth grant, including content that was uploaded before the policies existed.