Discovery that never leads to a decision is a dashboard, and a dashboard of shadow IT is a report nobody acts on. The reason Defender for Cloud Apps discovery is worth configuring is not that it produces a long list of applications your users found on their own. It is that the same platform closes the loop, from seeing an app to sanctioning it or blocking it, and it closes that loop best when it rides the endpoint agent you already deployed. This is the shape of that loop, for both the shadow IT you have been watching for years and the shadow AI that arrived all at once.
Snapshot, or continuous
There are two fundamentally different ways to feed discovery, and choosing between them is the first real decision. A snapshot is an ad-hoc upload of a firewall or proxy log, useful for a one-time assessment, a quick read of what a segment is reaching, a number to take into a meeting. Continuous discovery is the real posture: an ongoing feed that ingests traffic data as it happens and layers machine-learning anomaly analysis on top, so the estate stays current and the unusual stands out against a learned baseline. There are four ways to supply that continuous feed, the native integration with Defender for Endpoint, a log collector that receives syslog or FTP from your appliances, direct integrations with secure web gateways like Zscaler and iboss, and a discovery API for everything else. They are not equal in effort, and for the audience this series is written for, one of them is close to free.
Discovery with no infrastructure
If your endpoints already run Defender for Endpoint, discovery is one toggle away and needs nothing else. In the Defender portal, under Settings, Endpoints, Advanced features, you turn on Microsoft Defender for Cloud Apps, and within about two hours the devices you have onboarded begin reporting the cloud traffic they see. There is no log collector to stand up, no traffic to mirror, no egress path to re-route. The endpoints are already watching the network they sit on, and this simply lets that observation flow into the catalog. It covers Windows 10 from 1709 forward and Windows 11, and macOS with network protection enabled, though not Linux, which is not a discovery source. For a modern estate that is the whole setup, and it is the reason discovery is one of the cheapest genuinely useful things in the suite to switch on.
Be precise about the licensing, because it is the one place this gets misread. Endpoint-based discovery needs a Defender for Cloud Apps entitlement, devices onboarded through Defender for Endpoint, and Endpoint Plan 2 or Defender for Business underneath them. Plan 2 supplies the network telemetry; it does not, on its own, license Cloud Discovery. This is where the licensing asymmetry the anchor raised bites in reverse. A tenant on EMS E5 has the full Cloud Apps license but no Defender for Endpoint at all, which means it owns the discovery product and lacks the endpoint telemetry source that makes this particular path work. That tenant discovers through a log collector or a gateway integration instead. Neither the endpoint plan nor the Cloud Apps license is sufficient alone; endpoint-based discovery is the intersection of the two, and reasoning about it as either one leads you wrong.
The catalog, and what the score is for
What discovery produces is a match against a catalog of more than thirty-one thousand cloud applications, each carrying a risk score built from more than ninety factors across four categories, the app’s general profile, its security controls, its compliance certifications, and its legal and privacy terms. The score is not a verdict and it is not there to be obeyed; it is there to make a large unknown list triageable. You weight the factors that matter to your organization, you override an app’s score where you have a business reason and record the reason, and you sort the estate into three working states. Sanctioned is an app you have blessed. Unsanctioned is one you have decided to keep out. Monitored is the deliberately underused middle, an app you are neither endorsing nor blocking but watching, and it is the tag that lets you warn rather than break. The catalog is the raw material. The tagging is where discovery starts turning into a decision, and it is worth remembering that a tag by itself changes nothing on any device until you connect it to enforcement.
Closing the loop: from a tag to a block
Marking an app unsanctioned does nothing until the platform can act on it, and this is where the endpoint integration pays off a second time. When Cloud Apps and Defender for Endpoint are joined, the domains of an unsanctioned app propagate to your onboarded devices as custom network indicators, and Defender’s own network protection enforces them. That last clause is the load-bearing one, and it is the same argument the endpoint block made about the protection engine: enforcement is only real if the engine is actually in force. Blocking discovered apps requires Defender Antivirus with real-time protection on, cloud-delivered protection on, and network protection running in block mode, not the passive or audit posture a surprising number of estates quietly sit in. An unsanctioned tag on top of an audit-mode engine is a policy that logs and never blocks. Get the substrate right, from the Intune Deployment Guide‘s hardening work, and the tag becomes a genuine control.
An unsanctioned tag on top of an audit-mode engine is a policy that logs and never blocks.
Two details decide whether the block behaves the way you expect. The first is the browser. Microsoft Edge enforces these blocks through SmartScreen and does it cleanly, including full URL paths. Chrome and Firefox lean on network protection instead, and to block a secure site by name there you have to disable QUIC and Encrypted Client Hello so the protection layer can still see the destination, a real prerequisite that quietly defeats blocks when it is missed. The second is patience: end to end, a newly unsanctioned app takes up to three hours to be blocked everywhere, roughly an hour for Cloud Apps to sync the indicator to Endpoint and up to two more for the policy to reach devices. This is governance, not an instant kill switch, and designing as though it were instant produces confusing gaps. There is also a ceiling to respect. Defender for Endpoint caps custom indicators at fifteen thousand per tenant and will not raise it, so a sprawling blocklist competes for the same budget as every other indicator you use, which is an argument for blocking deliberately rather than blocking everything the score frowns at.
The hard block is not the only move, and the softer one is underused. The Monitored tag drives a warn-and-educate experience: the user reaching a monitored app is told it is discouraged and given the choice to continue, with a bypass you can time-limit, and that scoping can be aimed at specific device groups. For a category you want to discourage without an outright ban, personal file-sync say, warn is often the honest control, because a hard block on something people have a real reason to use just teaches them to route around you. Where you do not run Defender for Endpoint, the gateway integrations with Zscaler, iboss and the others can auto-block too, but with less finesse: no device-group scoping and no warn mode, just allow or deny at the edge. The endpoint path is the one that gives you the full range of the loop.
Shadow AI is the same loop
The arrival of generative AI did not need a new mechanism, only a new category, and treating it as a separate problem is how organizations end up with an AI policy that has no teeth. Cloud Apps carries a dedicated Generative AI category in the catalog, now more than a thousand applications deep, scored on the same factors as everything else and blocked through the same endpoint indicators. Discovering which AI tools your users have adopted and deciding, per tool, to sanction, monitor, or block it is not a different project from shadow IT; it is the same loop pointed at a fast-moving corner of the catalog. What is genuinely different, and genuinely newer, is the governance of AI agents, the Copilot Studio and Foundry agents your organization builds rather than the public apps users visit. That capability is still in preview, and as of July 2026 its licensing moved to Microsoft Agent 365 rather than the Cloud Apps license, so it is a story to watch rather than one to build a design on today. Keep the two separate in your head: discovering and blocking the AI apps users reach is mature and is exactly the loop above; governing the agents you build is early, and priced through a different door.
What discovery hands to the next decision
Discovery and enforcement together answer one question well: of the applications your users adopted without asking, which do you allow, which do you watch, and which do you keep out. But adoption is only one of the two ways a SaaS estate grows around you. The other is quieter and more dangerous, because it does not show up as traffic from a browser. It shows up as an OAuth consent, a token an application asked for and a user granted, that keeps reaching into your data long after the person who approved it has forgotten they did. Discovery cannot see that, because there is no network session to catch. The plane that can is app governance, and it is where we go next.
Defender XDR
‹ Previous: [D 5] Defender for Cloud Apps: Seeing and Governing the SaaS Estate
Next: [D 5.2] App Governance: The OAuth Consent Control Plane ›
