Enrolling and securing a macOS device with Intune: from zero to full Defender for Endpoint

Most of my Intune experience up to this point had been Windows-first — a tenant that already had a mature policy baseline. This project started from the opposite end: a Mac already in daily use under a local account, and a tenant that had never enrolled a macOS device before. That meant working through the platform from absolute zero — tenant prerequisites, enrollment, then rebuilding an existing Windows policy set as macOS equivalents, and finally a full Defender for Endpoint deployment now that the client’s on Business Premium.

Phase 1 — Tenant prerequisites (one-time)

Before any Mac can enroll, the tenant needs an Apple MDM Push certificate — this is what lets Intune talk to Apple’s push notification service at all.

Intune admin center → Devices → Enrollment → Apple tab → Apple MDM Push Certificate

The flow is a two-way handshake between Intune and Apple:

1. Generate and download a CSR from Intune
2. Upload that CSR to Apple’s own Push Certificates Portal (identity.apple.com/pushcert), signed in with an Apple ID
3. Download the resulting .pem certificate from Apple
4. Upload that .pem back into Intune, along with the same Apple ID used to generate it

One detail worth getting right from day one: use a shared/company Apple ID for this, not a personal one — ideally something like a distribution list mailbox rather than an individual’s account. The certificate needs renewing every 365 days, and whoever’s Apple ID is tied to it becomes a dependency for that renewal indefinitely.

Beyond the push certificate, two more prerequisites:

• Licensing — every user enrolling a Mac needs an Intune license, whether standalone or bundled via Microsoft 365 E3/E5/Business Premium
• Enrollment restrictions — worth checking Devices → Enrollment restrictions to confirm nothing’s silently blocking the macOS platform, since a restriction here causes the enrollment profile download to fail with a fairly generic, unhelpful error on the Mac side

Since this was user-driven Company Portal enrollment rather than Automated Device Enrollment, there was no Apple Business Manager token needed — that’s genuinely the full tenant-side prerequisite list.

Phase 2 — Enrolling the Mac

With the Mac already in use under a local account, the enrollment path was:

1. On the Mac, browse to aka.ms/EnrollMyMac and download the Company Portal app — worth noting there’s no App Store listing for it, it’s a direct package download
2. Install and open Company Portal, sign in with the user’s work/school account
3. Company Portal opens System Settings → Profiles and prompts to install the management profile
4. The user approves the profile install — this specifically makes it a user-approved MDM enrollment, which unlocks the full policy set. An unapproved enrollment is more limited and blocks several policy types silently.
5. Once approved, the device registers to Microsoft Entra ID and appears under Devices → macOS in Intune

A couple of things worth understanding about this specific enrollment type before treating it as equivalent to a Windows Autopilot-style deployment:

• This enrolls the existing local account’s session — it doesn’t touch or convert the local account itself. Entra-joined features like Platform SSO, or a proper synced local admin/standard account split, need a separate configuration path and typically want Automated Device Enrollment (ADE) instead.
• Because this isn’t ADE/supervised, the end user can remove the management profile themselves later, unless Conditional Access is configured to make that costly by cutting off access to work resources the moment the device falls out of compliance.

Mapping an existing Windows baseline onto macOS

The client already had five Windows Intune configuration profiles in place. Rather than build macOS policy from scratch, the goal was to carry over whatever had a genuine macOS equivalent:

Windows policy	macOS equivalent?	Notes
Defender Baselines	❌ No direct equivalent	The Windows Security Baseline template’s 65 settings (BitLocker CSP, Windows Firewall CSP, Device Installation Control, Edge SmartScreen) are almost entirely Windows-specific. macOS needs separate, purpose-built pieces instead — FileVault for disk encryption, the macOS firewall via Settings Catalog, Gatekeeper/SIP controls via Device Restrictions, and a full Defender for Endpoint deployment for actual AV/EDR
Windows Apps Removal	❌ Doesn’t apply	This strips default UWP/Store apps, which don’t exist on macOS. The closest analogue is hiding certain built-in apps (FaceTime, Podcasts, News, Game Center) via Device Restrictions — a block, not an uninstall, and a fundamentally different mechanism
Restrict Edge Personal Accounts	✅ Yes	The exact same RestrictSigninToPattern setting exists in the Settings Catalog once the profile’s platform is set to macOS — same setting, same value, just a new profile object
Enforce OneDrive Deny Personal	✅ Mostly yes	The core AllowTenantList setting carries over via Settings Catalog. Some Windows-only details (like the Known Folder Move opt-in wizard checkboxes) behave differently on Mac, so KFM specifically needed testing rather than assuming full parity
Edge Home Page and Search Engine	✅ Yes	Standard Edge policies, settable identically via Settings Catalog with the platform switched to macOS

The practical build was three new macOS-specific Settings Catalog profiles mirroring three of the five Windows ones:

Edge — restrict personal accounts:

Platform: macOS | Profile type: Settings catalog
Setting: Restrict sign-in to pattern
Value:   .*@                    # matches any work/school account, blocks personal MSAs

Edge — home page and search engine:

Default search engine name:        Google
Default search engine search URL:  https://www.google.com/search?q={searchTerms}
Default search engine enabled:     Enabled
Restore on startup:                Open a specific page or set of pages
New tab page search box:           Redirect to default search engine
Home page location:                https://www.yourcompany.co.uk/

OneDrive — deny personal accounts:

Allow tenant list:       Enabled → <your Entra tenant ID>
Disable personal sync:   Enabled
Silent account config:   Enabled
Files On-Demand enabled: Enabled
KFM block opt-out:       Enabled
Sync admin reports:      Enabled

One structural point worth flagging: even where a setting is byte-for-byte identical between platforms, it always has to live in its own policy object scoped specifically to macOS — Windows and macOS profiles can’t share a policy, even if every value inside them matches.

Full Microsoft Defender for Endpoint deployment (Business Premium)

With Business Premium in the tenant (which includes Defender for Business), the real macOS equivalent of the Windows Defender Baseline isn’t a single policy — it’s a full multi-profile Defender for Endpoint deployment. Microsoft’s own guidance runs to 15 sequential steps, and several of them use pre-built .mobileconfig files rather than hand-typed settings, specifically because getting a bundle identifier wrong causes Defender to silently ignore the profile rather than throw an error.

Prerequisite — connect Defender to Intune:

Intune admin center → Endpoint security → Microsoft Defender for Endpoint
  → "Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations" → On

If connection shows Unavailable:
security.microsoft.com → Settings → Endpoints → General → Advanced features
  → "Intune connection" → On → Save

Step 1 — Approve system extensions. Settings Catalog → System Configuration → System Extensions → Allowed System Extensions:

com.microsoft.wdav.epsext   Team ID: UBF8T346G9
com.microsoft.wdav.netext   Team ID: UBF8T346G9

Step 2 — Network filter. A Templates → Custom profile uploading Microsoft’s netfilter.mobileconfig as-is (a signed-structure plist — not something to hand-edit). This is what approves Defender’s Network Extension to inspect socket/connection traffic without popping a user-facing consent dialog. Deployed at the device channel, not per-user.

⚠️ Only ever one network filter profile per tenant — Microsoft is explicit that a second one breaks macOS networking entirely on affected devices, not just Defender.

Steps 3–8 — supporting .mobileconfig profiles, all Templates → Custom, each a pre-built file from Microsoft’s mdatp-xplat GitHub repo:

Step 3 — Full Disk Access         fulldisk.mobileconfig
Step 4 — Background Services      background_services.mobileconfig   (required on Ventura+)
Step 5 — Notifications            notif.mobileconfig                 (edit ShowNotificationCenter if needed)
Step 6 — Accessibility settings   accessibility.mobileconfig
Step 7 — Bluetooth permissions    bluetooth.mobileconfig             (only if using Device Control)
Step 8 — Microsoft AutoUpdate     com.microsoft.autoupdate2.mobileconfig

Step 9 — Antivirus/EDR configuration. Two valid routes here:

• Defender portal route (recommended): security.microsoft.com → Configuration management → Endpoint security policies → Mac policies → create a policy from the Microsoft Defender Antivirus template, then repeat for Endpoint detection and response
• Intune custom-profile route: copy Microsoft’s recommended preferences XML and upload as a Templates → Custom profile — with one hard requirement: the custom configuration profile name must be exactly com.microsoft.wdav. Any deviation and Defender silently ignores the whole profile.

Steps 10 (Network protection) and 11 (Device Control) don’t need separate profiles — both ride along inside the Step 3 and Step 9 templates respectively.

Step 12 — Publish the app itself:

Apps → macOS → Create → App type: Microsoft Defender for Endpoint → macOS → assign to macOS group

Steps 13–14 — onboarding package. Downloaded from security.microsoft.com → Settings → Endpoints → Device management → Onboarding (OS: macOS, Deployment method: MDM/Intune), then the WindowsDefenderATPOnboarding.xml inside the unzipped package gets uploaded as a final Templates → Custom profile.

Step 15 — Verification. On the Mac itself: System Settings → General → Device Management should list every profile above plus the management profile and onboarding package, and the Defender menu bar icon should be present. Confirmed working end to end with Microsoft’s official EICAR-based antivirus detection test — Defender caught and cleared the test file — followed by checking security.microsoft.com → Device inventory to confirm the Mac was genuinely phoning home to the tenant, not just protecting locally.

What’s actually portable to another tenant

Since this build is reusable as a template for future client deployments, it was worth working out exactly what could be exported and reused versus what’s tenant-specific:

Portable as-is:

• The System Extensions approval profile (UBF8T346G9 is Microsoft’s own Team ID, not tenant-specific)
• Full Disk Access, Background Services, Notifications, Accessibility, Network Filter, AutoUpdate — all generic Microsoft .mobileconfig files with no tenant data baked in
• Edge homepage/search engine values
• FileVault configuration
• The Antivirus/EDR Settings Catalog values themselves

Must be regenerated per tenant:

• OneDrive’s AllowTenantList value — this is the literal Entra tenant GUID. Reused on another tenant, it either does nothing useful or allows sign-in to the wrong tenant entirely.
• The Defender onboarding package — WindowsDefenderATPOnboarding.xml contains an org-specific onboarding identifier. Reusing one tenant’s file on another’s device would fail to onboard at best, or silently onboard their device into the wrong Defender tenant at worst. This file has to be freshly downloaded from each target tenant’s own Defender portal — it’s never safe to copy.
• Group assignments — any exported policy JSON references Entra group GUIDs specific to the source tenant; these never carry over cleanly on import and need reassigning regardless.
• The Apple MDM Push certificate — tied to both the Apple ID and the tenant that generated it, from the very first step. Every new tenant needs its own generated from scratch; there’s no export path for this piece at all.

Result

A macOS device taken from an unmanaged local-account Mac to a fully enrolled, policy-managed, Defender-protected endpoint — Edge and OneDrive locked down to match the existing Windows baseline where a genuine equivalent existed, and a complete 15-step Defender for Endpoint deployment verified end-to-end with a real detection test. The reusability audit at the end means most of this build is now a template for the next macOS tenant, with a clear, short list of exactly what needs regenerating rather than reusing each time.