Why Most Melbourne MSPs Cannot Support Your Macs Properly

Most Melbourne managed service providers cannot manage a Mac fleet, and most of them will not tell you that during the sales process. They will say Macs are supported, which is true in the sense that someone will answer the phone. It is not the same as managing the device.

This is not a character flaw. It is a structural consequence of how the Australian MSP market was built. Understanding why makes it much easier to ask the two or three questions that expose the gap in about ten minutes.

The market standardised on Windows tooling, and Macs fell out of the stack

An MSP’s economics depend on a single stack: one RMM agent, one patching engine, one antivirus, one documentation system, one ticketing integration. Every one of those products was built for Windows first, and several of them still treat macOS as a checkbox rather than a platform.

The result is a Mac that has an agent installed and nothing else. It appears in the RMM inventory. It reports a serial number and a disk usage figure. It is not enrolled in any device management service, it has no configuration profiles, its FileVault key is nowhere, and nobody has ever pushed a setting to it. On a dashboard it looks green. It is unmanaged.

The second structural problem is people. Windows administration is a well-trodden career path in Australia with a clear certification ladder. macOS at scale is not. Most helpdesks are staffed by technicians who are genuinely competent on Windows and Microsoft 365, have never used a configuration profile, and treat every Mac ticket as a one-off. Escalation goes to whoever owns a Mac personally. That is not a capability, it is a coincidence.

Third, volume. In a typical Australian SMB portfolio Macs are a minority of endpoints, so no MSP builds a practice around them. The finance director, the marketing team and the two designers get the worst service in the business, and because they are a minority they never generate enough noise to change anything.

The tell-tale signs, which you can check yourself

There is no MDM for the Macs at all. Ask which device management service your Macs are enrolled in. If the answer names your RMM product, the answer is none. An RMM agent is not MDM. Apple’s management framework is a separate thing that requires an enrolment profile, and a device that is not enrolled cannot receive configuration profiles, cannot be remotely wiped through Apple’s mechanism, and cannot be supervised.

Devices are not enrolled through Apple Business. Apple replaced Apple Business Manager with a service called Apple Business on 15 April 2026, and Apple’s own footnote on zero-touch deployment states that it “is available when devices are purchased through Apple or Apple Authorised Resellers”. Ask whether your provider has lodged your Organisation ID with your hardware reseller and whether new Macs appear in Apple Business before they are unboxed. Apple publishes a list of Preferred Device Enrolment Resellers for Australia. Your supplier is either on it or you are doing this the hard way.

If the answer is that Macs get set up manually when they arrive, you do not have a deployment process. You have a person.

They cannot patch third-party Mac applications. This is the sharpest question in the list, because the answer is verifiable. Ask how Chrome, Zoom, Adobe or whatever your designers use gets updated on a Mac. There are only three honest answers: a maintained patch feed in an Apple-first MDM, a scripted packaging pipeline the provider maintains, or the applications update themselves and nobody controls it. Intune has no macOS equivalent of its Windows Enterprise App Catalog, so if you are on Intune the answer cannot be “Intune does it”. The detail is in what Intune can and cannot do on macOS.

They do not know what a PPPC profile is. Privacy Preferences Policy Control is Apple’s configuration profile payload that pre-approves specific applications for access to things like the Documents folder, screen recording, Accessibility APIs and full disk access. Its payload identifier is com.apple.TCC.configuration-profile-policy and Apple’s documentation states that “supervision is required if you apply this payload using a device management service”.

Why it matters commercially: without PPPC, your backup client, your EDR agent and your remote support tool all trigger consent dialogs. Users click them away. The agents then quietly fail to do their job and the console still shows them installed. This is the single most common reason a Mac fleet is protected on paper and not in reality. A provider who cannot explain PPPC has not deployed security software to Macs properly, whatever the dashboard says.

Nobody holds the Activation Lock bypass codes. Ask where they are stored. Apple’s documentation is specific: on iPhone and iPad the device-generated bypass code is only retrievable for up to 15 days after the device is first supervised, and “if a device management service doesn’t retrieve the bypass code within 15 days, that bypass code is unretrievable”. If your provider cannot answer this, budget for the day a departing employee leaves a locked MacBook behind.

FileVault keys are not escrowed, or have never been tested. Ask them to retrieve the recovery key for a specific Mac while you watch. Escrow failing silently is common.

No bootstrap token. On an Apple silicon Mac, a bootstrap token escrowed to the management service is required for a remote erase to work. Without it, Apple’s documentation warns the machine can fall back to obliteration, after which macOS must be reinstalled before it can be used. Remote wipe either works or it does not, and you find out on the worst possible day.

Compliance answers stop at the Windows fleet. If you have an Essential Eight target, ask specifically what the maturity position is for the Macs. ASD’s own Maturity Model FAQ defines a workstation as “any device that uses a desktop operating system, such as Microsoft Windows or a Linux distribution”, and its application control file type list is entirely Windows. macOS needs a documented translation and compensating controls, which is the point of the Essential Eight mapped onto macOS. A provider who has not thought about this will tell you the Macs are fine. They are not fine, they are unassessed.

Nine questions to ask your current provider

Send these in an email. Ask for written answers. The quality of the reply tells you more than any capability statement.

1. Which device management service are our Macs enrolled in, and how many of our Macs are actually enrolled today?
2. Are our Macs supervised, and were they enrolled through Automated Device Enrolment?
3. Is our Organisation ID lodged with our hardware reseller, so new Macs appear in Apple Business automatically?
4. How do third-party applications get patched on our Macs, and where is the report showing current versions?
5. Do we deploy a PPPC profile, and which applications does it cover?
6. Where are our Activation Lock bypass codes stored, and can you produce one now?
7. Can you retrieve the FileVault recovery key for a specific Mac while I watch?
8. Have bootstrap tokens been escrowed for our Apple silicon Macs?
9. What is our Essential Eight maturity position for the Mac fleet specifically, and what compensating controls have you documented for application control?

The pattern to watch for: vague answers on 1 to 3, deflection on 4, silence on 5 and 6. A provider who genuinely runs Macs will answer all nine quickly and will probably correct one of your assumptions while doing it.

What good actually looks like

Macs bought through a reseller linked to Apple Business, arriving supervised and enrolled before anyone touches them. Configuration profiles delivering settings rather than a technician clicking through System Settings. A managed local administrator account with a rotating password, and users running as standard. FileVault on with keys escrowed and tested. PPPC deployed so security agents work silently. Software updates enforced through Apple’s declarative device management with a deadline you chose. A named position on third-party application patching, in writing. Activation Lock managed by the organisation, not by whoever signed in first. Offboarding that clears the lock before wiping, in that order.

None of that is exotic. It is the same discipline a competent MSP applies to Windows, applied to a platform whose management model is different rather than harder. It is covered end to end in what proper Mac fleet management looks like and the Apple device lifecycle end to end.

The trade-off is honest and worth naming: doing this properly costs more per Mac than leaving an agent on it. You are paying for a second management platform, or for the internal capability to work around the gaps in the one you have. That is a real decision, and Jamf and Intune compared honestly is where to make it.

Where TechAssist sits

We have been operating for over twenty years, we have thirteen certified specialists, and we run Apple and Mac fleet management as a named service alongside Microsoft 365, Intune, Entra ID and Essential Eight uplift and assessment work. Our head office is in Tecoma in the Dandenong Ranges and we have a Melbourne CBD office, so on-site work in the outer east and across greater Melbourne is us, not a subcontractor.

We are a member of the Apple Consultants Network, Apple’s programme of independent technology partners specialising in Apple solutions for small and medium-sized businesses. We work with Apple’s business deployment programmes for enrolment and device management: Automated Device Enrolment through Apple Business, supervision, configuration profiles including PPPC, FileVault key escrow, bootstrap tokens and Activation Lock held by the organisation. That is the list above, done rather than described.

The reason we can write this post is that we run mixed fleets as a normal state rather than an exception, which is the argument set out in running Windows, Mac and Google in one business. We are also a Microsoft partner, so read the above as an argument about breadth rather than an argument against Microsoft. We are not going to tell you to standardise on Windows because our tooling prefers it.

Send us the nine questions above and we will answer them about your environment, not ours. Call 1300 028 324 or use https://techassist.au/contact/. If your current provider comes out of that well, we will tell you so.

Intune can manage a Mac fleet properly. What it cannot do is keep your third-party Mac applications patched, and that single gap is usually what decides whether you need a second tool. Everything else in the Intune macOS story is better than its reputation suggests.

This is written for the business that already pays for Intune inside a Microsoft 365 subscription and would rather not buy and run a second management platform. That instinct is right more often than Apple-first consultants will admit.

The verdict, before the detail

If your Mac fleet is small, your application set is short and predictable, and nobody is auditing you against a control framework, Intune alone is enough. Buying a dedicated Apple MDM alongside it adds cost, a second console, a second set of enrolment records and a second thing to break.

Disclosure, because it is relevant to that verdict: we are a Jamf partner and a Microsoft partner, so we hold a commercial relationship on both sides of this question. We still tell most businesses in the position described above to stay on Intune alone, which is the cheaper answer for them and the smaller one for us.

Our rule of thumb, and it is professional judgement rather than a published benchmark: the trigger is not headcount, it is the application estate. Ten Macs running fifteen specialist creative or engineering applications will break Intune’s app model long before fifty Macs running Microsoft 365, a browser and a video conferencing client. If you can list every non-Apple, non-Microsoft application on your Macs on one hand, stay on Intune.

The trade-off is real: staying on Intune means you own the packaging and versioning of third-party Mac applications yourself, or you accept that they update themselves and you stop pretending you control that. Say which one you are choosing, in writing.

What Intune genuinely does well on macOS

Automated Device Enrolment and zero-touch setup. Intune links to Apple’s business portal, so a Mac bought through a participating reseller enrols itself out of the box and arrives supervised. Note the naming change: Apple replaced Apple Business Manager with a service called Apple Business on 15 April 2026, per Apple’s own announcement. The mechanics are unchanged and Intune’s enrolment token flow still works the same way. If you have not set that up, start with Apple’s business device portal before you touch Intune.

Platform SSO. This is the strongest thing Microsoft has shipped for the Mac. Platform SSO signs users into a managed Mac with their Microsoft Entra ID credentials, and with the Secure Enclave authentication method it is passwordless and hardware bound. Microsoft’s documentation states plainly that Secure Enclave “is considered password-less and meets phish-resistant multifactor (MFA) requirements” and is “conceptually similar to Windows Hello for Business”. It needs macOS 13.0 or newer, Company Portal 5.2404.0 or newer, and it is included with all Intune licensing plans.

One honest caveat from Microsoft’s own page: with Secure Enclave, the local account password is deliberately left alone, because FileVault uses the local password to decrypt the disk at startup. After a reboot the user still types the local password once. Touch ID works after that.

FileVault with escrowed recovery keys. Intune configures FileVault, escrows the personal recovery key, and surfaces it through the built-in encryption report. Key rotation is gated behind an RBAC right, so a help desk operator can retrieve a key without being a global administrator. Microsoft is candid that Intune’s FileVault settings “do not expose every FileVault capability”, so check the specific option you need exists before you promise it.

The settings catalog. Intune’s settings catalog exposes Apple’s declarative and profile settings directly, which means most things Apple publishes a payload for can be configured without hand-writing a mobileconfig file. This is a genuine change from the Intune of a few years ago and a lot of stale advice online predates it.

Compliance policy feeding Conditional Access. A Mac can be assessed for OS version, encryption status, firewall state and Defender health, and that compliance state can gate access to Microsoft 365 through Conditional Access. This is the single best argument for Intune on Macs: the same identity and access decision covers both platforms. It sits at the centre of endpoint security and device management for a mixed fleet.

Defender for Endpoint on Mac. Built on Apple’s system extension architecture, with web threat protection across Safari, Chrome, Firefox and Edge, network protection, and device control for removable storage now generally available. It is a real EDR product on macOS, not a token port.

Declarative software updates. macOS updates are now enforced through Apple’s declarative device management on macOS 14 and later, configured in the settings catalog, targeting a specific OS or build version with an enforced deadline. Apple has deprecated the older MDM software update workload and Microsoft recommends DDM. If you configure both, DDM wins.

Where Intune is genuinely weaker than a dedicated Apple MDM

Third-party application patching. This is the big one. Intune’s Enterprise App Catalog, the feature that discovers, packages and auto-updates non-Microsoft applications, is a Windows Win32 feature. There is no macOS equivalent. On the Mac you upload DMG, PKG or line-of-business packages yourself, and when the vendor ships a new version you upload it again. Nothing tells you a new version exists.

A dedicated Apple MDM either ships a maintained patch feed or plugs into the community tooling that does. Intune does not. In practice, Intune shops either script the gap or let applications self-update and accept the loss of control. Both are defensible. Neither is what a vulnerability scanner report will expect to see.

Scripting and inventory attributes. Intune supports shell scripts on macOS 12.0 and later, but only through the separate Intune management agent, only on devices with a direct internet connection (proxies are not supported), with a 1 MB script size limit and a hard 60-minute execution timeout. Run status is only reported when it changes, which makes troubleshooting slower than it should be.

Custom attributes are thinner still: the script runs every eight hours and the returned value must be 20 KB or less. Compare that with an Apple-first platform where extension attributes feed dynamic device groups that drive policy in near real time. If your operating model depends on “find every Mac where X is true and do Y”, Intune will frustrate you. This is the practical difference that shows up in how Jamf and Intune compare head to head.

Application control. Intune has no application allowlisting for macOS. Windows has Defender Application Control and AppLocker; the Mac has Gatekeeper, notarisation and XProtect, which are Apple’s controls, not yours. If you have a control requirement that says only approved software may execute, Intune will not get you there on the Mac and neither will a different MDM without a third-party product. We deal with that specifically when mapping the Essential Eight onto macOS.

Speed of support for new macOS releases. Microsoft’s published support policy is that Intune supports the three most recent major operating system versions, with older versions allowed to enrol but not guaranteed to work. That is a reasonable policy. What it does not promise is that a new setting Apple introduces at WWDC will be configurable in the settings catalog on the day the new macOS ships. Apple-first vendors compete on exactly that, and it matters if you deploy new hardware early or your users update themselves.

The practical consequence for an Australian business: Apple’s major macOS releases land in our spring, which is the same quarter as end-of-year project pressure. Plan a deferral window rather than assuming your MDM will keep up.

If you are staying on Intune, do these five things

1. Set the software update deferral and deadline through DDM, not through the deprecated MDM policy, and pick a deferral period you can actually support.
2. Decide your third-party patching position and write it down. Either you package and version applications yourself on a schedule, or you enable vendor auto-update and record that as an accepted risk. Undecided is the failure mode.
3. Deploy Platform SSO with Secure Enclave, not the password method, unless you have a specific reason otherwise. It is the phishing-resistant option and it costs nothing extra.
4. Confirm FileVault keys are actually escrowing by pulling a key from the encryption report for a real device. Escrow silently failing is common and only discovered when you need the key.
5. Get compliance policy wired into Conditional Access so a non-compliant Mac loses access to data rather than just showing red in a report.

If you want the full enrolment, policy and failure-mode picture rather than just the Intune slice, we cover the mechanics of running a Mac fleet separately, and the wider question of running Windows, Mac and Google in one business without standardising on one vendor.

Book a review of your existing Intune tenancy and we will tell you whether your Macs are actually managed or just enrolled, and whether a second MDM is worth the licence. Call 1300 028 324 or use the form at https://techassist.au/contact/. We will give you the answer even if the answer is that your current setup is fine.

The Essential Eight is ASD’s set of eight prioritised mitigation strategies for protecting internet-connected IT networks, assessed across four maturity levels from Maturity Level Zero to Maturity Level Three. It was written with Windows environments in mind, and several of its requirements name Microsoft products directly. That does not exempt your Macs, and an assessor will not accept “it is a Mac” as an answer.

This post maps each of the eight onto macOS honestly, including the three places where the mapping is genuinely imperfect and you will need compensating controls to survive an assessment. If you need the framework itself first, start with what the Essential Eight actually requires.

Get the names right, because assessors do

ASD’s eight mitigation strategies are: patch applications, patch operating systems, multi-factor authentication, restrict administrative privileges, application control, restrict Microsoft Office macros, user application hardening, and regular backups.

Maturity is assessed per strategy across four levels: Maturity Level Zero, One, Two and Three. ASD’s guidance is that organisations “should plan their implementation to achieve the same maturity level across all eight mitigation strategies before moving onto higher maturity levels”. There is no requirement to have an implementation certified by an independent party, though a government directive, a regulator or a contract may require an independent assessment.

Two things people get wrong in tender responses. First, “Maturity Level Two” is a target across all eight, not a badge you earn on your best control. Second, ASD’s FAQ states that risk acceptance without compensating controls, or transferring risk by buying cyber insurance, results in an assessment of Maturity Level Zero for that strategy and for the overall Essential Eight implementation. You cannot insure your way out of application control.

Why the mapping is awkward on Apple hardware

Read ASD’s own scoping language and the problem is visible. The Essential Eight “has been designed to protect organisations’ internet-connected information technology networks”, and the Maturity Model FAQ defines a workstation as “any device that uses a desktop operating system, such as Microsoft Windows or a Linux distribution”. macOS is not named. The application control file type list in the same FAQ is entirely Windows: .exe, .dll, .ps1, .msi, .chm, .hta, .cpl.

This is not an argument that the Essential Eight does not apply to Macs. It is an argument that you must translate intent into macOS controls and document the translation. ASD explicitly allows this. The FAQ states that compensating controls are acceptable where “system owners will need to demonstrate that their compensating controls provide an equivalent level of protection to the specific Essential Eight requirements they are compensating for”. Write that demonstration down before the assessor asks for it.

The mapping, strategy by strategy

Patch applications: mostly a tooling problem

The requirements are platform neutral. You need automated asset discovery at least fortnightly, a vulnerability scanner with a current database, weekly scanning of office productivity suites, browsers and their extensions, email clients, PDF software and security products, patching of those within two weeks, and removal of unsupported software.

Nothing here is Windows specific. The failure is practical: most Australian SMB fleets have no vulnerability scanner pointed at their Macs at all, and no automated way to push a third-party application update. Intune in particular has no macOS equivalent of its Windows Enterprise App Catalog, which is the detail covered in what Intune can and cannot enforce on a Mac. Fixing this usually means either an Apple-first MDM with a patch feed or a scripted packaging pipeline.

Verdict: clean mapping, common failure.

Patch operating systems: clean, with one open question

macOS updates are enforceable through Apple’s declarative device management, which lets you nominate a target OS or build version and an enforced deadline. Maturity Level One requires workstation operating system patches within one month of release, which is comfortably achievable.

The open question is the last requirement: “Operating systems that are no longer supported by vendors are replaced.” Apple does not publish a formal end-of-support date for a macOS release the way Microsoft publishes a Windows lifecycle date. You will need to state your own supported-version policy, defend it, and evidence that no Mac in the fleet is outside it. Expect an assessor to probe this.

Verdict: clean mapping, one documentation gap.

Multi-factor authentication: the strongest macOS story

This strategy is mostly about identity, not endpoints, so the platform is largely irrelevant. Maturity Level One requires that MFA “uses either: something users have and something users know, or something users have that is unlocked by something users know or are”.

macOS has a good answer. Platform SSO with the Secure Enclave authentication method binds a credential to the hardware and is described by Microsoft as passwordless and phishing resistant, conceptually similar to Windows Hello for Business. ASD’s FAQ explicitly accepts Windows Hello for Business as satisfying the MFA requirement. ASD has not published an equivalent answer for Platform SSO, so if you are being formally assessed, raise it with the assessor rather than assuming. Our reading is that it satisfies the construction, but that is our reading and not an ASD ruling.

Broader guidance on rollout sits in our multi-factor authentication for business guide.

Verdict: strong mapping, one unresolved question worth raising early.

Restrict administrative privileges: partly identity, partly a Mac habit

Maturity Level One requires separate dedicated privileged accounts, privileged accounts blocked from internet, email and web services, separate privileged and unprivileged operating environments, and unprivileged accounts unable to log on to privileged environments. Maturity Level Three adds Secure Admin Workstations.

Most of that lives in Microsoft Entra ID or Google Workspace and is platform neutral. The macOS-specific problem is cultural: on Macs, the day-to-day user account is very often a local administrator, because that is how the machine was set up out of the box and because some applications ask for it. Fixing that means standard user accounts by default, a managed local administrator account with a rotating password, and a controlled elevation mechanism for the handful of tasks that genuinely need it.

Verdict: clean mapping, uncomfortable remediation.

Application control: this is the real gap

ASD requires that application control “restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set”, applied to user profiles and temporary folders at Maturity Level One and to all locations by Maturity Level Two, with rulesets validated at least annually.

macOS does not ship an allowlisting engine. What it ships is Gatekeeper, notarisation and XProtect. Apple’s own security documentation describes this stack accurately: Gatekeeper verifies that software “is from an identified developer, is notarised by Apple to be free of known malicious content and hasn’t been altered”, and XProtect is “built-in antivirus technology” using YARA signatures for “signature-based detection and removal of malware”.

That is a strong reputation and integrity model. It is not an organisation-approved allowlist. Apple decides what is trusted, not you. A determined user can also override Gatekeeper unless restricted by a device management service.

Your realistic options are: restrict installation to the App Store only through managed Gatekeeper policy, which is genuinely an allowlist but usually kills business applications; deploy a third-party application control product built on Apple’s Endpoint Security API; or document a compensating control set and argue it. The third option is what most Australian SMBs will do, and it must be written up properly, because ASD’s compensating-control test is equivalence of protection, not good intentions.

One useful detail for the write-up: from macOS 15 onwards, third-party security software can receive Endpoint Security API events when a user bypasses Gatekeeper, which gives you the central logging of untrusted execution that an assessor will want to see.

Verdict: genuinely imperfect. Expect to argue compensating controls.

Restrict Microsoft Office macros: half maps, half does not

Macros are not a Windows-only problem. Microsoft Office for Mac runs VBA, and Microsoft publishes managed preference keys for it. Setting the com.microsoft.office key VisualBasicMacroExecutionState to DisabledWithoutWarnings via a configuration profile disables macros and, per Microsoft, disables the user interface for changing it. Related keys let you force VBAObjectModelIsTrusted and AllowVisualBasicToBindToSystem to false and DisableVisualBasicExternalDylibs to true.

That covers Maturity Level One’s core intent: macros disabled for users without a demonstrated business requirement, and macro security settings that users cannot change.

What does not map: “Microsoft Office macros in files originating from the internet are blocked” relies on Mark of the Web, a Windows construct. “Microsoft Office macros are blocked from making Win32 API calls” is meaningless on macOS. At Maturity Level Three, Trusted Locations, the Message Bar, Backstage View and V3 signatures are all Windows concepts.

The honest position is that a Mac with macros hard-disabled by policy is more restricted than a Windows machine at Maturity Level One, and you should say so in exactly those terms.

Verdict: partial mapping. Argue over-compliance, not equivalence.

User application hardening: the most Windows-specific of the eight

Maturity Level One is easy on a Mac and slightly absurd. “Internet Explorer 11 is disabled or removed” is satisfied by the operating system not having it. The browser requirements (no Java from the internet, no web advertisements from the internet, browser security settings that users cannot change) are achievable through managed browser preferences delivered by configuration profile.

Maturity Level Two and Three are where it falls apart. Blocking Microsoft Office from creating child processes, blocking executable content, blocking code injection and preventing OLE package activation are Windows attack surface reduction rules. .NET Framework 3.5, Windows PowerShell 2.0 and PowerShell Constrained Language Mode do not exist on macOS.

Two requirements do translate and matter: “PowerShell module logging, script block logging and transcription events are centrally logged” and “Command line process creation events are centrally logged”. On macOS the equivalent is shipping shell and process execution telemetry from the unified log or from your EDR into a central log store, protected from modification and deletion. If you can show that, you have a defensible compensating control. If your Macs log nowhere, you do not.

Verdict: imperfect above Maturity Level One. Central logging is the control that saves you.

Regular backups: platform neutral, commonly failed

The requirements are about retention aligned to business criticality, synchronisation to a common point in time, secure and resilient retention, tested restoration as part of disaster recovery exercises, and unprivileged accounts being unable to access, modify or delete backups.

Nothing Apple specific. The Mac-specific failure is Time Machine to a local external drive, which fails the last two requirements outright: the user can delete it, and it is not resilient. The other common failure in a Mac-heavy business is assuming iCloud or a sync service is a backup. It is not, and neither is the Microsoft 365 or Google Workspace tenancy that your Mac users store everything in. That belongs in a backup regime that survives an incident.

Verdict: clean mapping, frequently failed in practice.

What an assessor will actually ask you

• Show me the device inventory, including every Mac, and how it is generated automatically.
• Show me the last vulnerability scan that included macOS endpoints.
• Show me the policy that sets the macOS update deadline, and the report proving devices met it.
• Show me your documented compensating controls for application control on macOS, and your evidence that they provide equivalent protection.
• Show me a Mac with a standard user account and no local administrator rights.
• Show me the central log store receiving process execution events from a Mac.
• Show me a restore test from the last twelve months that included data created on a Mac.

None of those require an Apple-specific product. All of them require the Macs to be genuinely managed rather than merely enrolled, which is why get the Macs properly enrolled and managed first is the correct order of operations, and why choosing between Jamf and Intune is a decision to make before the uplift work rather than during it.

One thing to watch

In June 2026 ASD opened consultation on evolving the Essential Eight into a broader Essentials series, with a first chapter covering enterprise IT. Nothing has changed for you yet. The Essential Eight, the Maturity Model and the assessment process guide are all still published and still the reference for contracts, insurance questionnaires and government supply chain requirements. Keep scoring against the current model, and fund controls rather than a framework name.

If you have a cyber insurance questionnaire, a client security review or a tender asking for an Essential Eight maturity level and your Macs are the part you cannot answer, call 1300 028 324 or use https://techassist.au/contact/. We will do an honest gap assessment against the current Maturity Model, including the compensating controls you will need to document for application control.

Jamf Pro and Microsoft Intune both enrol and configure Macs using Apple’s MDM protocol, but Jamf is an Apple-only platform and Intune is one console covering Windows, macOS, iOS and Android. Both are legitimate choices. The comparison is not about which is better in the abstract, it is about how many Macs you have, what you already pay for, and how much control you actually need.

Anyone who tells you one is universally superior is selling something. What follows is what each genuinely does and does not do on macOS as it stands today.

Disclosure before you read any further: we are a Jamf partner and we are also a Microsoft partner, and we run Macs under both products. Being partnered on both sides is what makes this a comparison rather than a pitch, and below you will find the cases where we tell clients not to buy Jamf.

Intune on macOS is far better than its reputation

Intune’s Mac support was thin for years and the reputation has outlasted the reality. It now covers most of what a normal business needs.

Automated Device Enrolment through Apple Business, formerly Apple Business Manager works properly. Compliance policies feed Conditional Access. The settings catalog is now Microsoft’s recommended way to build macOS policy, and it covers both Apple’s declarative configurations such as software update settings and passcode, and traditional payloads such as FileVault, firewall, Gatekeeper and system extensions. Anything Microsoft has not ingested can be uploaded as a custom mobileconfig file. FileVault management with personal recovery key escrow and rotation is supported, as is macOS LAPS for the managed local admin account on Automated Device Enrolment machines. Shell scripts run. App deployment covers volume purchased apps, signed and unsigned packages, disk images and Microsoft’s own applications.

Platform SSO with Microsoft Entra ID is generally available and is genuinely good, particularly the Secure Enclave backed Platform Credential method that Microsoft recommends. It requires macOS 14 or later in practice, the Microsoft Authenticator app, and Company Portal 5.2404.0 or later deployed before you target users.

If you run Microsoft 365 Business Premium, E3 or E5, you already own Intune. For a business with a handful of Macs beside a Windows estate, that is a strong argument on its own.

What Intune genuinely cannot do on macOS

These are the concrete gaps, each of which Microsoft documents.

Endpoint Privilege Management is Windows only. This matters more than anything else on this list. EPM is a headline component of the Intune Suite, and its documentation carries an explicit Windows applicability banner with supported file types of exe, msi and ps1. If you are being sold the Intune Suite as the answer to just-in-time admin rights on Macs, the answer is that it does not do that. Privilege elevation on macOS with Intune means scripting it yourself.

There is no Self Service equivalent. Company Portal can offer apps for a user to install on demand. It cannot publish a policy or a script for a user to run on demand. Jamf Self Service can publish policies, scripts, configuration profiles, apps, patch policies and bookmarks. For a fleet where users need to trigger a printer install, a VPN repair or a re-enrolment themselves, this is the difference between a self-service tile and a support ticket.

There are no policy triggers. Jamf documents six triggers including startup, login, network state change, enrolment complete, recurring check-in and custom events invoked on demand. Intune has no equivalent. Scripts run against the agent’s check-in cycle.

Remediations are Windows only. The detect-and-fix pattern that Windows admins rely on does not exist for macOS in Intune.

Deep device inventory is Windows only. Microsoft’s device inventory feature states that it supports Windows devices only, and that on Apple devices properties are simply collected automatically. You get what the MDM protocol returns and no control over the depth.

Third-party application patching is thin. Enterprise App Management, Microsoft’s automated patching service for non-Microsoft software, is documented as curated Win32 apps. There is no macOS equivalent. Jamf ships both App Installers, where Jamf sources and signs the packages, and classic patch management where you supply the package. Note that App Installers is a Jamf Cloud capability, so it is off the table for on-premises Jamf.

Check-in latency is real. Microsoft documents that newly enrolled Macs check in every 15 minutes for an hour and then roughly every eight hours, with maintenance syncs throttled to one every 6.5 hours. Jamf’s default recurring check-in is every 15 minutes. If you push a policy change on a Friday afternoon, Jamf lands it that afternoon and Intune may not land it until Monday.

Script behaviour is constrained. Microsoft documents scripts under 1 MB, a 60-minute timeout after which the run is marked failed, root execution by default with an option to run as the signed-in user, and an agent check-in every eight hours. Reporting is lossy in a way that trips people up: a recurring script only reports status the first time it runs, and thereafter only when the status changes.

One correction to a common claim: Intune does have an extension attribute analogue in custom attributes for macOS, which run a shell script every eight hours and return a string, integer or date, capped at 20 KB. The real gap is not that they do not exist. It is that they are reporting-only. Jamf extension attributes feed directly into smart group criteria and profile variables. Intune custom attributes cannot be used as dynamic group or filter criteria, so you can see the value but you cannot target on it.

There is more detail in a closer look at Intune on macOS.

What Jamf gives you for the extra licence

Jamf’s advantage is not a longer feature list. It is depth in three specific places.

Smart groups. Jamf evaluates group membership against the entire inventory record, including hardware, operating system, security state, disk encryption, installed applications, package receipts, local user accounts, certificates and your own extension attributes, with nested and-or logic. That is a different order of targeting precision than Entra dynamic groups plus assignment filters.

Self Service and triggers together. Publishing a self-healing action that a user can run on demand, or that fires on login or network change, removes a whole class of support ticket. This is the capability Mac-heavy shops miss most when they move to Intune.

Same-day operating system support. Jamf publishes an annual claim of same-day support for new Apple releases, most recently marking 14 consecutive years. It is a real track record and it matters when a design team updates on release day. Be clear about what it is though: it appears in press releases, not in a service level agreement, with no remedy attached. Treat it as a strong indicator, not a contractual guarantee.

The product line itself is worth getting right, because it changed recently. Jamf’s current plans are Jamf for Mac and Jamf for Mobile, each bundling Jamf Pro with Jamf Connect and Jamf Protect, plus Jamf for K-12 for schools. Jamf Now still exists and has not been discontinued, but it is now positioned for organisations under 25 employees. Jamf Trust is the end-user client app rather than a separate licence.

Licensing structure, and why we are not quoting prices

The two vendors behave completely differently here, and that difference is itself useful information.

Intune is licensed per user and is included in Microsoft 365 E3, E5, F1 and F3, Enterprise Mobility and Security E3 and E5, and Microsoft 365 Business Premium. Above that base sit Intune Plan 2 and the Intune Suite as additive add-ons, along with standalone add-ons such as Remote Help and Endpoint Privilege Management. Microsoft publishes list pricing openly on its Australian pricing page. For most Australian SMBs the marginal cost of managing Macs with Intune is zero, because the licence is already bought.

Jamf publishes no list price for any current plan. Every option is a contact request. The one published figure is a free tier in Jamf Now for up to three devices. Jamf for Mac and Jamf for Mobile are Jamf Cloud only, so on-premises customers are on a different footing. Beyond that, minimum quantities, contract terms and volume tiers are not published, which means the real answer for your fleet size can only come from a quote.

We are not going to print dollar figures here, because Microsoft’s change without notice and Jamf’s are not published at all. What you can rely on is the shape: Intune is usually already paid for, Jamf is always an additional line item, and the question is whether the capability gap justifies it.

Twenty Macs versus two hundred

Around 20 Macs, mostly Windows business, already on Business Premium or E3. Use Intune. Jamf is over-specified at this size and we say so on the call. The licence is sunk, one console is genuinely easier to run, compliance flows into Conditional Access without an integration, and the gaps are survivable at that scale because you can absorb the occasional manual task. Do not buy the Intune Suite expecting privilege management on those Macs.

Around 200 Macs, or Macs as the primary platform. Use Jamf. At that scale the missing self-service, the eight-hour policy latency and the absent third-party patching stop being inconveniences and start being headcount. Smart groups alone will save more time than the licence costs.

The middle, roughly 50 to 100 Macs. This is where it is a genuine judgement call, and the deciding factor is usually the software estate rather than the device count. A team running standard productivity software is fine on Intune. A creative or engineering team with a long tail of third-party applications that all need patching is not, because that is precisely the gap.

If you already pay for Intune, you can run both

This is the option most people do not know exists. Jamf can manage the Macs while Intune owns compliance and Conditional Access, through Microsoft’s partner compliance management integration.

Get the history right, because it changed. The old Conditional Access partner integration is retired. Jamf announced the deprecation with Microsoft and the end of support date was extended to 31 January 2025. The current path is the Device Compliance integration, configured under Device Compliance in Jamf Pro and added as a compliance partner in Intune. Some Microsoft pages still cite the older date, which is a documentation lag rather than a live option.

Practical constraints worth knowing before you commit: the integration supports Entra user groups only, and compliance policies targeted at device groups will not apply. Users must register through Jamf Self Service rather than by launching Company Portal directly. And Jamf-managed devices do not appear in Intune’s device list, so your asset view stays split.

It is more moving parts, and it is the right answer surprisingly often in a genuinely mixed Windows, Mac and Google environment, where the Macs are a meaningful population but the identity and compliance story has to stay in one place.

Our recommendation, and what it costs you

For most Australian SMBs between 10 and 200 staff with fewer than about 50 Macs, start with Intune. You already own it, one console is materially easier to operate and document, and compliance integration is native rather than bolted on.

The trade-off is real and you should accept it knowingly: slower policy delivery, no self-service for users, no on-demand or triggered actions, manual third-party patching, and no privilege management on macOS regardless of which Intune plan you buy. If those constraints start generating tickets rather than mild annoyance, that is your signal to move, and it is a signal that arrives at a fleet size rather than a date.

Whichever you choose, the platform is the smaller half of the problem. Apple’s own rules on supervision, user approval, bootstrap tokens and privacy consent apply identically to both, and they are what actually determine whether your fleet is controlled. That ground is covered in how Mac enrolment and policy actually work and sits alongside your wider approach to endpoint security across the fleet. We run Mac fleets under management alongside Windows, and we are a member of the Apple Consultants Network, Apple’s programme of independent technology partners specialising in Apple solutions for small and medium-sized businesses. That is why this comes out as a fleet-size answer rather than a brand preference.

If you want this decided on evidence rather than a vendor pitch, the useful next step is a short review of your Mac count, your existing Microsoft licensing and the applications those Macs actually run. Call 1300 028 324 or get in touch at https://techassist.au/contact/, and we will give you a straight recommendation, including when the answer is to keep using what you already pay for. We have been doing Mac support in Melbourne for over 20 years.

Mac fleet management is the practice of enrolling company-owned Macs into a device management service so that configuration, encryption, updates and software deployment are controlled centrally instead of machine by machine. The technology is mature and Apple documents it thoroughly. What catches businesses out is that macOS enforces a set of user consent boundaries that Windows does not, and no amount of MDM licensing removes them.

If you are choosing a platform to do this with, that decision is covered separately in Jamf against Intune. This article is about what happens after you have chosen, on any platform, because Apple’s rules apply to all of them equally.

There are four enrolment paths and only one of them is any good

Apple currently defines these methods, and the differences are not cosmetic.

Automated Device Enrolment. The device is in your organisation’s account in Apple Business, formerly Apple Business Manager, and enrols itself during Setup Assistant. The Mac is supervised automatically, enrolment can be made non-removable, and no technician touches the hardware. This is the only path that produces a properly controlled Mac from first boot.

Account-driven Device Enrolment. Introduced for macOS in macOS 14. The user signs in with a Managed Apple Account on a Mac already in service. On Mac this does produce supervision, which is a Mac-specific behaviour worth knowing, and it gives you data separation. It is the best available option for machines already in the wild.

Account-driven User Enrolment. Designed for personally owned devices, macOS 14 and later. Not supervised, deliberately limited, and you can only remove managed data rather than wipe the device. Correct for genuine BYOD, wrong for company hardware.

Profile-based Device Enrolment. The old manual profile install. On macOS 11 and later this still yields a supervised Mac if a local administrator approves it, which surprises people who assume manual enrolment means unsupervised. It is fine as a fallback and poor as a strategy, because the user can remove it if they know a local admin password.

The practical consequence is the same one that shows up in procurement: get the Mac into Apple Business at the point of purchase and you get path one. Miss that and you spend the next three years working around it.

User Approved MDM gates the payloads you actually care about

macOS distinguishes between an enrolment the user approved and one they did not, and the distinction is not academic. Apple’s own device management schema flags a specific set of payloads as requiring user-approved enrolment, and marks them as impossible to install by hand. They include the ones that matter most:

• Privacy Preferences Policy Control, which is how you pre-authorise security agents
• Kernel Extension Policy and System Extensions
• FileVault
• Extensible Single Sign-On, including the Kerberos variant
• Managed Login Items and Background Task Management

Without user-approved enrolment, those payloads do not apply. Your endpoint detection agent does not get the access it needs, FileVault does not enforce, and single sign-on does not deploy. Automated Device Enrolment resolves this cleanly, because the Remote Management step in Setup Assistant is itself the approval, and Apple documents that devices enrolled this way are automatically allowed to use the bootstrap token for authentication.

MDM cannot grant camera, microphone or screen recording. Ever.

This is the single most useful thing an IT manager can know about macOS, and it is the one most often got wrong in vendor sales calls.

A Privacy Preferences Policy Control profile lets you pre-approve a long list of permissions: Full Disk Access, Documents and Desktop and Downloads folders, Apple Events, Contacts, Calendars, Photos, access to other apps’ data, and more. Deploy those and the user is never prompted.

Four permissions do not work that way. Apple’s schema states, in these words, that access to the camera cannot be given in a profile and can only be denied. The same wording applies to the microphone, to screen capture, and to input event monitoring. You can block them centrally. You cannot grant them.

Anything that records the screen, joins a call with video, or watches keyboard input therefore requires the person sitting at the Mac to click Allow. That includes most remote support tools, most video conferencing, and several endpoint agents. Plan the user communication for it, because the alternative is a helpdesk queue full of tickets that all say the same thing. There is one narrow relief valve: for screen capture and input monitoring only, Apple provides an authorisation value that lets a standard user set the permission themselves without an admin password.

One change to diarise. Apple’s schema now records that the ability to grant Accessibility access through a PPPC profile is deprecated as of macOS 26.2 and will be removed in macOS 27.0. If you rely on a profile to grant Accessibility to an automation or assistive tool, that arrangement has a shelf life, and you should be testing the replacement now rather than discovering it during an OS upgrade.

Declarative device management is where updates now live

Declarative device management is Apple’s newer, asynchronous approach, in which the device applies settings and reports status itself rather than waiting to be polled. It is not a replacement protocol bolted on the side. It is part of the MDM protocol, and Apple states that software update and app configurations applied declaratively take precedence over the equivalent older commands.

For software updates specifically, the old command set is on the way out. Apple’s schema marks the legacy scheduling, availability and status commands as deprecated as of the 26 releases. More immediately, if a declarative software update configuration is active on a Mac, the legacy commands already fail today: scheduling returns an install failure and status returns nothing. If your management platform is still driving Mac updates the old way, you are managing something that has already stopped working.

Software updates on Mac are enforceable, within limits

Managed updates are genuinely good now, provided you understand the boundaries.

Deferral is set in days, from one to ninety. macOS gives you three separate deferral controls where iOS gives one: major upgrades, minor updates, and non-OS system updates such as Safari and XProtect are deferred independently. Where several policies overlap, the longest deferral wins.

Enforcement works by setting a target version and a target local date and time, expressed in the device’s own time zone so a single policy behaves correctly across sites. As the deadline approaches, notifications escalate, and Apple states that Do Not Disturb is ignored in the final 24 hours. At the deadline macOS force-quits open applications regardless of unsaved documents and restarts. Tell people that before you turn it on.

Two constraints that bite:

On Apple silicon, enforcement depends on the bootstrap token. The Mac retrieves it from your management service to authorise the update without a human. No token, and the user gets a credential prompt instead, which means the enforcement quietly does not happen.

There is no way to hold a Mac fleet on a major version indefinitely. iOS and iPadOS have a cadence control that lets you offer only the older release. macOS has no equivalent. You have deferral, capped at ninety days, and that is the whole toolkit. If you have a critical application that is not yet certified on the next major macOS, ninety days is your runway. Budget vendor pressure accordingly.

FileVault: escrow the personal key, and stop using institutional keys

Apple’s guidance here has changed and a lot of documentation has not caught up.

Apple now states that institutional recovery keys provide no functional value on Apple silicon, because they cannot be used to access recoveryOS and target disk mode no longer exists, and that institutional keys are no longer recommended for managing FileVault on Mac. Use the personal recovery key and escrow it.

The mechanics: your management service supplies a public key as a certificate, the Mac encrypts the personal recovery key against it, and returns it. Because the encryption is asymmetric, whether your platform can actually decrypt and show you that key is a property of the platform, not of macOS. Test a real recovery before you need one. An escrowed key you cannot read is not a backup.

Standard MDM enablement is deferred: FileVault turns on at a user login or logout rather than instantly, and you control how many times the user may defer and whether they see the key. If the Mac came through Automated Device Enrolment, macOS 14 and later can force FileVault on during Setup Assistant instead, which removes the deferral problem entirely. Store the recovered keys somewhere that survives a laptop failure, which is a password management question as much as an MDM one.

The bootstrap token is the thing nobody knows about until it breaks

A bootstrap token is generated by macOS and escrowed to your management service, and it is what lets the Mac perform privileged operations without a person present. Your management platform has to advertise support for it, and the Mac escrows it on first login by a user with a secure token.

Without one, on Apple silicon:

• Enforced software updates prompt the user for credentials rather than proceeding
• Erase All Content and Settings is not supported, and an erase command falls back to obliteration, which means macOS has to be reinstalled from scratch
• Second and subsequent users do not get secure tokens, so they cannot unlock FileVault

Nearly every mystifying macOS management fault we are called into turns out to be a missing or stale bootstrap token. Check that your platform is collecting them, and check it per device rather than assuming.

Kernel extensions are a procurement problem, not a technical one

Apple’s position is unambiguous: kernel extensions are no longer recommended, and vendors should use system extensions, which run in user space. System extensions are approved centrally by team identifier through a profile, and that works well.

Kernel extensions on Apple silicon require the startup security policy to be set to Reduced Security. For an unenrolled Mac or one on User Enrolment, that means the user holding the power button to enter recoveryOS, authenticating as a local administrator, and changing the policy. Apple is explicit that only entering recoveryOS by power button press causes the Secure Enclave to accept the change, so it cannot be scripted. Under Automated Device Enrolment, Apple documents that management services can handle this automatically, which is one more argument for getting enrolment right at purchase.

The practical upshot is that if a software vendor still ships a kernel extension in 2026, that is a red flag about the vendor. Ask before you buy, not during rollout.

Local admin rights: you can set them, you cannot easily change them

Apple gives you real control at enrolment and almost none afterwards.

Through Automated Device Enrolment you can have Setup Assistant create the user’s account as a standard user, create a managed administrator account alongside it, hide that admin account from view, and rotate its password remotely. That is a solid baseline and it is what a well-built fleet uses.

What does not exist is an Apple command to promote or demote an arbitrary existing account. If a Mac was set up with the user as an administrator, no MDM will demote them natively. It requires scripting against the local directory, which means your platform’s scripting capability is the deciding factor, and that is one of the sharper differences between platforms discussed in the limits of Intune on macOS.

One trap worth flagging: Apple notes that remotely changing the managed admin password updates the login password but not the secure token password if that account has become secure token enabled. That desynchronisation produces an account that logs in but cannot unlock FileVault, and it is genuinely unpleasant to unpick.

The bits that reliably break

Devices bought outside Apple Business. They can be added later with Apple Configurator, but Configurator-added devices carry a 30-day window in which the user can release them from management. Buy through the right channel and the window never exists.

Major OS upgrades. Ninety days of deferral, no cadence control, and an application vendor who is not ready. Start compatibility testing when the beta appears, not when the deadline does.

Activation Lock. If a Mac has Activation Lock enabled by a personal Apple Account before it enrolled, Apple states you cannot turn it off through management. Only the user can. And bypass codes must be captured and retained, because Apple’s warning is direct: if you change management platforms, make sure you receive a copy of those codes or that the outgoing platform clears Activation Lock for every enrolled device first. This is the most expensive migration mistake in the Apple world.

Erase commands on Apple silicon without a bootstrap token. Obliteration rather than a clean erase, and a machine that needs a full reinstall.

Conflicting profiles. Apple states plainly that where multiple profiles carry the same payload with different settings, the resulting behaviour is undefined. Do not layer policies and hope.

Getting this right is ordinary work, but it is Apple-specific work, and it does not transfer from a Windows background. That is the substance behind why most Melbourne providers cannot support Macs properly. It also has to line up with your wider endpoint security and device management posture, your compliance position as set out in the Essential Eight on macOS, and your identity architecture if you are running Windows, Mac and Google side by side. We run Mac fleets under management alongside Windows, through Apple’s business deployment programmes, as a member of the Apple Consultants Network, Apple’s programme of independent technology partners specialising in Apple solutions for small and medium-sized businesses, and as a Jamf partner. None of the above is theory.

If you have Macs that are enrolled but not actually enforcing anything, the fastest useful step is an audit of supervision status, bootstrap token presence and FileVault key escrow across the fleet. Call 1300 028 324 or get in touch at https://techassist.au/contact/ and we will tell you which of your Macs you could actually recover, wipe or update today.