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 through Platform SSO behave differently enough that a Windows-centric mental model quietly leads you into broken update enforcement, Macs that prompt for two passwords, and — the most expensive failure of all — a fleet that is genuinely encrypted and enrolled yet gets locked out of every Microsoft 365 app the day you flip on Conditional Access. The Mac fleet is small enough to be an afterthought and important enough (it is your engineers, your designers, your executives) that an afterthought is unacceptable.

The core reason macOS is different is that on a Mac, enrollment into Intune and registration into Entra ID are two separate events. On Windows, an Entra join does both in one motion; on macOS, a device can be fully MDM-managed by Intune while having no Entra device object at all — and Conditional Access evaluates compliance against the Entra device object. Miss that and you build a perfect baseline that blocks the very users it was meant to protect. This guide builds the whole baseline in the right order: enrollment (ADE, account-driven, BYOD, and the Setup Assistant), Platform SSO with its three authentication methods, FileVault with recovery-key escrow and rotation, DDM-driven OS updates, app delivery (VPP, signed PKG, DMG/PKG via the agent, and unmanaged apps), shell scripts and custom attributes, compliance, and finally Conditional Access — sequenced so the last step never DoSes your own users.

By the end you will be able to enrol a corporate Mac zero-touch through Apple Business Manager, wire Platform SSO so a single Entra credential unlocks the Mac and every M365 app, escrow and rotate FileVault keys, enforce a target macOS version with a deadline that the Mac’s own daemon honours even while offline, deliver apps through the correct channel for each artifact, and gate the whole fleet into Conditional Access without the “we locked out 200 engineers” incident that this article’s real-world scenario is built around. Every operation gets the exact Intune portal path, a real Settings Catalog payload or Graph call, and the confirming command you run on the Mac itself.

What problem this solves

The pain shows up in three predictable places. First, authentication friction: without Platform SSO, a user signs in to macOS with a local password and again to Outlook, Teams, OneDrive, and the browser — every app, every token expiry. It is death by a thousand prompts, and it trains users to click “stay signed in” and accept every dialog, which is its own security problem. Second, update drift: the legacy MDM “push a command and hope” update model is being retired, and teams that keep using it find Macs stubbornly parked on an old, vulnerable build while Intune’s dashboard cheerfully reports everything compliant. Third, and most damaging, the Conditional Access lockout: a team enables “require compliant device” for macOS, and because those Macs were enrolled before Platform SSO existed, they have no Entra device record, so the compliant-device grant has nothing to evaluate and simply blocks them.

What breaks without a proper baseline is not subtle. A stolen laptop with FileVault off is a plaintext disk of company data. A Mac enrolled via user enrollment (personal, unsupervised) cannot be forced to encrypt, cannot be remote-wiped fully, and cannot have its OS updates enforced — so treating it like a corporate device is a false sense of control. A recovery key read into a help-desk ticket and never rotated is a permanent backdoor sitting in ticket history. And an update deadline set shorter than the time it takes to download the update over a home DSL link generates forced restarts in the middle of the workday.

Who hits this: any Microsoft-shop enterprise that has more than a handful of Macs — which today is essentially every enterprise, because engineering, design, and executive populations skew Apple. It bites hardest on teams whose muscle memory is Windows: they reach for Group Policy analogues, expect Entra join to register the device, and assume “encrypted” equals “compliant.” To frame the whole field before the deep dive, here is every layer this article builds, the question it forces, and the single fact a Windows admin gets wrong about it:

Learning objectives

By the end of this article you can:

• Choose the correct enrollment path per device posture — ADE via Apple Business Manager for corporate zero-touch, account-driven device enrollment for corporate off-catalog, account-driven user enrollment for BYOD — and explain exactly what supervision unlocks and what user enrollment forbids.
• Connect Apple Business Manager to Intune via the enrollment program token, assign a default enrollment profile, and manage the 12-month token renewal so ADE never silently stops.
• Configure Platform SSO with the Microsoft Enterprise SSO plug-in (shipped inside Company Portal) and pick the right authentication method — Secure Enclave, password, or smart card — for your assurance level, then drive users through the registration prompt that actually activates it.
• Enable FileVault, escrow the personal recovery key to Intune, retrieve it via the portal or Graph, and rotate it on demand — treating every retrieval as burning the key.
• Enforce macOS OS updates with Declarative Device Management: declare a target version and deadline that the Mac’s own software-update daemon honours locally and reports declaratively, even while offline — and avoid stacking the retiring command model on the same devices.
• Deliver apps through the right channel: VPP with device licensing (no Apple Account), signed PKG line-of-business apps, DMG/PKG via the Intune agent with detection rules, and unmanaged App Store apps — and know the trade-off of each.
• Run shell scripts and custom attributes idempotently as root via the agent, and know when a script is the wrong tool versus a real packaging step or a DDM/Settings Catalog control.
• Author a macOS compliance policy and wire it into Conditional Access after Platform SSO/Company Portal registration is confirmed, so the compliant-device grant never blocks a device that has no Entra record.

Prerequisites & where this fits

You should already understand the Intune fundamentals: that configuration profiles, compliance policies, and apps are assigned to Entra ID groups; that assignment supports include/exclude and filters; and that Intune is the MDM authority for your tenant. Comfort with the Microsoft Graph (via PowerShell or REST) helps, because several macOS operations — reading a FileVault key, checking enrollment token expiry — are cleaner through Graph than the portal. You need Global Administrator or Intune Administrator to configure the connectors, an Apple Business Manager (or Apple School Manager) tenant to do ADE, and at least one test Mac on macOS 14 (Sonoma) or later — 14+ is where Platform SSO registration and DDM are first-class. On the Entra side you need a Conditional Access-capable licence (Entra ID P1 or P2) to gate access.

This sits in the Endpoint Management track alongside the Windows-focused Intune articles, and it depends heavily on the Conditional Access work. The compliance-and-gating layer here is the macOS-specific application of the pattern covered in Gating Microsoft 365 with Endpoint Conditional Access: Compliance Policies, Device Filters, and Require-Compliant Enforcement, and the policy framework behind those CA rules is Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters. The assignment and rollout discipline — pilot rings, filters, precedence — comes from Mastering Intune Assignment Filters and Ring Deployment: Targeting Logic, Precedence, and Safe Rollouts. For BYOD Macs that you don’t want to fully manage, the containment pattern is Intune App Protection Policies for BYOD: Securing Microsoft 365 Data Without MDM Enrollment. A quick map of who owns what during a macOS rollout, so you route decisions correctly:

Core concepts

Six mental models make every later decision obvious.

Supervision is the master switch. A Mac is either supervised (enrolled through ADE or account-driven device enrollment) or unsupervised (account-driven user enrollment / BYOD). Supervision is what lets Intune force FileVault, enforce OS updates through DDM, block removal of the management profile, and install management silently. User enrollment deliberately withholds all of that: it gives the org a managed APFS volume and a managed Apple Account, and nothing more — no serial number, no full wipe, no forced encryption. You choose per device posture, not per convenience. There is no supported way to make a manually enrolled Mac supervised after the fact; it must come through Apple Business Manager into ADE.

Enrollment and registration are two events. On a Mac, being managed by Intune (MDM) and being registered in Entra ID (a device object) are separate. MDM enrollment is Apple’s protocol; Entra registration is what Company Portal (and Platform SSO) establishes. Conditional Access reads compliance from the Entra device object. A Mac can be flawlessly MDM-managed and 100% FileVault-encrypted yet have no Entra record — and a “require compliant device” grant will block it, because there is no device object to evaluate as compliant. This one fact is behind the most common and most painful macOS-CA incident.

Platform SSO puts the Entra credential at the login window. Without it, the local macOS account and the Entra identity are unrelated; the user authenticates twice — once to the Mac, once (repeatedly) to every cloud app. Platform SSO (PSSO), delivered by the Microsoft Enterprise SSO plug-in that ships inside the Company Portal app, binds the local account to Entra ID and provides SSO to apps via the extension. It has three authentication methods (Secure Enclave, password, smart card) that are architecturally different, not cosmetic. Crucially, deploying the profile only configures PSSO; the user must complete a registration prompt to activate it, and until they do, PSSO is inert.

DDM is declarative, not imperative. The legacy MDM model pushed a command (ScheduleOSUpdate) and hoped the device obeyed. Declarative Device Management flips this: you declare a desired state (target OS version, deadline), the Mac’s own software-update daemon enforces it locally and reports status declaratively — and it keeps enforcing even when the device is offline from Intune. You set a backstop, not a fixed moment; the user can satisfy the declaration early. On macOS 14+ this is how you enforce updates, and mixing it with the retiring command model is a recipe for stuck builds.

Settings Catalog is the default authoring surface. Almost everything you configure — PSSO, FileVault, DDM, Wi-Fi, restrictions — is authored in the Settings Catalog, Microsoft’s curated, searchable, versioned surface over Apple’s raw MDM payloads. It reports per-setting status and conflicts. The escape hatch is a custom profile (a raw .mobileconfig you author in Apple Configurator or iMazing Profile Editor) for payloads the catalog does not yet expose — at the cost of opaque, per-profile-only status. Reach for Settings Catalog first, always.

The management surface is Apple’s, mediated by Intune. Everything Intune does to a Mac is an Apple MDM/DDM operation under the hood. Intune is the authority and the console, but the capabilities, the limits, and the “supervised-only” gates are Apple’s. This is why “can I do X on macOS?” is often answered by Apple’s platform rules, not Intune’s UI — and why some Windows features simply have no macOS equivalent.

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary at the end repeats these for lookup; this table is the mental model side by side:

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 the user can remove enrollment. The pivotal property, again, is supervision — the difference between “we can enforce it” and “we can only ask.”

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 of the whole device, no personal data, no forced encryption. 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.

Here is what supervision actually buys, capability by capability — the grid that settles “why can’t I force that on this Mac?”:

Account-driven user enrollment (BYOD) — the deliberate ceiling

Account-driven user enrollment is Apple’s privacy-preserving BYOD model. The user adds their work account and macOS creates a managed APFS volume for corporate data, cryptographically separated from personal data. The org manages that volume and its apps, and nothing else. You cannot force FileVault (the whole disk is the user’s), cannot read the serial number, cannot wipe the machine — only the managed data. This is a feature, not a limitation: it lets you put corporate data on a personal Mac with real containment. For BYOD Macs, this plus App Protection Policies is usually the right posture rather than trying to manage the device fully.

Account-driven device enrollment — corporate, but removable

If a Mac was bought outside your Apple Business Manager relationship (retail, a reseller not linked to ABM, an existing machine), you cannot ADE it. Account-driven device enrollment gives you a supervised device — so FileVault-force and DDM work — but the profile is removable by the user and enrollment does not survive a wipe. It is the practical path for the fleet you couldn’t route through ABM, with the understanding that a determined user can un-enrol. Where possible, buy through ABM channels so new machines land in ADE.

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). It is a three-way certificate exchange between you, Apple, and Intune, and every step matters.

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 (a Managed Apple ID from ABM) used to create it. Intune stores it as a named token.
4. In ABM, assign devices (by serial, by order number, or all future 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 12 months after creation and silently stops ADE syncs when it lapses — the sync icon in Intune looks fine while no new Macs enrol. Put renewal on a calendar and renew under the same token entry to preserve all serial-to-profile assignments. The token lifecycle in one table:

There is a second, easily-forgotten Apple credential: the Apple MDM Push (APNs) certificate, which authorises Intune to push MDM notifications to all Apple devices (iOS and macOS). It is separate from the enrollment token, also renews annually, and if it lapses all Apple management stops, not just ADE. Renew it with the same Apple ID it was created with, or you re-enrol every Apple device.

# Renewal reality check (do both on a schedule, not when enrollment breaks):
#
# Enrollment program token (ADE), 12-month expiry:
#   1. ABM > Preferences > MDM Servers > <server> > Download Token   (new .p7m)
#   2. Intune > Enrollment program tokens > <token> > Renew token > upload .p7m
#   (Renew under the SAME token row -> all serial-to-profile assignments preserved.)
#
# Apple MDM Push (APNs) certificate, 12-month expiry, breaks ALL Apple mgmt if lapsed:
#   Intune > Devices > Enrollment > Apple > Apple MDM Push certificate > Renew
#   MUST use the same Apple ID that created it.

You can audit token expiry via Graph rather than eyeballing the portal — worth wiring into a scheduled check:

# List Apple enrollment (DEP) tokens and their expiration dates
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"

Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/beta/deviceManagement/depOnboardingSettings" |
  Select-Object -ExpandProperty value |
  ForEach-Object { [pscustomobject]@{ Token=$_.tokenName; AppleId=$_.appleIdentifier; Expires=$_.tokenExpirationDateTime } }

The Setup Assistant: the enrollment profile

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

The single most valuable setting here is Await final configuration. Without it, the user reaches the desktop, starts working, and then FileVault, PSSO, and compliance profiles trickle in — meaning there is a window where the device is on, logged in, and unencrypted/unregistered. With it, the desktop is gated until the baseline is present. It is the macOS equivalent of the Windows Autopilot Enrollment Status Page.

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 — you need both: the app provides the extension binary, the profile configures it.

The three authentication methods are architecturally different, and the choice is a security decision:

Secure Enclave is the modern default: a key bound to the Mac’s hardware becomes the credential, the Entra password is never synced to the Mac, and it is phishing-resistant. Password mode syncs the Entra password to the local account so there is genuinely one password everywhere — simplest for users, but the Entra password now lives on the device. Smart card is for environments already invested in PIV/CAC hardware. Prerequisites: macOS 13+ (14+ strongly preferred for the registration UX), the Enterprise SSO plug-in shipped inside Company Portal, and the device registered in Entra ID (which Company Portal establishes). 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). The three fields you must get exactly right:

The AuthenticationMethod string maps to the UI choice: UserSecureEnclaveKey (Secure Enclave), Password (password), UserSmartCard (smart card). After the profile lands, the user gets a registration prompt (a notification / dialog) 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 single most common “deployed but SSO doesn’t work” ticket. The PSSO lifecycle in states:

To confirm PSSO state on the Mac itself, app-sso platform -s in Terminal reports whether registration completed and which method is active — the ground truth when the portal and the device disagree.

Settings Catalog vs custom .mobileconfig

You have two ways to push configuration, and the default should almost always 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.”

The decision and its consequences:

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. The corollary: the same setting configured in both a custom profile and Settings Catalog is a conflict Intune can’t reconcile cleanly — pick one surface per setting and stick to it. This is the same “settings as code, avoid drift” discipline that the Building Intune Configuration Profiles with the Settings Catalog and ADMX Ingestion article drills for Windows; on macOS the stakes are higher because the custom-profile escape hatch is opaque.

Enable FileVault, escrow recovery keys, and rotate them

FileVault is APFS full-disk 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:

On a supervised Mac this enables silently and escrows the key without user action. On user-enrolled Macs you cannot force it — the disk is the user’s. FileVault must be turned on while a user is present (their credentials become an unlock path), which is why “defer enablement until user logs out” exists: it schedules enablement for the next logout when a credential is available to capture. 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. The FileVault operations and their meaning:

Two failure modes to pre-empt. First, encryption on but escrow absent: if FileVault was enabled by the user (not by policy) before the device was managed, the key may not be escrowed to Intune — the profile enforces going forward, but the existing key isn’t automatically captured. Confirm the portal actually shows a key, not just that fdesetup status says On. Second, rotation vs. an in-flight recovery: don’t schedule rotation so aggressively that a key you just handed a user for a genuine recovery is invalidated before they’ve used it — 90 days is a sane hygiene interval; on-demand rotation is the tool for after a disclosure.

Declarative Device Management for OS updates

This is the single biggest behavioural 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. The device is doing the enforcing; Intune is stating the goal.

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

{
  "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. DDM vs. the legacy command model, side by side:

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. Beyond the enforcement declaration, DDM also underpins status subscriptions (the device proactively reports state changes) and software-update settings (deferrals, allowed update behaviours) — but the enforcement declaration above is the one that changes your update posture from “hope” to “guarantee.” Common DDM update outcomes and what they mean:

Deploy apps: VPP, PKG, DMG, and unmanaged

Four delivery mechanisms, each for a different artifact and licensing model. Match the app to the channel:

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. This is the cleanest channel: license count is tracked in ABM, installs are silent on supervised devices, and there’s no personal Apple ID involved. The VPP licensing models:

Line-of-business vs. agent-installed apps

For everything bespoke you have two paths, and the distinction is about how the artifact installs:

• Line-of-business (LOB) app — a signed, distribution-style .pkg installed via the MDM InstallEnterpriseApplication command. Best for vendor PKGs that are proper signed product archives. If the PKG isn’t a signed product archive (a bare component package, or unsigned), this path fails — many vendor PKGs need re-wrapping.
• macOS app (DMG/PKG via agent) — the Intune agent downloads and installs a .dmg or .pkg, supporting detection rules and larger/complex installers. This is the more forgiving path for messy real-world installers, but it requires the agent (which only installs on MDM-enrolled Macs).

Shell scripts and custom attributes

The Intune agent also runs shell scripts (arbitrary management logic as root) and custom attributes (a script whose output becomes an inventory property in Intune). 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

A custom attribute is a script that prints a value; Intune captures stdout and surfaces it on the device record. Use it to inventory anything the built-in properties don’t cover — for example, whether a specific security agent is running:

#!/bin/bash
# Custom attribute: report whether the CrowdStrike falcon sensor is loaded
if /usr/bin/pgrep -q "falcond"; then
  echo "Running"
else
  echo "NotRunning"
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. The scripting surface and its rules:

When not to use a shell script: if a Settings Catalog setting or a DDM declaration does the job, use that instead — declarative state is enforced and reported; a script runs once (or on a schedule) and reports only what you make it report. Scripts are the escape hatch, like the Intune Remediations at Scale pattern on Windows: powerful, but the last resort, not the first.

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 so users get a window to remediate before losing access. The compliance settings that matter on macOS:

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 — and the entire reason this article exists in the order it does — is that Conditional Access 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"->  access granted
Break any link and the user is BLOCKED, not warned.

The safe rollout sequence — the order that prevents the lockout:

Architecture at a glance

Picture the macOS management stack as a left-to-right pipeline where each stage produces a fact the next stage depends on — and where the whole thing gates, at the far right, into Microsoft 365 access. Read it as four connected zones.

On the far left is Apple’s control plane: Apple Business Manager holds your purchased devices and the tokens, and it is wired to Intune by two annually-renewed credentials — the enrollment program token (authorises ADE) and the Apple MDM Push (APNs) certificate (authorises Intune to notify all Apple devices). Devices assigned to your Intune MDM server flow rightward into enrollment. This zone is the source of supervision: a device that comes through here into ADE is supervised and non-removable; anything else is a lesser posture.

The second zone is the device itself during and after enrollment. A supervised Mac runs the Setup Assistant (with panes you locked and “Await final configuration” holding the desktop) and receives, from Intune, a stack of Settings Catalog profiles: the Platform SSO extension config, the FileVault disk-encryption policy, and the DDM update declaration. Two distinct things happen on this Mac that a Windows admin conflates: MDM enrollment (Apple’s protocol, done) and Entra device registration (established when the user signs into Company Portal and completes the PSSO registration prompt). The FileVault policy encrypts the disk and escrows the recovery key back to Intune — a left-pointing arrow, because the key travels from device to console. The DDM declaration is enforced locally by the Mac’s software-update daemon, which reports state back declaratively.

The third zone is Entra ID. Company Portal / PSSO registration produces the Entra device object — the single most important artifact in the whole picture, because it is what Conditional Access evaluates. Alongside it, Intune’s compliance policy stamps the device compliant or noncompliant based on the posture the second zone built (FileVault on, OS at the DDM target, firewall enabled, SIP/Gatekeeper healthy). Compliance state and the device object live together here.

The fourth zone is the gate: Conditional Access with a “require compliant device” grant, scoped to the macOS platform. A sign-in from the Mac is allowed only if the Entra device object exists and it is marked compliant. This is where the chain is unforgiving — every earlier stage is a prerequisite, and the failure mode is a hard block, not a warning. The mental model to carry away: supervision → enrollment → registration → compliance → access, four arrows, and a break anywhere upstream surfaces as a locked-out user at the far right. The reason this article sequences PSSO/Company Portal before flipping the CA grant is precisely this diagram: the “access granted” arrow at the end has no source unless the “Entra device object” node in zone three was populated first.

Real-world scenario

Meridian Studios, a 900-person media company, runs about 320 Macs — the entire creative, engineering, and post-production population — alongside a Windows back office. The platform team is five people; the Macs had drifted in over years, enrolled via ADE as they were purchased, FileVault turned on device-by-device, and updates left to “whenever the user gets the nudge.” Management had been reactive: a support tool here, a config profile there, no coherent baseline. The mandate arrived after a laptop was stolen from a car and nobody could confirm whether its disk was encrypted or its recovery key retrievable. The security team wanted one thing: Conditional Access “require compliant device” for every Mac, so a non-encrypted or out-of-date machine cannot reach Microsoft 365.

The team did the responsible-looking thing and moved fast. They authored a macOS compliance policy (FileVault required, minimum OS 15.4, firewall on), confirmed on a sample of five Macs that they were genuinely ADE-enrolled and FileVault-encrypted, and — reasonably, they thought — assumed compliance would flow. On a Tuesday morning they enabled a CA policy requiring a compliant device for all cloud apps, scoped to macOS, targeted at everyone. Within twenty minutes the help desk was on fire: roughly 200 engineers and editors could not open Outlook, Teams, or anything on the web that required sign-in. The Macs were fine. FileVault was on. The devices were managed. And they were all blocked.

The breakthrough was asking what CA actually evaluates. It evaluates the Entra device object, and those Macs — enrolled via ADE before Platform SSO and Company Portal were ever deployed — had no Entra device registration. Intune managed them through Apple’s MDM protocol, but no Entra device record existed for Conditional Access to look at. A “require compliant device” grant with no device object to evaluate does not fail open; it blocks. The five test Macs that “worked” during validation were the team’s own machines, which happened to have Company Portal installed from earlier experiments — so they were registered, which is exactly why the test gave a false green light.

The fix was not to weaken CA. They did three things. First, they immediately added a Conditional Access filter to exclude devices with no Entra registration during a remediation window — using a device filter keyed off the trust type — so the 200 blocked users could work while the real fix rolled out. Second, they deployed the Company Portal + PSSO Settings Catalog profile (Secure Enclave method) to the whole Mac fleet and drove users through the registration prompt via a comms campaign (“you’ll see a sign-in prompt from Company Portal — complete it, it takes 30 seconds”). Third, they tracked PSSO/Entra registration completion per cohort, and as each cohort registered and matched the compliant grant, it dropped out of the exclusion filter.

# 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"

Within nine days the whole fleet was registered, compliant, and inside the “require compliant” grant with the exclusion filter removed. The lasting cost was avoidable: a morning of ~200 blocked users, a full incident bridge, and a security team briefly told “your control locked out the company.” The lesson written into their runbook, in bold, was the sentence this article is built to prevent you needing: on macOS, Intune enrollment and Entra device registration are two separate events, and Conditional Access depends on the second one. They also rewrote their validation to test against a representative Mac (one enrolled the way the fleet was, without prior Company Portal), not an admin’s already-registered machine. Sequence PSSO/Company Portal before you flip the CA grant, pilot it, and you never DoS your own engineers.

Advantages and disadvantages

Managing macOS through Intune consolidates Apple and Microsoft device management into one console and one compliance/Conditional-Access story — which is the whole appeal — but the Apple platform’s rules and the enrollment-vs-registration split impose real constraints. Weigh it honestly:

The model is right for any Microsoft-shop enterprise that wants a single endpoint and identity story across mixed hardware — which is almost all of them. It bites hardest on teams that assume Windows semantics (Group Policy, Entra-join-registers-everything, encrypted-means-compliant) and on fleets bought outside ABM (stuck at removable enrollment). Every disadvantage is manageable — buy through ABM, deploy Company Portal early, prefer Settings Catalog, drive DDM on 14+ — but only if you know it exists, which is the point of this article. If your Mac population is genuinely BYOD and you don’t want to manage the hardware, the right answer isn’t fuller MDM — it’s App Protection Policies, and you skip most of this stack.

Hands-on lab

Build a minimal but real macOS baseline: connect ABM (conceptually, since it needs an Apple tenant), then author and assign the three profiles that matter — Platform SSO, FileVault, and a compliance policy — and validate on a test Mac. Where an Apple tenant is required, the step notes what you’d do; the Intune-side authoring is fully reproducible in any tenant with an Intune licence and a test Mac on macOS 14+.

Step 1 — Confirm Apple connectors (prerequisite check). In Devices > Enrollment > Apple, confirm the Apple MDM Push certificate is present and not expiring soon, and (if you have ABM) that an enrollment program token exists with a default profile assigned.

# Verify the APNs push certificate and any DEP tokens exist and their expiry
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/beta/deviceManagement/applePushNotificationCertificate" |
  Select-Object appleIdentifier, expirationDateTime

Expected: an appleIdentifier (the Apple ID that owns the cert) and an expirationDateTime comfortably in the future.

Step 2 — Create the Platform SSO profile (Settings Catalog). In Devices > Configuration > Create > New policy > macOS > Settings catalog, add category Authentication > Extensible Single Sign On (Platform SSO). Set Extension Identifier com.microsoft.CompanyPortalMac.ssoextension, Team Identifier UBF8T346G9, Type Redirect, Authentication Method UserSecureEnclaveKey. Assign to a pilot group of test users.

Expected: the profile lists a single Extensible SSO payload; assignment shows your pilot group.

Step 3 — Create the FileVault policy. In Endpoint security > Disk encryption > Create policy > macOS > FileVault: Enable FileVault On; Escrow location description “Contact IT Service Desk for your recovery key.”; Personal recovery key rotation On, interval 90 days; Defer enablement until user logs out On. Assign to the pilot group.

Expected: policy created with FileVault enabled and rotation set; assigned to pilot.

Step 4 — Create the compliance policy. In Devices > Compliance > Create policy > macOS: Require FileVault; Minimum OS version (e.g. 15.4); Firewall enabled; System Integrity Protection on; noncompliance action “Mark device noncompliant” with a 1-day grace period. Assign to the pilot group.

Expected: a macOS compliance policy asserting encryption, OS floor, and firewall.

Step 5 — Enrol / sync the test Mac and install Company Portal. On the test Mac (macOS 14+), if not ADE-enrolled, enrol via account-driven device enrollment (System Settings > add work account) or install Company Portal and sign in. Signing into Company Portal is what establishes the Entra device registration — do not skip it.

Expected: System Settings > General > Device Management shows the org’s management profile; for supervised paths it reads “This Mac is supervised and managed by <org>.”

Step 6 — Complete PSSO registration. After the SSO profile lands, the Mac shows a registration prompt. Complete it (Secure Enclave will prompt for the Entra credential once to bind). Confirm state in Terminal:

# Report Platform SSO state and whether registration completed
app-sso platform -s

Expected: output indicating PSSO is configured and registered (registration complete / login state present).

Step 7 — Validate the baseline on the device.

# FileVault is on
fdesetup status
# -> "FileVault is On."

# The OS meets the compliance floor (compare against your minimum)
sw_vers -productVersion
# -> e.g. 15.5

# Confirm the management profile is installed
profiles status -type enrollment
# -> "Enrolled via DEP: Yes/No" and "MDM enrollment: Yes"

Expected: FileVault On; OS version at or above your floor; MDM enrollment Yes.

Step 8 — Validate escrow and compliance in Intune. In Intune > Devices > select the Mac: Recovery keys shows a FileVault key; the device shows Compliant; the Entra device object exists (Entra > Devices). Only now would you scope a “require compliant device” CA policy to this pilot group.

Validation checklist. You authored PSSO, FileVault, and compliance; enrolled a Mac; established Entra registration via Company Portal; completed PSSO registration; and confirmed FileVault On + key escrowed + device Compliant + Entra object present — the exact chain Conditional Access needs. The lab steps mapped to what each proves:

Teardown. Remove the pilot assignments (or delete the policies), and on the test Mac remove the management profile (System Settings > Device Management > remove for removable enrollments) or wipe/re-enrol for ADE. No cloud resources incur cost; the only “cost” is the pilot Mac’s time.

Common mistakes & troubleshooting

This is the playbook — the part you bookmark. First as a scannable table, then the entries that bite hardest with full detail.

The expanded form for the entries that cost the most time:

1. Compliant, encrypted Macs are blocked by a “require compliant device” CA policy. Root cause: The Macs are MDM-enrolled by Intune but have no Entra device object, because enrollment and Entra registration are separate events on macOS — CA evaluates the (absent) device object and blocks. Confirm: Entra > Devices does not list the Mac; on the device app-sso platform -s shows PSSO not registered. Fix: Deploy Company Portal + the PSSO Settings Catalog profile, drive users through the registration prompt, confirm the Entra device object appears, then enable the CA grant (pilot first). During remediation, exclude unregistered devices with a CA device filter so you don’t block users.

2. Platform SSO is “deployed” but users still authenticate twice. Root cause: The profile configured PSSO but the user never completed the registration prompt, so PSSO is inert. Confirm: app-sso platform -s reports not registered; the login window doesn’t offer the Entra credential. Fix: Make the registration prompt part of onboarding comms; the user completes it once (Secure Enclave binds a hardware key, password mode syncs the Entra password). Re-trigger by re-syncing the device or re-signing into Company Portal.

3. New Macs quietly stop enrolling while the sync looks healthy. Root cause: The enrollment program token expired (12 months from creation); ADE syncs stop but the portal’s sync UI still looks normal. Confirm: Graph GET /deviceManagement/depOnboardingSettings shows tokenExpirationDateTime in the past. Fix: Download a fresh .p7m from ABM and renew under the same token row in Intune to preserve serial-to-profile assignments. Put annual renewal on a calendar.

4. Every Apple device — not just new ones — stops checking in. Root cause: The Apple MDM Push (APNs) certificate lapsed; it authorises Intune to notify all Apple devices, so its expiry breaks all Apple management. Confirm: Devices > Enrollment > Apple > Apple MDM Push certificate shows an expired/expiring date. Fix: Renew the certificate with the same Apple ID that created it — renewing with a different Apple ID forces re-enrollment of every Apple device.

5. FileVault On but Intune holds no recovery key. Root cause: FileVault was enabled by the user before the device was managed, so the existing personal recovery key was never escrowed to Intune; the policy enforces going forward but doesn’t retroactively capture the old key. Confirm: Device > Recovery keys is empty while fdesetup status on the Mac returns On. Fix: Trigger Rotate FileVault recovery key (rotateFileVaultKey) — the Mac generates a new key and escrows it, giving Intune a recoverable value.

6. Updates won’t enforce; the fleet is stuck on an old build but shows compliant. Root cause: Either the legacy update-command model is stacked alongside DDM (they fight), or the devices are below macOS 14 (no DDM), so the declaration is “not applicable” while compliance was set only against a version floor. Confirm: The device’s DDM update state reads “pending” or “not applicable”; softwareupdate --list shows available updates not installing. Fix: On macOS 14+ drive updates through DDM only; retire any legacy update policy on the same devices. For sub-14 devices, plan an OS upgrade and don’t rely on DDM until they’re there.

7. A DDM update deadline generates forced restarts during the workday. Root cause: The deadline is shorter than the time to download the update over the user’s real link, so the device force-installs (with restart) before the user could have finished downloading voluntarily. Confirm: Compare the policy deadline against realistic download windows; users on home links report mid-day restarts. Fix: Extend the deadline to give the download runway, and set the user-facing target local date/time to off-hours so voluntary installs happen when it’s convenient.

8. A custom .mobileconfig says “applied” but the setting doesn’t take effect. Root cause: Two custom profiles share a PayloadUUID/PayloadIdentifier, so they collide; because custom profiles report opaquely, both show “applied” while the device flaps between them. Confirm: Inspect the profiles — matching identifiers across two. Fix: Regenerate UUIDs per profile, and move the setting into Settings Catalog (which manages identifiers and reports per-setting status) so this can’t recur.

Best practices

• Buy through Apple Business Manager. ADE is the only enrollment that is non-removable and survives a wipe. Off-catalog Macs are permanently at “removable” — route procurement through ABM so new machines land in ADE and are supervised.
• Deploy Company Portal + Platform SSO before Conditional Access. Entra device registration comes from Company Portal/PSSO, and CA evaluates the device object. Sequence registration first, confirm it, then flip “require compliant device” — and pilot it.
• Turn on “Await final configuration.” It gates the desktop until FileVault, PSSO, and compliance profiles apply, closing the on-but-unencrypted-and-unregistered window.
• Prefer Secure Enclave for PSSO unless you have a specific reason for password mode. The Entra password never lands on the device and it’s phishing-resistant.
• Escrow every FileVault key and rotate on a schedule (e.g. 90 days). Verify the portal actually shows a key — encryption that predates management may not be escrowed until you rotate.
• Treat a recovery-key read as burning the key. Rotate immediately after any retrieval so the value in ticket history is already dead. Reads are privileged and audited; scope who can do them.
• Drive OS updates through DDM on macOS 14+, and only DDM. Declare a target and deadline; never stack the retiring command model on the same devices. Give deadlines download runway and off-hours targets.
• Author everything in Settings Catalog; use .mobileconfig only for gaps. Custom profiles are opaque and UUID-collision-prone. One surface per setting — never configure the same thing in both.
• Deliver apps by the right channel. VPP with device licensing for App Store apps (no Apple Account), signed product-archive PKGs as LOB apps, and the agent for messy DMG/PKG installers with detection rules.
• Keep shell scripts small, idempotent, and loud. set -euo pipefail, explicit exit codes. A script that exits 0 on failure reports “succeeded” forever. Use DDM/Settings Catalog when a declarative control exists.
• Validate against a representative device. Test CA and PSSO on a Mac enrolled the way your fleet is (without pre-existing Company Portal), not an admin’s already-registered machine — the false green light is how lockouts ship.
• Put both Apple credentials on a renewal calendar. The enrollment program token and the APNs push certificate each expire annually; the push cert lapsing breaks all Apple management.

Security notes

• Least-privilege the recovery-key readers. Retrieving a FileVault key is a privileged, audited action (DeviceManagementManagedDevices.PrivilegedOperations.All). Grant it to a small, monitored role, and rotate the key after every read so a disclosed value can’t be reused.
• Secure Enclave over password mode where assurance matters. Enclave keeps the Entra password off the device and is phishing-resistant; password mode places the Entra password on the local account. Choose per your threat model.
• FileVault is the data-at-rest control — enforce it via policy, not the Setup Assistant. Skip the FileVault Setup Assistant pane and drive encryption through the disk-encryption policy so it’s enforced and escrowed, not user-optional.
• Assert SIP, Gatekeeper, and the firewall in compliance. System Integrity Protection and Gatekeeper are core macOS protections; a device with them disabled should be marked noncompliant and lose access. Set Gatekeeper to App Store + identified developers.
• Gate access on compliance, not merely on management. Conditional Access “require compliant device” is what turns a baseline into enforcement — but it depends on the Entra device object, so registration is itself a security prerequisite, not a nicety.
• Guard the app supply chain. VPP apps come from ABM; LOB PKGs must be signed product archives; DMG/PKG installers should be signed and notarized. Don’t push unsigned packages to production Macs.
• Protect the connectors. The enrollment program token and APNs push certificate are trust anchors — store the Apple IDs that own them securely, and never let them lapse (a lapsed push cert is a fleet-wide management outage that looks like an attack).
• Keep the OS patched via DDM. An enforced target version with a deadline is a security control: it closes the “stuck on a vulnerable build while the dashboard says compliant” gap that the legacy model left open.

Cost & sizing

macOS management in Intune has almost no marginal infrastructure cost — the cost is in licensing, Apple hardware, and operational effort, not per-device Azure spend.

• Intune licensing is the main line item: each managed Mac needs an Intune (or Microsoft 365 E3/E5, or EMS) licence, the same as a managed Windows PC. There’s no separate “macOS surcharge.” Conditional Access needs Entra ID P1 (bundled in E3); risk-based CA needs P2 (E5).
• Apple Business Manager and DDM are free — ABM is a no-cost Apple service, and DDM/DEP enrollment carry no Apple fee. The “cost” of ABM is procurement discipline (buying through linked channels), not money.
• VPP apps cost whatever the app costs (many are free); the VPP mechanism itself is free. Device licensing avoids the need for per-user Managed Apple ID app purchases.
• Operational effort dominates the real cost: authoring and testing profiles, running pilot rings, driving PSSO registration comms, and the annual token/cert renewals. Budget the people time, not a cloud bill.

A rough picture for a 300-Mac fleet already on Microsoft 365 E3: the Intune entitlement is already paid (E3 includes it), so the incremental software cost of managing those Macs is effectively zero — you’re using capacity you own. The costs that are real:

The sizing lesson mirrors Meridian’s: the expensive thing isn’t the tooling, it’s getting the sequence wrong — a botched CA rollout costs a morning of lost productivity across hundreds of users, which dwarfs any licensing line. Spend the effort on pilots and registration comms; the software you likely already own.

Interview & exam questions

1. Why can a fully FileVault-encrypted, ADE-enrolled Mac be blocked by a “require compliant device” CA policy? Because on macOS, Intune enrollment and Entra device registration are separate events. CA evaluates the Entra device object, which is created by Company Portal / Platform SSO registration — not by MDM enrollment. A Mac managed by Intune but never registered has no device object, so the compliant-device grant has nothing to evaluate and blocks it. Fix: deploy Company Portal + PSSO and complete registration before enabling the CA grant.

2. What does supervision unlock, and which enrollment paths provide it? Supervision lets Intune force FileVault, enforce OS updates via DDM, block removal of the management profile, and install silently. It comes from ADE and account-driven device enrollment. Account-driven user enrollment (BYOD) is unsupervised — you get a managed data volume only, and can’t force encryption or full wipe.

3. Compare the three Platform SSO authentication methods. Secure Enclave uses a hardware-bound key as the credential and never syncs the Entra password to the Mac — strongest, phishing-resistant, the corporate default. Password makes the Entra password the local account password (kept in sync) — simplest UX, one password everywhere, but the password lives on the device. Smart card uses a PIV/CAC card — highest assurance, for regulated environments.

4. Why is DDM different from the legacy update model, and when must you use it? The legacy model pushes a command (ScheduleOSUpdate) and hopes; DDM declares a target version and deadline that the Mac’s own software-update daemon enforces locally and reports declaratively — even offline. On macOS 14+ you drive updates through DDM only; stacking the retiring command model on the same devices leaves Macs stuck on old builds while Intune reports compliant.

5. A recovery key was read into a support ticket. What’s the correct follow-up and why? Rotate the FileVault recovery key immediately (device action Rotate FileVault recovery key / rotateFileVaultKey), so the value now sitting in ticket history is dead. Reading a key is a privileged, audited action; treat every retrieval as burning that key.

6. When would you choose an LOB (PKG) app vs. the agent (DMG/PKG) delivery, and what’s the LOB constraint? Use LOB for clean vendor PKGs that are signed distribution/product archives (installed via MDM InstallEnterpriseApplication, no agent needed). Use the agent for messy, unsigned, or large installers, and when you need detection rules. The LOB constraint: if the PKG isn’t a signed product archive (e.g. a bare component package), LOB install fails — re-wrap it or use the agent.

7. What is “Await final configuration” and why enable it? It holds the user at the Setup Assistant/desktop until critical profiles (FileVault, PSSO, compliance) have applied. Enabling it closes the window where a Mac is logged in and working but not yet encrypted or registered — the macOS analogue of the Windows Autopilot Enrollment Status Page.

8. Why prefer Settings Catalog over a custom .mobileconfig? Settings Catalog is curated, searchable, versioned, and reports per-setting status and conflicts; a custom profile is an opaque blob with only profile-level status and a real risk of PayloadUUID collisions across profiles that silently fight. Use custom profiles only for payloads the catalog doesn’t yet expose, and never configure the same setting in both surfaces.

9. Both an enrollment token and a push certificate exist for Apple. What breaks if each lapses? The enrollment program token (12-month) lapsing stops ADE (new corporate zero-touch enrollments) while existing devices keep working. The APNs push certificate lapsing stops all Apple management (every enrolled iOS/macOS device stops responding to MDM) — a far bigger outage. Renew each with the same Apple ID that created it.

10. Why did a CA rollout “pass” validation in test but lock out the fleet in production? The test Macs happened to have Company Portal installed already, so they were Entra-registered and passed; the fleet had been ADE-enrolled before Company Portal/PSSO and had no device objects, so “require compliant” blocked them. Validate against a representative Mac enrolled the way the fleet is, not an admin’s already-registered machine.

11. How do you inventory something Intune doesn’t natively report on a Mac? Use a custom attribute — a shell script (run by the Intune agent) whose stdout Intune captures as a device property (e.g. whether a security agent’s process is running). Keep it side-effect-free and print one clean value.

12. A shell script reports success but nothing changed on the device. Likely cause and fix? The script exited 0 on a silent failure (missing set -euo pipefail, no explicit error handling). Intune trusts the exit code, so it reports “succeeded.” Fix: make scripts idempotent, fail loudly, and return non-zero on any failure; prefer a declarative control (DDM/Settings Catalog) where one exists.

These map primarily to the MD-102 (Endpoint Administrator) exam — enrollment, compliance, configuration, app deployment, and Conditional Access for managed devices, including macOS. The identity/CA angle touches SC-300 (Identity and Access Administrator). A compact cert-mapping for revision:

Quick check

1. A Mac is ADE-enrolled and FileVault-encrypted but gets blocked by a “require compliant device” CA policy. What single artifact is missing, and what creates it?
2. Your team deployed the Platform SSO profile weeks ago, yet users still sign in twice to every M365 app. What step was almost certainly skipped, and how do you confirm it on the device?
3. True or false: you can force FileVault and enforce DDM updates on a Mac enrolled via account-driven user enrollment (BYOD).
4. A recovery key was pasted into a help-desk ticket. What is the correct immediate follow-up action?
5. New corporate Macs quietly stop enrolling, but the Apple enrollment token’s sync icon looks fine in Intune. What’s the most likely cause and the fix?

Answers

1. The Entra device object is missing. On macOS, MDM enrollment (Intune) and Entra registration are separate; the device object is created by Company Portal / Platform SSO registration, and CA evaluates that object. Deploy Company Portal + PSSO and complete registration before the CA grant.
2. PSSO registration was never completed — the profile configured PSSO but the user didn’t action the registration prompt, so it’s inert. Confirm on the Mac with app-sso platform -s (it shows not registered). Surface the registration prompt in onboarding and re-trigger.
3. False. User enrollment is unsupervised: you get a managed data volume and can’t force FileVault, can’t enforce DDM updates, and can’t fully wipe the device. Those require supervision (ADE or account-driven device enrollment).
4. Rotate the FileVault recovery key immediately (device action Rotate FileVault recovery key / rotateFileVaultKey) so the disclosed value is dead. Reading a key is privileged and audited — treat every read as burning that key.
5. The enrollment program token expired (12-month lifetime); ADE syncs stop while the portal UI still looks healthy. Download a fresh .p7m from ABM and renew under the same token row to preserve serial-to-profile assignments. (Also check the APNs push certificate, whose lapse breaks all Apple management.)

Glossary

• Supervision — the corporate-owned control level set at enrollment (ADE or account-driven device enrollment) that lets Intune force FileVault, enforce DDM updates, block profile removal, and manage silently. Unsupervised (user enrollment) devices have none of this.
• Automated Device Enrollment (ADE) — Apple’s zero-touch enrollment (formerly DEP): the device enrols during Setup Assistant, is supervised, non-removable, and survives a wipe. The only path with all three properties.
• Apple Business Manager (ABM) — Apple’s portal for corporate device purchases, the MDM server token, and VPP/Apps-and-Books tokens; the source of supervision.
• Enrollment program token — the ADE/DEP trust artifact (a .p7m) linking ABM to Intune; expires 12 months after creation, at which point ADE silently stops.
• Apple MDM Push (APNs) certificate — authorises Intune to push MDM notifications to all Apple devices; renews annually, and its lapse breaks all Apple management.
• Company Portal — the Microsoft app that carries the Enterprise SSO plug-in and, on sign-in, establishes the device’s Entra registration.
• Platform SSO (PSSO) — binds the local macOS account to Entra ID at the login window and provides SSO to apps via the SSO extension; requires a user-completed registration step to activate.
• Secure Enclave / Password / Smart card — the three PSSO authentication methods: a hardware-bound key (Enclave), the Entra password as the local password (Password), or a PIV/CAC card (Smart card).
• Entra device object / registration — the Entra ID record of the device that Conditional Access evaluates; on macOS it’s created by Company Portal/PSSO, separately from MDM enrollment.
• FileVault — Apple’s APFS full-disk encryption; on supervised Macs it can be forced by policy, with the personal recovery key escrowed to Intune.
• Recovery key escrow / rotation — storing the FileVault personal recovery key in Intune (escrow) and generating a fresh one (rotation), on schedule or on demand after a disclosure.
• Declarative Device Management (DDM) — Apple’s model where the device enforces a declared desired state (e.g. a target OS version + deadline) locally and reports declaratively, even offline; the modern way to enforce macOS 14+ updates.
• Settings Catalog — Microsoft’s curated, searchable, versioned surface over Apple MDM payloads, with per-setting status and conflict reporting; the default authoring surface.
• Custom profile (.mobileconfig) — a raw Apple configuration profile authored externally, used only for payloads Settings Catalog doesn’t expose; reported opaquely (profile-level only).
• VPP / Apps and Books — volume app licensing from ABM; device licensing installs apps with no personal Apple Account; user licensing ties apps to a Managed Apple ID.
• Line-of-business (LOB) app — a signed distribution/product-archive .pkg installed via the MDM InstallEnterpriseApplication command (no agent).
• Intune agent — Microsoft’s macOS management agent (installs only on MDM-enrolled Macs) that runs shell scripts, custom attributes, and DMG/PKG app installs with detection rules.
• Custom attribute — a shell script whose stdout Intune captures as a device inventory property, for facts the built-in properties don’t cover.
• Await final configuration — a Setup Assistant option that holds the desktop until critical profiles apply; the macOS analogue of the Windows Autopilot Enrollment Status Page.

Next steps

You can now build a full macOS baseline and gate it into Conditional Access without locking anyone out. Build outward:

• Next: Gating Microsoft 365 with Endpoint Conditional Access: Compliance Policies, Device Filters, and Require-Compliant Enforcement — the deep dive on compliance + CA that this article’s final zone applies to macOS.
• Related: Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters — the policy framework behind the “require compliant device” grant.
• Related: Mastering Intune Assignment Filters and Ring Deployment: Targeting Logic, Precedence, and Safe Rollouts — the pilot-ring and filter discipline that prevents rollouts like Meridian’s.
• Related: Building Intune Configuration Profiles with the Settings Catalog and ADMX Ingestion — the same Settings-Catalog-first authoring discipline, from the Windows side.
• Related: Intune App Protection Policies for BYOD: Securing Microsoft 365 Data Without MDM Enrollment — the right posture for personal Macs you don’t want to fully manage.
• Related: Intune Remediations at Scale: Detection and Remediation Scripts, Scheduling, and Drift Correction — the scripting-as-last-resort pattern, applied on Windows.