Jamf used to be a one-horse town. It isn’t anymore

Platform SSO closed the technical gap between Jamf and Intune for managing Macs. What’s left is a skills gap — and most Windows-centric IT teams solve it by not solving it.

Six years ago I had to enrol 450 “in the wild” Macs into an MDM. At the time, that was a one-horse town.

The requirements were straightforward on paper: FileVault disk encryption, and the ability to log into the device with Entra ID (then Azure AD) credentials rather than a local account nobody could account for. In practice, that second requirement made the decision for me. Jamf Connect was the only credible way to get there, so Jamf Pro was the only credible MDM.

That gap has closed.

Platform SSO changed the calculus

Microsoft’s Platform SSO means you can enrol Macs into Intune, eliminate unmanaged local accounts, and have users sign into the device itself with their M365 credentials. For a Microsoft-centric organisation, the single biggest reason to pay the Jamf premium is no longer a reason at all.

That doesn’t mean the two products are equivalent.

Where the gap still is

Jamf’s advantage is now what it gives you out of the box. Bringing an Intune tenant to Jamf parity is entirely achievable, but it demands a materially higher level of shell scripting than the equivalent work in Jamf’s GUI:

Self-healing software installs: detect drift, remediate without a ticket
CIS baseline configuration: and, critically, ongoing enforcement rather than a one-time apply
Third-party patching: the part most estates quietly fail at
Zero-touch deployment: device out of the box, into the user’s hands, compliant on first boot

A concrete example of what “self-healing” actually means in practice. On that estate I defined a baseline allowlist of permitted software, configured directly in a Jamf policy. Devices were evaluated against that baseline at inventory. Any drift, meaning anything present that wasn’t on the list, triggered an uninstall policy against the known applications. No ticket, no user prompt, no engineer touching the machine.

Drift detected, drift corrected, on a loop, indefinitely.

That matters more than it sounds. In a regulated environment, “we have an approved software policy” is a document. “Every device is continuously measured against our approved list, and here is the record of each one being brought back into line” is a control. Auditors care a great deal about the difference, and so should you.

The same outcome is achievable in Intune, with caveats. You are working around the limitations of extension attributes rather than leaning on native smart group evaluation, which means more of the detection and remediation logic has to live inside the script itself rather than in the platform. It works. It is simply more of your own engineering and less of the vendor’s.

None of this is hard if macOS is your specialism. All of it is a steep climb if it isn’t. Which is why, in practice, the decision often gets made for the organisation by default: the team knows Windows, the tooling is familiar, and macOS stays an exception rather than an option.

The barrier has moved

For years, the reason a Microsoft-centric business couldn’t offer macOS as a default option was a technical one. Platform SSO removed it.

What’s left is a skills gap, and a skills gap is a solvable problem. It’s just that most organisations solve it by not solving it, and quietly making Windows the only option on the hardware form.

I’m an endpoint management specialist. I work with regulated businesses on Intune and Jamf Pro, getting macOS estates into a compliant, zero-touch, audit-ready posture and keeping them there.

I’m currently taking on new client work. If your Mac estate is stuck in “unmanaged but tolerated,” or you’re staring at an Intune migration and the macOS side is the part nobody wants to own, get in touch.

← Writing · Andy Bridson