Intune and macOS 27: what changed and what to fix

What do I need to change in Intune for macOS 27? If your Macs are in Intune, macOS 27 changes four things. Enrolment now needs macOS 15 or later, so Macs on 14 stay enrolled but can't enrol fresh. Your old macOS update policies stop working on 27, so updates have to move to Declarative Device Management in the settings catalog, and Microsoft said it would start removing the legacy update policies from the admin centre with its October (2610) release. Several old MDM payloads are deprecated, including PPPC, passcode, DNS and content caching, with settings catalog replacements. And Platform SSO works the same way in Intune as before, but needs Company Portal 5.2404.0 or later and Macs on 27.0.1, which fixed a Lock Screen bug. Four weeks after release there's no documented wave of Intune bugs on macOS 27. The work is retiring old Mac policies, not firefighting.

This post is for whoever runs IT at a Microsoft-first company and has watched the Mac count creep up. The Macs went into Intune because Intune was already there. That works until the Mac policies fall behind the Windows ones, and macOS 27 is where the older ones stop doing anything. We've covered what broke on macOS 27 for business Macs in general; this is the Intune version.

Which Macs can still enrol in Intune?

Macs on macOS 15 or later. Microsoft announced in June, in Message Center post MC1403402 (opens in a new tab), that "Microsoft Intune, the Company Portal app and the Intune MDM agent will be moving to support macOS 15 (Sequoia) and later". Microsoft didn't publish an exact date, only "later this year", and the change rides on the OS 27 cycle, so plan as if it already applies.

Two things follow from that post.

Macs already enrolled stay enrolled. Microsoft's wording: "Devices that are currently enrolled on macOS 14.x or below will continue to remain enrolled even when those versions are no longer supported." Nothing gets kicked out, so there's no rush on that side.

New enrolments on 14 or below are blocked. "New devices will be unable to enroll if they are running macOS 14.x or below." So a Sonoma-era Mac handed to a new starter won't go in until it's upgraded.

There's one nuance in Microsoft's Intune and Apple OS 27 post (opens in a new tab). "Supported" means macOS 15 and later. "Allowed" stretches back to macOS 13, but only for user-less enrolment. User-affinity enrolment, and any app that needs the user to sign in, aren't available on allowed-only versions. For an employee's Mac that's the same as not supported.

Intel Macs top out at macOS 26, which is fine for Intune. The ones to find are Macs still on 14 or older. Our macOS 27 upgrade checklist covers the Intel maths and the Cyber Essentials side.

What happens to macOS update policies on macOS 27?

They stop working. Apple's enterprise notes for macOS 27 (opens in a new tab) say "Legacy software update management no longer functions in all 27.0 operating systems", and list what that covers: software update commands, queries, recommended cadence settings, and restrictions like deferrals and Background Security Improvements.

Intune's old macOS update policies are built on those commands. Microsoft's OS 27 post says they "have been removed from OS 27, and you should use DDM for these instead". A deferral set the old way isn't holding a macOS 27 Mac back, and it isn't pushing updates to it either. The Mac is just unmanaged for updates until you replace the policy.

Microsoft is also removing the old policies from the console. Starting with the October (2610) release, it said it would remove from the admin centre: iOS/iPadOS update policies, macOS update policies, the per-device macOS software updates report, and the iOS and macOS update installation failure reports.

The replacement is DDM, which Microsoft's update policy documentation (opens in a new tab) now describes as the model, with the MDM-based policies marked deprecated. DDM updates need macOS 14 or later and either Device Enrollment or Automated Device Enrollment. You build them under Settings catalog, then Declarative Device Management, and there are two shapes.

Software Update Enforce Latest. You set a delay in days and an install time. Every Mac in the group installs whatever Apple's latest is, that many days after it ships. Use this for office Macs with no app blockers.

Software Update (targeted). You set a target OS version, optionally a build, a target date and time, and a details URL for the user. Use this to hold a group at a specific version, or to get a pilot group to 27.0.1 by a date.

Two behaviours to know before you turn either on. When the deadline arrives, the user gets a one-minute countdown, then the Mac installs the update and restarts. A Mac that was powered off at the deadline gets a one-hour grace period after it's powered on. Tell people this in advance, because a one-minute warning in the middle of a client call is how update policies get a bad name.

And clean up behind yourself. Once a Mac has passed the version in a targeted policy, the policy reports an error, because the Mac reads it as a downgrade. Remove old-version policies as groups move on. A separate Software Update Settings policy controls the user side: who can update, hiding updates for a period, and notifications.

Which Intune payloads are deprecated on macOS 27, and what replaces them?

Microsoft's OS 27 post lists six MDM payloads as deprecated with OS 27: content caching service, DNS settings, DNS proxy, parental controls application restrictions, privacy preferences policy control (PPPC), and passcode. Deprecated means they will "no longer be updated or supported". The replacement in each case is the DDM equivalent in the settings catalog.

Several settings inside the Restrictions payload are deprecated too, with DDM replacements. Microsoft names App Settings, which allows or blocks listed app bundle IDs, and Intelligence settings, which cover the Apple Intelligence features.

For a typical Microsoft-first fleet, two of those matter most.

PPPC. If you grant Accessibility access to a remote support tool or an automation agent through the old PPPC profile, Apple's notes say the user now sees a notification, once per configured app, telling them the app can access their data, monitor their keyboard and websites, record their screen and more. The grant still applies, but it's no longer silent. We wrote up what replaces PPPC on macOS 27 when Apple announced it.

Passcode. If your Mac password rules live in the Passcode payload, they need rebuilding in the settings catalog. Do that before the old payload drifts out of support, and test on one Mac first, because password policy mistakes lock people out.

One addition rather than a replacement: Apple says device management on macOS 27 "can manage which apps or binaries are allowed to run". Microsoft's post lists App Settings in the settings catalog, with allowed and blocked app bundle IDs. Whether that reaches command-line tools as well, Microsoft hasn't said yet.

Does Platform SSO still work on macOS 27?

Yes, and in Intune it's set up the same way as before. Microsoft's Platform SSO documentation (opens in a new tab), updated in September, still delivers it as a settings catalog Extensible Single Sign On (SSO) policy using the Company Portal SSO extension. It needs Company Portal 5.2404.0 or newer. Microsoft's own words: "If you have an older version of the Company Portal app installed, Platform SSO fails."

So check the Company Portal version on every Mac before you touch the policy. It's the cheapest fix in this post.

On the Apple side, macOS 27 lets Platform SSO authenticate with the identity provider using OpenID at FileVault unlock, the Lock Screen and the login window, and can require Touch ID or Apple Watch. Microsoft hasn't said Intune delivers Platform SSO through the new macOS 27 declaration, so don't assume you get those options from the Intune policy yet. Our Platform SSO on macOS 27 post covers what Apple built.

One thing to get right first: Apple's notes for 27.0.1 say it "resolved an issue where Platform SSO did not display username and password fields at the Lock Screen after waking from sleep". Get Macs to 27.0.1 or later before Platform SSO goes anywhere near them. A targeted DDM update policy is the tool for that.

Does Defender for Endpoint support macOS 27?

From day one. Microsoft's prerequisites page (opens in a new tab) says "Defender for Endpoint supports the three most recent major macOS releases: 27 (Golden Gate). 26 (Tahoe). 15 (Sequoia)." and that "New major macOS releases are supported from the first day that Apple makes the release generally available."

Note that 15 is on that list, so Defender's window and Intune's new floor line up. A Mac on Sonoma is on neither.

What should your compliance policy say about macOS 27?

Whatever you decide on purpose. This one isn't a reported bug, it's the thing that catches people out every autumn. Compliance policies with an OS version rule need a decision on two dates: when macOS 27 is allowed, and when the older versions become non-compliant.

Leave the maximum version where it was and a Mac that upgrades to 27 goes non-compliant. If Conditional Access requires a compliant device, that person loses access to M365 until someone notices. Leave the minimum where it was and nobody has a reason to upgrade. Neither is a decision anyone made.

Pair the compliance rule with the DDM update deadline so the two agree: if Enforce Latest installs 27 on a Tuesday, the compliance policy allows 27 before that Tuesday. A group held on Tahoe for an app vendor keeps a Tahoe minimum until the vendor moves.

What to change in Intune, in order

Here's the order we'd work through it.

1. Find the Macs on 14 or older. They stay enrolled, but they're your enrolment and support problem. Plan their upgrade or replacement.
2. Check the Company Portal version everywhere. 5.2404.0 or newer, or Platform SSO fails.
3. Build a DDM update policy and assign it to a pilot group. Enforce Latest for office Macs, targeted for anything that needs holding.
4. Target 27.0.1 or later for any Platform SSO group. Don't let 27.0 near the login screen.
5. Decide the compliance rule and change it before the update deadline. Minimum and maximum, per group.
6. Rebuild deprecated payloads in the settings catalog. Passcode and PPPC first, then DNS and content caching if you use them.
7. Retire the old update policies. Remove any targeted policy whose version has passed, and build nothing new on the legacy ones Microsoft is removing from the admin centre.
8. Tell users about the countdown. One minute, then a restart. One short email saves a lot of tickets.

None of this has to happen this week. But a macOS 27 Mac with legacy update policies is sitting there unpatched until someone does step 3.

If your Mac fleet is growing faster than your Intune setup

We work with Microsoft-first companies whose Macs sit in Intune alongside their Windows estate. Intune manages Macs well once it's set up the DDM way. Most of the problems we see are configuration debt: policies built for an older macOS and carried forward release after release.

What we'd do is audit the Mac side of your Intune tenant, list what's legacy against what macOS 27 expects, rebuild it in the settings catalog, run the pilot group with you, and hand it back documented. If you're weighing whether Intune is the right home for Macs at all, our Jamf, Intune and Iru comparison is the place to start.

Get in touch if you want the Mac side of Intune looked at, or read about our Apple IT support in London first.