Managing macOS with Intune: Enrollment, Platform SSO, FileVault Escrow, and Declarative Device Management

Managing macOS in Intune is not “Windows management with a different logo.” Apple’s MDM protocol, the move to Declarative Device Management (DDM), and the way Macs authenticate against Entra ID via Platform SSO behave differently enough that a Windows-centric mental model quietly leads you into broken update enforcement and Macs that prompt for two passwords. This guide builds a real macOS baseline end to end: enrollment, Platform SSO, FileVault escrow, DDM updates, app delivery, and gating into Conditional Access.

1. macOS enrollment paths: ADE, account-driven, and BYOD

Three enrollment paths exist, and the one you pick decides how much control you get and whether enrollment is removable by the user.

The pivotal property is supervision. Only supervised Macs (ADE and account-driven device enrollment) can be forced to enable FileVault, enforce OS updates through DDM, block removal of the management profile, and install management silently. User enrollment deliberately limits the org to a managed APFS volume and a managed Apple Account: no serial numbers, no remote wipe, no personal data. Pick the path per device posture, not per convenience.

ADE is the only path where the management profile is non-removable and enrollment survives a wipe-and-reinstall. If a device must stay enrolled no matter what the user does, it must come through Apple Business Manager into ADE. There is no after-the-fact way to make a manually enrolled Mac supervised.

2. Connect Apple Business Manager and manage the enrollment program token

ADE requires a trust relationship between Apple Business Manager (ABM) and Intune, brokered by an enrollment program token (the renamed ADE/DEP token), set up as a three-way certificate exchange.

1. In Intune, go to Devices > Enrollment > Apple > Enrollment program tokens > Add, accept the terms, and download the Intune public key (a .pem).
2. In Apple Business Manager > Preferences > Your MDM Servers > Add, upload that public key, then download the server token (an encrypted .p7m).
3. Back in Intune, upload the server token and supply the Apple ID used to create it. Intune stores it as a named token.
4. In ABM, assign devices (by serial, order number, or all-new-purchases) to the Intune MDM server.

Critically, assign a default enrollment profile to the token: a device that syncs down without one lands in a half-managed state. The token expires after 12 months and silently stops ADE syncs when it lapses — the sync icon in Intune looks fine while no new Macs enroll. Put renewal on a calendar and renew under the same token entry to preserve assignments.

# Renewal reality check (do this on a schedule, not when enrollment breaks):
# 1. ABM > MDM Servers > <your server> > Download Token  (new .p7m)
# 2. Intune > Enrollment program tokens > <token> > Renew token > upload .p7m
# Renewing under the SAME token row keeps all serial-to-profile assignments.

Define the enrollment profile (Setup Assistant experience) under the token: enrollment type Supervised, lock down which Setup Assistant panes appear, and decide whether to Await final configuration (blocks the user at the desktop until critical profiles land — strongly recommended so FileVault and Platform SSO are present before first login completes).

3. Configure Platform SSO

Platform SSO (PSSO) makes the local macOS account authenticate against Entra ID at the login window and unlocks SSO across apps via the Microsoft Enterprise SSO plug-in. Without it, users sign in to the Mac locally and again to every M365 app. PSSO is delivered by the Company Portal app (which carries the SSO extension) plus an Extensible Single Sign-On configuration profile.

Three authentication methods, and the choice is architectural:

Prerequisites: macOS 13+ (14+ strongly preferred for the registration UX), the Microsoft Enterprise SSO plug-in shipped inside Company Portal, and the device registered in Entra ID. Build one Settings Catalog profile combining the SSO extension and the PSSO settings:

{
  "ExtensionIdentifier": "com.microsoft.CompanyPortalMac.ssoextension",
  "TeamIdentifier": "UBF8T346G9",
  "Type": "Redirect",
  "URLs": [
    "https://login.microsoftonline.com",
    "https://login.microsoft.com",
    "https://sts.windows.net"
  ],
  "PlatformSSO": {
    "AuthenticationMethod": "UserSecureEnclaveKey",
    "UseSharedDeviceKeys": true
  }
}

In Intune this is authored under Devices > Configuration > Create > macOS > Settings catalog, category Authentication > Extensible Single Sign On (Platform SSO). Set the extension identifier to com.microsoft.CompanyPortalMac.ssoextension, the team ID to UBF8T346G9 (Microsoft’s Apple Developer Team ID), type Redirect, and select the method. After the profile lands the user gets a registration prompt to bind the local account to Entra ID; until they complete it, PSSO is configured but inert. Surface that prompt in onboarding — unregistered PSSO is the most common “deployed but SSO doesn’t work” ticket.

4. Settings Catalog vs custom .mobileconfig

You have two ways to push configuration, and the default should be Settings Catalog.

• Settings Catalog is Microsoft’s curated, searchable surface over Apple’s MDM payloads. It is versioned, shows per-setting conflict reporting, and is the only place new Apple payloads (including PSSO and DDM) get first-class UI. Reach for it first.
• Custom profile (.mobileconfig) uploads a raw Apple configuration profile you authored in Apple Configurator or iMazing Profile Editor. Use it only for payloads Settings Catalog does not yet expose. The cost: Intune treats it as an opaque blob, so you get no per-setting status — only “profile applied / failed.”

Do not hand-author the PayloadUUID/PayloadIdentifier and then duplicate them across profiles. Two custom profiles sharing an identifier will fight, and because custom profiles report opaquely you will see “applied” on both while the device flaps. Generate UUIDs fresh per profile, and prefer Settings Catalog precisely so you never hit this.

5. Enable FileVault, escrow recovery keys, and rotate them

FileVault is volume encryption; operationally what matters is escrowing the personal recovery key to Intune so you can recover a locked-out Mac. Create a profile under Endpoint security > Disk encryption > Create policy > macOS > FileVault with these settings:

• Enable FileVault: On.
• Escrow location description: a string shown on the recovery-key screen, e.g. “Contact IT Service Desk for your recovery key.”
• Personal recovery key rotation: enable and set an interval (e.g. 90 days) so a key that is ever surfaced becomes stale.
• Defer enablement until user logs out: forces enablement at the next logout, since FileVault must be turned on while a user is present to capture credentials.

On a supervised Mac this enables silently and escrows the key without user action. On user-enrolled Macs you cannot force it. Retrieve a key from Intune > Devices > select the Mac > Recovery keys, or via Graph:

# Retrieve the escrowed FileVault personal recovery key for a macOS device
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.PrivilegedOperations.All"

$deviceId = (Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'macOS' and deviceName eq 'MAC-ENG-014'").Id

Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/beta/deviceManagement/managedDevices/$deviceId/getFileVaultKey"

To rotate on demand (for example after a key was read to unlock a device), the device action is Rotate FileVault recovery key, which instructs the Mac to generate and re-escrow a fresh key on next check-in:

# Force rotation of the personal recovery key after it has been disclosed
Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/beta/deviceManagement/managedDevices/$deviceId/rotateFileVaultKey"

Reading a recovery key is a privileged, audited action. Treat every retrieval as burning that key: rotate immediately after use so the value sitting in someone’s ticket history is already dead.

6. Declarative Device Management for OS updates

This is the single biggest behavioral change in modern macOS management. The legacy MDM ScheduleOSUpdate command model is being retired; Declarative Device Management (DDM) is now how you enforce updates on macOS 14+. Instead of pushing a command and hoping, you declare a target OS version and a deadline, and the Mac’s own software-update daemon enforces it locally and reports status declaratively — even while offline from Intune.

Author it in Intune under Devices > macOS > Update policies for macOS > Create profile. The model has three knobs that actually matter:

• Required minimum OS version (the version string you are driving to, e.g. 15.5).
• Install deadline (a hard date/time after which the install is forced with a restart).
• Target local date/time for the user-facing nudge before the deadline.

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Payload": {
    "TargetOSVersion": "15.5",
    "TargetLocalDateTime": "2026-06-15T03:00:00",
    "TargetBuildVersion": "24F74"
  }
}

Because enforcement is declarative, the user can install early and the device reports satisfied; you are setting a backstop, not a fixed install moment. Two hard constraints: the device must support DDM (macOS 14+), and you must target a version Apple is currently publishing — you cannot force an unreleased build. Set a deadline before the update can realistically download over the user’s link and you generate forced restarts, so give the download window room.

Do not run the legacy “Update policies” and a DDM update profile against the same devices expecting them to cooperate. On macOS 14+ drive updates through DDM only. Mixing the retiring command model with the declarative model is how you end up with Macs that won’t move off an old build while Intune insists everything is compliant.

7. Deploy apps: VPP, PKG/DMG, and shell scripts

Three delivery mechanisms, each for a different artifact:

For App Store apps, sync Apps and Books from ABM (Tenant administration > Connectors and tokens > Apple VPP tokens) and assign with device licensing so machines get apps without a personal Apple Account. For everything bespoke, the Intune MDM agent runs shell scripts and installs DMG/PKG payloads. Shell scripts run as root; pin the interpreter and fail loudly:

#!/bin/bash
# Intune macOS shell script: install a config file, return non-zero on failure
set -euo pipefail

DEST="/Library/Application Support/Acme/agent.conf"
mkdir -p "$(dirname "$DEST")"

if /usr/bin/curl -fsSL "https://config.example.com/agent.conf" -o "$DEST"; then
  /bin/chmod 644 "$DEST"
  echo "agent.conf deployed"
  exit 0
else
  echo "failed to fetch agent.conf" >&2
  exit 1
fi

Intune shell scripts require the Intune agent, which only installs on Macs that are MDM-enrolled in Intune and run with a configurable retry/frequency. They are not a substitute for a real packaging tool — keep them small and idempotent (set -euo pipefail, explicit exit codes), because a script that exits 0 on a silent failure will report “succeeded” forever.

8. Compliance policies and gating macOS into Conditional Access

A baseline is only enforced if non-compliant Macs are denied access. Create a macOS compliance policy (Devices > Compliance > Create policy > macOS) asserting the posture you built: minimum OS version, FileVault required, system integrity (SIP / Gatekeeper), firewall, and a password policy. Set “Mark device noncompliant” with a short grace period.

Then wire it into Conditional Access with a policy that requires a compliant device, scoped to macOS:

• Users: your pilot group first, then all.
• Target resources: All cloud apps (or start with Office 365).
• Conditions > Device platforms: macOS.
• Grant: Require device to be marked as compliant.

The hidden dependency: CA can only read compliance for a device that is registered in Entra ID, which on macOS is established by Company Portal / PSSO registration. A Mac that is MDM-enrolled but never completed that registration has no Entra device record for CA to evaluate, so a “require compliant device” grant simply blocks it. This is why PSSO and Company Portal sign-in belong in the enrollment runbook, not as an afterthought.

Chain that must all be true for access to be granted:
  ADE/supervised enrollment  ->  device managed by Intune
  Company Portal + PSSO registration  ->  Entra device record exists
  Compliance policy satisfied (FileVault, OS version, firewall)  ->  device = compliant
  Conditional Access "require compliant device"  ->  access granted
Break any link and the user is blocked, not warned.

Enterprise scenario

A platform team at a media company rolled out “require compliant device” CA for macOS and immediately locked out roughly 200 engineers. The Macs were genuinely ADE-enrolled and FileVault-encrypted, so the team assumed compliance would flow. The constraint: these Macs were enrolled via ADE before Platform SSO and Company Portal were deployed, so although Intune managed them, no Entra device registration existed — and CA evaluates compliance against the Entra device object, which was absent.

The fix was not to weaken CA. They (1) deployed the Company Portal + PSSO profile to the affected group, (2) used a CA filter to exclude devices with no Entra registration during the remediation window, and (3) tracked PSSO registration completion before removing the exclusion. The filter keyed off the device’s trust type:

# Conditional Access device filter used during PSSO remediation
# Temporarily exclude devices with no Entra registration (trustType blank/unknown)
device.trustType -ne "Workplace" -and device.deviceOSType -eq "MacMDM"

Once registration completed for a cohort, that cohort matched the compliant grant normally and dropped out of the exclusion. The lesson the team wrote into their runbook: on macOS, Intune enrollment and Entra device registration are two separate events, and Conditional Access depends on the second one. Sequence PSSO/Company Portal before you flip the CA grant, or you will DoS your own engineers.

Verify

Confirm each layer independently rather than trusting the green checkmarks in the portal.

• Enrollment / supervision — on the Mac, System Settings > General > Device Management should show the org profile with “This Mac is supervised and managed by <org>.” No “supervised” wording means it came in via user enrollment.
• Platform SSO — in Terminal, app-sso platform -s reports PSSO state and whether registration completed. The login window should accept the Entra password (Password method) or prompt a Secure Enclave registration.
• FileVault + escrow — fdesetup status returns FileVault is On, and Intune > device > Recovery keys shows a key. Run fdesetup status after a forced rotation and confirm Intune holds a new value.
• DDM updates — softwareupdate --list plus the device’s compliance state in Intune should reflect the declared target; the DDM declaration status appears under the device’s monitor blade.
• Apps — VPP app present without an Apple Account sign-in; a deployed PKG visible in /Applications with the detection rule satisfied.
• Conditional Access — sign in to office.com from the Mac; Entra > Sign-in logs should show the CA policy evaluated as Success with “Require compliant device” satisfied, and a populated Device ID.

Checklist

• ABM connected to Intune via enrollment program token; default profile assigned; renewal date on the calendar (token expires in 12 months)
• Enrollment paths chosen per posture: ADE/supervised for corporate, account-driven user enrollment for BYOD
• Setup Assistant profile set to Supervised with Await final configuration enabled
• Platform SSO Settings Catalog profile deployed (extension com.microsoft.CompanyPortalMac.ssoextension, team ID UBF8T346G9, method chosen) and registration step in the onboarding runbook
• FileVault enabled with escrow configured and key rotation (e.g. 90 days); rotation tied to any disclosure
• OS updates driven by DDM update profiles on macOS 14+ (legacy update commands not stacked on the same devices)
• Apps delivered by the right channel: VPP (device licensing), signed PKG LOB apps, DMG/PKG + idempotent shell scripts via the agent
• macOS compliance policy asserting OS version, FileVault, firewall, and Gatekeeper/SIP
• Conditional Access “require compliant device” rolled out after PSSO/Company Portal registration is confirmed for the target population
• Recovery-key retrieval treated as privileged and audited; rotate after every read