Defender for Cloud Apps is the part of the suite that watches everything your users reach that is not a device and not a mailbox: the SaaS estate, the apps they signed up for without asking, the tokens they handed out, and the sessions they open in a browser. The easy mistake is to read it as a discovery tool, a dashboard of shadow IT. It does see, but the reason it earns a place in a security design is that it also governs, and one of the few pillars it does not intend to keep governing is walking out the door as I write this. Before you configure any of it, you need the shape of what it is now, because that shape is changing.
Five pillars, and the one that is leaving
Defender for Cloud Apps is a cloud access security broker, the CASB category, and inside this suite it resolves to five things worth naming plainly. It discovers the SaaS and AI apps your users actually adopted. It governs the OAuth apps they consented to, the ones now holding tokens into your data. It controls what happens inside a live browser session against a sanctioned app. It assesses the security posture of the SaaS platforms you have connected to it. And it detects threats on those connected apps, the impossible-travel logins and mass downloads and terminated-user activity that only an application’s own logs reveal. Discovery, app governance, session control, posture management, threat detection. Those are the durable five, and the rest of this block is about the three of them you configure directly.
There was a sixth, and it is leaving on a date you should write down. The file-based data protection in Cloud Apps, the data-loss-prevention file policies and the auto-labeling that rode on them, retires on January 6, 2027. Microsoft’s own statement of what survives is explicit: discovery, posture management, and threat detection stay, and file protection moves to Microsoft Purview. This is not a rumor or a nervous reading of a deprecation notice; it is a dated architectural decision, and it should change how you plan. If you are standing up Cloud Apps in 2026 to do file data-loss prevention, you are building on a floor with a removal date printed on it. That work belongs in Purview now, which carries its own E5 or E5 Compliance entitlement rather than riding the Cloud Apps license, and you should know going in that a few of the old file actions, quarantining a file, expiring a shared link, transferring ownership, the File ID condition itself, have no Purview equivalent to migrate onto. This is exactly why the block that follows has no information-protection article. There is nothing durable left in it to teach.
It sees the estate. The reason it belongs in a security design is that it also governs it.
The licensing spine, and an asymmetry worth catching
The suite anchor made a point of the E5 that is not an E5, the way Enterprise Mobility and Security E5 wears a name close enough to Microsoft 365 E5 to fool people and contains no Defender for Endpoint at all. Cloud Apps inverts that trap, and the inversion is worth holding onto. EMS E5 includes the full Defender for Cloud Apps, and Defender for Identity along with it. The exact license that leaves your endpoints dark covers your SaaS estate completely. Full Cloud Apps also arrives through Microsoft 365 E5, through the security add-on Microsoft renamed in October 2025 from Microsoft 365 E5 Security to the Microsoft Defender Suite, and as a standalone license in its own right. So the customer who was burned on endpoints by “but we have EMS E5” is, for cloud apps, genuinely covered. Same sentence, opposite outcome, one product over.
Below the full product sit two smaller flavors that are alive and easy to mistake for the whole thing. Cloud App Discovery, bundled into Entra ID P1 and the E3 tiers, is discovery only: it sees and scores apps and stops there, with no anomaly detection, no session control, no app governance. Office 365 Cloud App Security, carried in Office 365 E5, is an Office-scoped subset of the same idea. Neither is retired and neither is a stand-in for the licensed product, so a tenant that “has Cloud App Security” may have far less than the name implies. One co-requirement catches people out on the other side: session control, the browser-level enforcement, needs Microsoft Entra ID P1 on top of the Cloud Apps license, because it is delivered through Conditional Access and P1 is the license for that rail. App governance runs the other way, having stopped needing an add-on in June 2023, so it is included in the license, though you still have to switch it on.
The one-way doors
Two decisions here are made once and effectively forever. The data residency of your tenant, in the US, the EU, or the UK depending on where the tenant was first created, is fixed at creation and cannot be moved afterward without a support engagement you would rather not need. And the retention window is now a flat up-to-180-days; the old per-data-type retention table people still quote from memory is gone from the documentation, so do not design around it. Neither is a knob you tune later, which is precisely why both deserve a deliberate look the first time rather than a default accepted in passing. The administrative model has shifted too. The product’s permissions have folded into Defender unified role-based access control, which reached worldwide availability in December 2025, and once you activate the Cloud Apps workload there the old scoped roles, the Cloud Discovery administrators and their kin, stop working. And for the firewall team, the durable answer to a service whose IP ranges changed three times in a single year is the AzureFrontDoor.MicrosoftSecurity service tag rather than a hand-maintained list that ages badly.
What it owns, and what it hands off
A product this broad stays coherent only if you are strict about its edges, and this series is. Cloud Apps owns SaaS discovery, OAuth app governance, and the configuration of session controls, and it reaches for the rest rather than reteaching it. It does not own Conditional Access policy design; the targeting, the conditions, the break-glass exclusions, that discipline lives in the Intune guide and the identity series, and session control borrows the rail without rebuilding it. It does not own posture aggregation; the way SaaS posture recommendations now surface, in Microsoft Security Exposure Management for commercial tenants and in Secure Score for the government clouds where that is unavailable, is the exposure-management pillar’s story, and Cloud Apps only feeds it. And it does not own attack disruption; when an OAuth app compromise is contained automatically, Cloud Apps is the hand that executes the containment, but the correlation fabric that decides to pull the trigger is the capstone’s subject. Knowing what a product refuses to do is how you avoid building the same control twice in two places.
The map ahead
Everything after this is decision, and it follows the three verbs that survive the Purview handoff. First discovery and the enforcement loop it feeds, how Cloud Apps sees the shadow-IT and shadow-AI estate and, far more usefully, how it turns seeing into blocking without your standing up any infrastructure to do it. Then app governance, the plane where you find the OAuth grants your users made on your behalf and revoke the dangerous ones. Then session control, the one place Cloud Apps reaches inside a live session and changes what a person can do in it, told with the honesty that feature deserves about what it costs. Read against everything the endpoint block built, this is the workload that answers a different question: not is this device healthy, but what is my organization actually doing across the hundreds of services nobody deployed on purpose. We start where the estate first becomes visible, at discovery.
Defender XDR
‹ Previous: [D 4.3] Operating Mail Security: Submissions, Quarantine, and the Queue
Next: [D 5.1] Discovery, Shadow IT, and Shadow AI: The Enforcement Loop ›
