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.