Microsoft Defender for Cloud Apps: Governance Policies That Actually Work
- Derek Morgan
- Jul 21
- 5 min read
A client had been running Cloud Discovery in Microsoft Defender for Cloud Apps for months before we ever got engaged. Signals were flowing in from Microsoft Defender for Endpoint, plus a log collector pulled from a mix of virtual and on-premises firewall appliances. On paper, that looked like decent coverage. In practice, it was a complete mess: risk scores that didn't match reality, discovered apps that made no sense for the environment, and an admin team that had stopped trusting the dashboard entirely.
That's the failure mode I see most often with Defender for Cloud Apps (MDCA) governance: most tenants enable Cloud Discovery, glance at the dashboard once, and never turn on a policy. The average enterprise now runs more than 1,000 cloud apps, and IT has direct visibility into fewer than 1 in 10 of them. Discovery without enforcement is a report nobody acts on.
This is a walkthrough of the four policy layers inside MDCA that actually change what happens, the order to build them in, and one of those layers you should stop investing in right now, because Microsoft is retiring it.
The four layers, and the one that's changing
MDCA governance breaks into four policy types. Three are stable today. The fourth is in transition, and the timing matters for anyone planning work in the next two quarters.
Cloud Discovery and app risk scoring
Cloud Discovery comes first. It ingests logs, typically firewall or proxy traffic, sometimes fed by Defender for Endpoint signals, and scores every discovered app against more than 90 risk factors: data storage location, compliance certifications, breach history, and more. Every other policy in MDCA depends on this layer having clean input.
That dependency is the trap. If your log sources are misconfigured, wrong appliances in scope, incomplete coverage, duplicate signals, the risk scores built on top of that data are worthless, and everything downstream inherits the error.
OAuth and app governance policies
App governance policies flag and can auto-remediate over-permissioned OAuth grants across Entra ID, Google Workspace, and Salesforce-connected apps. This is the layer most tenants skip. Touching third-party OAuth integrations feels riskier than tuning a sanctioned-app policy, so it sits at the bottom of the backlog indefinitely.
That avoidance is expensive. An OAuth grant with broad Mail.Read or Files.ReadWrite.All scope is a standing credential. It doesn't expire on its own, it isn't challenged by MFA, and it doesn't show up in a sign-in log the way a compromised user account does. It just sits there, working, until someone thinks to look.
File-level data governance: the layer in transition
Here's the one that's different. Microsoft Defender for Cloud Apps file policies retire on January 6, 2027. DLP file policies configured in MDCA will stop being enforced after that date, and any policy you want to keep has to be migrated into Microsoft Purview DLP before then. SharePoint and OneDrive file DLP are already generally available in Purview; Box and Google support is moving there too.
If you're building new file-level governance today, build it in Purview DLP, not MDCA. MDCA still has a role here: its Cloud Discovery and app governance signals still show what data lives where. The enforcement layer for files has already moved.
If you already have MDCA file policies in production, the deadline isn't abstract. Nothing breaks with a warning banner on January 7, 2027. Enforcement just stops, silently, and you find out during an audit or an incident, whichever comes first.
Access and session policies
Conditional Access App Control gives you real-time session controls: block a download, force read-only access, block copy-paste, before the user ever leaves the browser tab. This deserves its own deep-dive treatment (coming later this year) rather than a paragraph here. Short version: it's active, it's not going anywhere, and it should be the last layer you build, not the first.
Build order, and the traps that break each layer
Sequence matters more than coverage. Turning on all four layers simultaneously without tuning any of them produces alert fatigue and a policy stack nobody trusts. Build in this order:
Cloud Discovery, with correctly configured log sources
OAuth and app governance policies
Purview DLP for file-level governance
Access and session policies, once the first three are stable
Two traps show up constantly in this sequence.
Unscoped OAuth revocation: auto-revocation policies pushed straight to production, without an alert-only phase first, will eventually catch a business-critical integration in the blast radius. Run every new OAuth governance policy in alert-only mode for at least one full business cycle before you let it take automated action.
Bad Cloud Discovery input: this is the trap that hit the client from the opening. Once we worked through the log collector vendor's documentation, we reconfigured it to pull from the correct security appliances, not just whatever feed happened to be easiest to wire up, and to actually capture the fields MDCA needed to score risk accurately. Discovery went from noise to something the admin team trusted again. If you only fix one thing before turning on any other policy, fix your log sources first. Every layer above Cloud Discovery inherits whatever quality problem exists at that layer.
The business case
To a CFO, this is blast radius and remediation cost.
An over-permissioned OAuth grant is a standing credential with no expiry and no MFA challenge. When it's caught at grant time, through an app governance policy running in alert-only mode, remediation is a five-minute conversation: revoke the scope, notify the user, move on. When it's caught during an incident instead, because nobody was watching, remediation means auditing every file and mailbox that grant touched for as long as it was active, which could be months or years. That cost difference is what separates a policy review from an incident response engagement.
The file policy retirement carries its own version of this risk. An organization that doesn't migrate to Purview DLP before January 6, 2027 loses enforcement silently. The first sign is usually a sensitive file that moved somewhere it shouldn't have, discovered well after the fact.
Where to start Monday morning
If you're standing up MDCA governance from scratch, or fixing one that's been running unmonitored, the order holds:
Audit and correct Cloud Discovery log sources before trusting any risk score it produces.
Turn on OAuth and app governance policies in alert-only mode, then tighten to enforcement once you've confirmed no business-critical grants are in the blast radius.
Build new file-level governance in Purview DLP, not MDCA. Migrate anything currently in MDCA file policies before January 6, 2027.
Layer access and session policies last, once the first three are producing data you trust.
Four layers, in the right order, with clean input, is what makes MDCA governance a control instead of a dashboard nobody checks.
Are Your Defender for Cloud Apps Policies a Control, or Just a Report?
Cloud Harbor Consulting partners with security architects and technical leadership teams to turn a Defender for Cloud Apps deployment that stalled at Cloud Discovery into a governance program with all four policy layers built, tuned, and enforced in the right order. Schedule a conversation to walk your tenant against this build order and pinpoint where a misconfigured log collector, an unscoped OAuth revocation policy, or file policies that haven't been migrated ahead of the January 2027 retirement are leaving your SaaS estate ungoverned.
Comments