Deploying Microsoft Defender for macOS via Intune — The Real Troubleshooting Path

If you've rolled out Microsoft Defender to a Mac fleet through Intune and hit "No license found" even though your licensing is fine, this one's for you.

The setup

Microsoft 365 Business Premium includes Defender for Business, which does support macOS. Intune enrollment was already working. The Defender app was already installed on the Mac devices. And yet Defender showed no license.

That mismatch — app installed, licensing correct, still broken — is the tell. It almost never means the license is actually the problem.

The real root cause

Three things, not one:

• Device onboarding was incomplete
• macOS permission profiles were missing (Full Disk Access, specifically)
• Defender's system extension approvals hadn't gone through

Defender for macOS isn't "install the app and done." It needs a small stack of Intune configuration profiles sitting alongside the app to actually activate.

What not to do

Don't uninstall Defender and don't switch to an App Store deployment to "reset" things. Keep the existing app deployment and layer configuration profiles on top of it. Pilot on one Mac before touching the fleet — this stack has enough moving parts that you want to validate on one device first.

The profile stack that actually works

Built as custom Intune configuration profiles (Devices → macOS → Configuration Profiles → Create → Template → Custom → Device Channel):

1. Full Disk Access profile for Defender
2. Network Filter profile
3. Background Services profile
4. Onboarding profile — upload WindowsDefenderATPOnboarding.xml
5. System Extensions policy (Settings Catalog) — approve Defender's extensions by Team Identifier UBF8T346G9:
   • com.microsoft.wdav.epsext
   • com.microsoft.wdav.netext

One gotcha worth flagging: if you're on Windows packaging these files, macOS .mobileconfig files can silently get saved as .mobileconfig.txt. Turn on file extensions in Explorer before you upload, or Intune will accept a file that doesn't do what you think it does.

Also worth knowing: kext.xml, if you find it in an older onboarding package, is legacy kernel-extension configuration. Modern Defender for macOS deployments run on System Extensions and Network Extensions instead — you generally don't need it.

How to validate — three layers, in order

Don't just check one place. Check all three, in this order:

1. Intune — did the profile actually deploy successfully to the device?
2. The Mac itself — run mdatp health locally. You want to see licensed: true, org_id populated, managed_by: MDM, and full_disk_access_enabled: true.
3. The Defender portal — is the device showing as Onboarded, with an Active health state?

All three agreeing is what "actually working" looks like. Any one of them alone can lie to you.

The last mile: network protection

Even after the device shows Onboarded and Active, you may still see:

network_protection_status : stopped
network_events_subsystem  : unavailable

This isn't a licensing or onboarding problem — by this point those are already fixed. It's the System Extensions approval specifically. Once the Settings Catalog profile above is deployed and the device syncs and reboots, you should land on:

healthy                   : true
network_protection_status : started
network_events_subsystem  : healthy

The takeaways

• Business Premium genuinely does support Defender for macOS — don't let a confusing error message convince you otherwise.
• Never reinstall Defender to "fix" it. The fix is almost always a missing configuration profile, not the app.
• Validate at three layers (Intune, device, portal) — not one.
• Apple extension activation frequently needs a reboot to fully take effect. If health looks right except for network protection, try that before you assume something's broken.