Most organisations have cloud apps nobody approved: file-sharing sites, AI chat tools, personal note-taking services. If your devices run Microsoft Defender for Endpoint, you already have the data to see those apps and the enforcement point to stop them. In this post I'll connect it to Microsoft Defender for Cloud Apps, review what Cloud Discovery finds, warn on or block what you don't want, and prove it works on a device.
Errors this guide fixes
ExploitGuardNetworkProtectionBlockedAdvanced hunting (DeviceEvents)+1 more guideSmartScreenUrlWarningAdvanced hunting (DeviceEvents)
How it works#
With the integration on, Defender for Endpoint forwards the network signal from onboarded devices to Defender for Cloud Apps, which matches domains against its cloud app catalog and builds a continuous Cloud Discovery report (data source Win10 Endpoint Users). No log collectors are needed. Every catalog app has a risk score out of 10, built from more than 90 risk factors in four groups (General, Security, Compliance and Legal). A higher score means a safer app.
You govern apps with three built-in tags:
| Tag | Meaning | On devices, once enforcement is on |
|---|---|---|
| Sanctioned | Approved for use | Allowed |
| Monitored | Allowed, but discouraged | Warning the user can bypass |
| Unsanctioned | Not allowed | Blocked |
With enforcement on, tagging an app Unsanctioned or Monitored creates custom URL/domain indicators in Defender for Endpoint for its domains, and network protection enforces them. Microsoft documents a worst case of about three hours: up to one hour to sync and up to two more to reach devices.
Prerequisites#
- Licences: Defender for Cloud Apps plus Defender for Endpoint, for example through Microsoft 365 E5.
- Devices: onboarded to Defender for Endpoint, with Microsoft Defender Antivirus real-time protection and cloud-delivered protection on, and network protection in block mode. Discovery doesn't need block mode; blocking and warnings do.
- Platforms: Windows 10 (1809 or later) and Windows 11; also macOS 11+, Android 8.0+, iOS 14.0+ and Linux with network protection.
If network protection isn't deployed yet, my post on web content filtering and network protection with Intune covers it.
Step-by-step#
1. Connect Defender for Endpoint to Cloud Discovery#
- In the Microsoft Defender portal, open Settings › Endpoints › Advanced features.
- Turn on Microsoft Defender for Cloud Apps to forward device network data.
- Turn on Custom network indicators too; blocking depends on it.
2. Review what Cloud Discovery found#
Go to Cloud apps › Cloud discovery and select the Win10 Endpoint Users continuous report. Give it a few days first. On the Discovered apps tab, filter by risk score and category (Cloud storage and Generative AI are good starting points), sort by users or traffic, and open an app to see its risk breakdown and who uses it.
3. Decide: sanction, monitor or unsanction#
A workable rule: sanction what you license and manage, monitor risky apps with a legitimate use, and unsanction high-risk apps and duplicates of tools you already provide. Tag an app from the three dots at the end of its row, or from Cloud apps › Cloud app catalog. A tag alone blocks nothing until step 4, and a few Microsoft services the platform depends on (Defender for Identity, Intune and Purview, for example) can't be blocked at all.
4. Turn on enforcement and user messages#
- Open Settings › Cloud Apps › Cloud Discovery › Microsoft Defender for Endpoint and select Enforce app access. Allow up to 30 minutes for it to take effect.
- Under user warnings, enter a notification URL for blocked apps: a page explaining the policy and the exception process, linked as Visit the Support page on the block page.
- Set the notification URL for warnings (list approved alternatives there) and a bypass duration in hours, after which the warning appears again.
- Optionally turn off Generate alert for blocked app access (preview) if the informational alerts are noise; blocking continues.
5. Pilot with a scoped profile#
- Go to Settings › Cloud Apps › Cloud Discovery › App tags, open the Scoped profiles tab and select Add profile.
- Choose Include and pick your pilot device groups from Defender for Endpoint. An Exclude profile blocks everyone except those groups.
- When you tag an app as Unsanctioned, the Tag as unsanctioned? dialog offers Select a profile. Choose the pilot profile and save.
To widen the block later, remove the Unsanctioned tag and tag the app again without a profile. Tenants licensed only for Defender for Business don't see device groups here.
6. Automate with app discovery policies#
Under Cloud apps › Policies › Policy management, create an App discovery policy matching, for example, the Generative AI category and a risk score below your threshold, with a governance action that tags matching apps as Unsanctioned or Monitored. If a policy and an admin disagree, the most recent action wins.
What users see#
- Microsoft Edge on Windows: a full-page SmartScreen block for Unsanctioned apps, or a warning with an option to continue for Monitored apps, both with your support link.
- Other browsers and platforms: network protection drops the connection; on Windows the user gets a Windows Security notification instead of a page. Microsoft also lists the Microsoft Defender Browser Protection add-on for non-Microsoft browsers as a prerequisite, so deploy it too.
Verify#
- In Settings › Endpoints › Indicators › URLs/Domains, look for indicators created by Defender for Cloud Apps for the app's domains.
- On a pilot device, confirm the enforcement prerequisites:
PowerShell
Get-MpPreference | Select-Object EnableNetworkProtection # 1 = block, 2 = audit, 0 = off Get-MpComputerStatus | Select-Object AMRunningMode, RealTimeProtectionEnabled # Normal, True - Browse to the app in Edge and in another browser: expect the block page and the notification.
- Confirm the events in advanced hunting:
Good looks like rows for your test device and the app's domain;KQL
DeviceEvents | where Timestamp > ago(1d) | where ActionType in ("SmartScreenUrlWarning", "ExploitGuardNetworkProtectionBlocked") | extend AF = parse_json(AdditionalFields) | extend Reason = coalesce(tostring(AF.Experience), tostring(AF.ResponseCategory)) | project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl, ActionType, Reason | order by Timestamp descReasonshows which feature made the call when web content filtering or your own indicators also apply. - In Discovered apps, open the app: its overview shows the applied controls and, for Monitored apps, how many users bypassed the warning.
Tips & gotchas#
- Blocking is per domain. Enforcement uses the domains the catalog lists for the app, so check that list before you unsanction anything that shares infrastructure with a service you need.
- Don't edit the indicators by hand. Defender for Cloud Apps overrides manual scoping on the indicators it creates; use scoped profiles instead.
- Not all traffic comes from Defender for Endpoint. For the rest, use the built-in streams for Zscaler, iboss, Corrata, Menlo or Open Systems, generate a block script, or export the unsanctioned apps' domains for your firewall or proxy.
- Communicate first. Publish the support page and alternatives before the first block.

