Managing a Mac Fleet: Enrolment, Policy and the Bits That Break

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.

A mixed fleet is a business running more than one desktop platform and more than one productivity suite at the same time, most commonly Windows with Microsoft 365 alongside Macs and Google Workspace. Almost every Melbourne business over about thirty staff is one, whether anyone planned it or not. The design team bought Macs, the accounts team runs Windows because the practice software demands it, and the founder set up Google Workspace in 2016 and never looked back.

Most providers respond to this by proposing a migration. That is usually a sales position rather than a technical one. A mixed fleet is entirely runnable, but only if you are honest about which layer must be unified and which layers should be left alone.

Identity is the only thing you genuinely must unify

Everything else in a mixed environment can be tolerated. Two identity stores cannot.

The moment a person exists as a separate account in Microsoft 365, in Google Workspace and again in Apple’s ecosystem, you have three joiner processes, three leaver processes and three places to enforce multi-factor authentication. When someone resigns on a Friday afternoon, the account you forget is the one that gets used. This is the single most common failure we see in businesses that grew into a mixed fleet rather than designing one.

Unified identity does not mean one vendor. It means one authoritative directory that every other system trusts, and one onboarding and offboarding checklist that closes every door at once.

Make Entra ID the anchor and Google the relying party

If you are running both suites, the direction of federation is not a matter of taste. It is determined by what the two vendors actually support.

Microsoft publishes a first-party integration for using Microsoft Entra ID as the identity provider for Google Workspace, listed in the Entra gallery as the Google Cloud / G Suite Connector by Microsoft, with SCIM provisioning alongside it. Google documents the other half from its side, confirming that Workspace supports single sign-on from third-party identity providers over both SAML and OIDC, and ships a pre-built Microsoft Entra OIDC profile.

The reverse is not a supported architecture. Microsoft’s Google federation feature is scoped to business-to-business guest users, and Microsoft states plainly that it no longer performs validation testing of independent identity providers for compatibility with Entra ID. Anyone proposing Google Workspace as the primary identity provider for a Microsoft 365 tenancy is proposing something neither vendor documents.

One caveat worth writing into your runbook: Google restricts single sign-on for super administrators, and super admins signing in to the admin console must use their Google password rather than federated credentials. Keep at least one break-glass Google super admin outside single sign-on, store the credential properly, and test it. If you skip this, read what happens when you are locked out of your Google Workspace admin account before you find out the hard way.

Apple will federate with one identity provider, not two

Apple Business, the portal formerly known as Apple Business Manager, can federate with Google Workspace, with Microsoft Entra ID, or with a generic provider over OIDC or SCIM. Apple’s documentation is explicit that you can link to one of these at a time, not several.

That single sentence settles a lot of architectural arguments. If your Macs and iPhones are going to draw their Managed Apple Accounts from a directory, you must choose which directory, and in a Microsoft-anchored environment that is Entra ID.

There is a second trap here that catches people badly. Before Apple will federate a domain it must be verified and captured, and turning on Domain Capture gives every staff member with a personal Apple Account on your company domain a fixed thirty days to move their personal data off it. Apple states the date cannot be extended and that turning on Domain Capture cannot be undone. Staff with a decade of personal photos and App Store purchases attached to a work email address will not take this well if it lands unannounced. Communicate before you press the button, not after. The full sequence is covered in the guide to Apple Business, the portal formerly called Apple Business Manager.

Device management does not consolidate, and that is fine

Identity converges. Device management does not, and chasing a single pane of glass here usually costs more than it saves.

Windows provisioning through Autopilot, macOS enrolment through Apple’s Automated Device Enrolment, and Chrome or Android enrolment through the Google admin console are three genuinely different pipelines with three different trust models. One console can hold all three records, but the underlying work is still platform-specific. What matters is that every device is enrolled in something, that the something reports compliance back to your identity provider, and that nothing is unmanaged.

If you already pay for Microsoft 365 Business Premium or E3, you already own Intune, and Intune will manage Macs. Whether it manages them well enough is a real question with a real answer, covered in what Intune can and cannot do on a Mac and in the head-to-head on Jamf and Intune compared honestly. The practical mechanics of enrolling and managing a Mac fleet are a separate discipline again, and it is the one most generalist providers quietly skip. We have written separately about why most Melbourne MSPs cannot support Macs properly, because the gap is structural rather than a matter of effort.

On the Google side, the equivalent baseline work is in the Google Workspace admin console settings that matter, and the day-to-day device story sits alongside your broader approach to mobile device management.

Running both suites costs more than two subscriptions

The licence line is the visible cost. It is rarely the largest one.

Only one system can own your mail. Your domain has one set of MX records. Google documents split delivery and dual delivery as the two ways to run a second mail platform alongside Gmail, and in both cases the second system receives forwarded copies rather than authoritative delivery. You pay for two mail platforms and get one authoritative mailbox store, plus permanent complexity in SPF, DKIM and DMARC alignment on forwarded messages.

Storage entitlements do not travel. Google’s pooled storage is pooled within Google. Microsoft’s mailbox and OneDrive quotas are entitlements within Microsoft. Buying more of one never offsets the other, and staff will keep the same files in both, so you pay twice to store the same bytes. Neither vendor is backing that data up for you either, which is the subject of Google is not backing up your Workspace data.

Policy parity requires an edition uplift on both sides. Conditional Access on the Microsoft side requires Entra ID P1, which is included in Microsoft 365 Business Premium and E3. The nearest Google equivalent, Context-Aware Access, is restricted to the Enterprise, Education and Frontline editions or to Cloud Identity Premium, and Google states that users without a supported edition are simply not subject to Context-Aware Access policies at all. That Google-side uplift is the cost most businesses miss, because it is not a security add-on you buy for a handful of people. It is an edition change across every user.

We are not going to publish a dollar figure here, because the honest answer depends on your exact mix of editions. What we will say is that the second suite is almost never as cheap as the second subscription line suggests.

Your security baseline does not translate across platforms

This is where mixed fleets quietly fail audits and cyber insurance questionnaires.

The Essential Eight is the framework Australian businesses are measured against, and read closely it is shaped around Microsoft products. The current maturity model, last updated in November 2023, contains no mention of macOS, Apple, iOS, Chrome or Google anywhere in the document. One of the eight strategies is restrict Microsoft Office macros, and at Maturity Level Two and above it requires blocking macros from making Win32 API calls, which is Windows-only by definition. Application control at Maturity Level Two and above requires implementing Microsoft’s recommended application blocklist. User application hardening names Internet Explorer 11 and PowerShell logging.

ASD’s own hardening library reflects the same shape. It publishes hardening guides for Windows 10, Windows 11 and Linux workstations. There is no enterprise macOS hardening publication at all, and the only Apple configuration guide covers iOS 14. Its Blueprint for Secure Cloud is described by ASD as having a current focus on Microsoft 365, with no Google Workspace equivalent.

None of that means a Mac fleet cannot be secured to an equivalent standard. It means the equivalence has to be argued and documented rather than assumed, using the model’s own allowance for vendor hardening guidance and its exceptions process. Do that work before an assessor asks, not during. The detail sits in mapping the Essential Eight onto macOS and whether you can meet the Essential Eight on Google Workspace, and the underlying platform hardening in hardening Google Workspace.

One more thing worth knowing if you are planning a multi-year uplift: ASD ran a consultation on the evolution of the Essential Eight that closed on 12 July 2026, proposing a new Essentials series with the current guidance becoming a chapter called Essentials for enterprise IT. ASD says existing adopters can expect strong alignment with their current controls. Build your roadmap anyway, but build it knowing the framework is being rewritten.

When consolidating actually is the right call

Sometimes the migration everyone keeps proposing is correct. The honest triggers are these.

Consolidate when the duplication is at the identity layer and cannot be federated away. Consolidate when a compliance obligation or a client security review requires a single enforceable policy set and you cannot demonstrate equivalence on the second platform. Consolidate when the second suite is used by fewer people than it costs to administer properly. Consolidate when the business is being sold or is acquiring, because two suites double the integration work later.

Do not consolidate because one platform is unfamiliar to your provider. That is their problem to fix, not yours to pay for.

If you do decide to move, move deliberately. The comparison itself is covered where we have already compared the two suites feature by feature, and the actual migration mechanics, including what breaks in shared drives and calendar delegation, are in the mechanics of moving off Google Workspace. If you have inherited an environment and cannot even establish who owns what, start with inheriting a Workspace tenancy nobody documented.

What a properly run mixed fleet looks like

One authoritative directory. Every other platform federated to it, including Apple. Every device enrolled in a management service appropriate to its platform, reporting compliance back to that directory. One documented joiner and leaver process that touches every system. A written, defensible mapping of your security baseline onto each platform, including the parts where the framework does not fit and you have documented an equivalent control instead. And a hardware lifecycle that does not depend on who happened to buy the laptop, which is the subject of buying, redeploying and disposing of Apple hardware.

That is achievable at 30 staff and at 200. What it requires is a provider who is competent on all three platforms rather than one who tolerates two of them: someone who works with Apple’s business deployment programmes for enrolment and device management, runs Entra ID and Intune as daily work rather than as an escalation, and can open the Google Admin console and tell you what is wrong with it.

TechAssist has run Windows, Mac and Google environments side by side for Melbourne businesses for over 20 years, with 13 certified specialists across the team. We are a Microsoft partner and a Jamf partner, and on the Apple side 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 combination is the point rather than the decoration. A provider holding partnerships on both sides of an argument has no commercial reason to steer the answer, and the only honest test of neutrality is whether they ever recommend the option that earns them less. We do that regularly, and you will find us doing it in the posts linked above. If you want a straight assessment of whether your mixed fleet should be unified or simply run properly, call 1300 028 324 or get in touch at https://techassist.au/contact/. We will tell you which of the two it is, including when the answer is that you do not need to change anything.

Mobile device management is how you keep company email and data secure when staff read it on phones, tablets and personal laptops you don’t own. The real problem with bring-your-own-device (BYOD) is the privacy trade-off, and the fix is usually app-protection policies that secure the company data inside an app without taking control of someone’s entire personal phone.

The problem MDM and MAM actually solve

The moment a staff member adds their work Microsoft 365 account to the Mail app on their own iPhone, your company data is sitting on a device you have no control over. No screen lock policy, no encryption guarantee, no way to remove the data if the phone is lost or the person leaves. Multiply that across a 40-person business and you have email, OneDrive files and Teams chats scattered across dozens of unmanaged personal devices.

This is the gap two related technologies close. Mobile device management (MDM) manages the whole device — it enrols the phone or laptop and enforces a passcode, encryption and OS version, and gives you the ability to wipe it. Mobile application management (MAM), or app-protection policy, manages only the company apps and the data inside them. It can require a PIN on the work app, block copy-paste out to personal apps, and wipe just the company data, while never touching the photos, messages or personal accounts on the device.

The distinction matters because most BYOD failures aren’t technical — they’re about trust. Staff don’t want their employer controlling their personal phone, and they’re right to be cautious. MAM answers that objection, and getting the choice right is the difference between a policy people accept and one they quietly work around.

The BYOD privacy tension, and why it kills full enrolment

Ask any team to enrol their personal phones in full MDM and you’ll hear the same fear: “Can the company read my texts? Can they wipe my photos?” With full device enrolment, the honest answer is that the company can see device-level inventory, push configuration, and yes, issue a full wipe that takes the personal data with it. Even when an MSP would never do that, the perception alone pushes people to refuse, use a second unmanaged device, or forward work email to a personal account — far worse for security than the problem you started with.

App-protection policy removes the objection. The company gets a security boundary around its own data — the work account, its files, its email — and the staff member keeps full ownership of everything else. When they leave, you wipe the company container and their holiday photos are untouched. For BYOD this is almost always the right model; you reserve full device management for hardware the business actually owns.

Microsoft Intune: the tool most Melbourne SMEs already have

If you’re on Microsoft 365 Business Premium or any E3/E5 licence, you already own Microsoft Intune — it’s bundled, which is why it’s the default MDM/MAM platform for businesses in our patch. Intune does both jobs from one console and ties into the rest of the Microsoft security stack. Four pieces do the heavy lifting.

Device compliance policies

A compliance policy defines what “healthy” means for a device: minimum OS version, disk encryption on, a passcode of a set length, not jailbroken or rooted. Intune continuously checks enrolled devices and marks each one compliant or non-compliant. On its own this is just a status flag — its power comes from what you connect it to.

App protection policies

This is the MAM layer. An app-protection policy applies to the Microsoft apps (Outlook, Teams, OneDrive, the Office apps) and governs the data inside them. You can require a separate PIN or biometric to open the work app, block cut/copy/paste into personal apps, stop “Save As” to personal storage, encrypt company data, and force a selective wipe of only the in-app company data on command. Critically, this works whether or not the device is enrolled in MDM at all.

Conditional access

Conditional access is the enforcement engine, and it lives in Microsoft Entra ID rather than Intune itself. It evaluates each sign-in and applies rules — for example, only grant access to Exchange Online if the device is marked compliant, or only allow Outlook if an approved app-protection policy is applied. That turns a compliance flag into a real control: a non-compliant or unmanaged device simply doesn’t get the data. We go deeper in our guide to conditional access policies in Microsoft 365.

Selective wipe at offboarding

When someone leaves, you don’t chase their personal phone. From the Intune console you issue a wipe of company data — on a MAM-protected BYOD device that removes the work account and its cached files and leaves the rest alone; on a company-owned enrolled device you can do a full wipe and reset. Combined with disabling the account, this is how secure offboarding actually happens — the step most businesses skip until a former employee still has live access three weeks later.

MDM full enrolment vs MAM app-protection

The single most useful decision in any BYOD rollout is which of these two models a given device gets. Here’s how they compare.

In practice a typical setup uses both: full MDM on the laptops and phones the business bought and owns, and MAM-only app-protection on staff personal devices, with conditional access requiring one or the other before any company data is released.

Company-owned vs BYOD enrolment paths

The enrolment path follows ownership. For company-owned devices, you enrol into full MDM — on iOS usually through Apple Business Manager so the device is supervised and locked to your tenant from first boot; on Windows it’s Autopilot, which ships a laptop that configures itself at first sign-in. These get the full set of compliance and configuration policies because the business owns the hardware.

For BYOD, you avoid full enrolment wherever you can. The staff member installs the standard Microsoft apps, signs in with their work account, and the app-protection policy applies automatically — no enrolment, no agent on the device, nothing that touches their personal data. Where a BYOD device genuinely needs full management you use a model that ring-fences the work side, such as a work profile on Android, but for most SMEs MAM-only covers it without the friction.

How this maps to the Essential Eight and secure offboarding

Mobile device management isn’t a standalone exercise — it’s how several Essential Eight controls reach the devices outside your office walls. The Australian Cyber Security Centre (ACSC) Essential Eight expects multi-factor authentication, patched operating systems and applications, and restricted admin privileges. Intune enforces those on a phone or laptop you can’t physically touch: compliance policies hold devices to a current, patched OS; conditional access pairs with MFA so a stolen password alone doesn’t open the mailbox; and app-protection keeps company data inside sanctioned apps.

Offboarding is where the absence of MDM gets expensive. We worked with a construction firm in Box Hill that had no device management at all — staff used personal phones for site photos, email and the project app. When a site supervisor left for a competitor, the business had no way to remove its data from his phone and no record of what he could still reach. With Intune in place, offboarding is a five-minute job: disable the account, issue a selective wipe of company data, done. That firm now runs MAM on every personal device and full MDM on the company-issued tablets on site.

A sensible BYOD plus MDM policy outline

We have a separate post on writing the BYOD policy itself; here the focus is the technical controls it should mandate. A workable policy ties the rules to enforceable Intune settings rather than good intentions:

• Eligibility. Define which roles may use BYOD and which must use company-owned devices — sensitive client or health data often warrants company hardware.
• Minimum device standard. Require a supported, currently-patched OS and a device passcode or biometric, blocked by conditional access if not met.
• App-protection mandatory. Company data is accessed only through the approved Microsoft apps with app-protection applied — no native mail clients, no forwarding to personal accounts.
• Access conditions. Conditional access requires a compliant or app-protected device before email, files or Teams are released.
• Separation of data. Block copy, paste and “Save As” from work apps into personal storage so company data can’t leak sideways.
• Offboarding and loss. State in writing that the business will selectively wipe company data on exit or device loss — never personal data on a BYOD device — with a single point of contact who actions it the same day.

The policy and the platform have to match. “Devices must be encrypted” means nothing if no system checks; a compliance policy that enforces it does. That pairing — written rules backed by enforced technical controls — is the whole point, and the part most businesses get half-right.

Frequently asked questions

Can my employer read my personal texts or photos if I enrol in MDM?

On a personal BYOD device set up with app-protection (MAM) only, no — the business sees nothing outside the work apps and cannot read your messages, photos or personal accounts. On a company-owned device in full MDM, the business can see device inventory and configuration and can issue a full wipe, which is exactly why we keep full enrolment for company-owned hardware and use app-protection for personal devices.

What’s the difference between MDM and MAM?

MDM (mobile device management) manages the whole device — passcode, encryption, OS, all apps — and is right for company-owned hardware. MAM (mobile application management, or app-protection policy) manages only the company apps and the data inside them, leaving the rest of a personal device alone. For BYOD, MAM is almost always the better fit.

Do I need extra licences for Microsoft Intune?

Usually not. Intune is bundled with Microsoft 365 Business Premium and the E3 and E5 plans, so most SMEs on those licences already own it and aren’t using it. On a lower plan it’s available as an add-on, but for most Melbourne businesses the capability is already paid for.

What happens to company data when someone leaves?

You issue a selective wipe from the Intune console, removing the company account and its cached files. On a BYOD device that’s all it touches — personal data stays put. Pair it with disabling the user’s account so access is revoked immediately. That’s the secure offboarding step businesses without device management can’t perform.

Getting it set up properly

Intune is powerful, but a misconfigured rollout either locks staff out of email or quietly enforces nothing. The work is in the detail: scoping which devices get MDM versus MAM, writing conditional access that doesn’t break legitimate access, and tying offboarding into a repeatable process. As a Melbourne MSP founded in 2014 with 13 Australian-employed engineers, we set up and run Intune across the metro as part of our cybersecurity services and managed IT services, on per-user fixed monthly pricing so it isn’t a surprise line item. If staff devices are reaching your company data with no controls in place, get in touch and we’ll map out what BYOD security should look like for your business.

Windows Autopilot is a Microsoft service that lets a brand-new laptop set itself up automatically the first time a staff member turns it on. The device ships from the vendor straight to the user, connects to your Microsoft tenant over the internet, and configures itself — no imaging, no SOE, no IT hands on it.

If onboarding a new hire still means a laptop landing on an engineer’s desk for a day of imaging, this is the fix. Below: what Autopilot does, how a device self-provisions, the moving parts, the deployment modes, the licensing, and where an MSP fits in.

What Windows Autopilot actually is

Autopilot is not an imaging tool — there is no gold image and no USB stick. It takes the standard Windows installation the manufacturer already put on the device and transforms it into your corporate build during the out-of-box experience (the setup screens a user sees on first boot). It runs on two Microsoft cloud services: Microsoft Entra ID (formerly Azure AD) handles identity and joins the device to your directory, and Microsoft Intune — the mobile device management (MDM) platform inside Microsoft 365 — pushes down your policies, apps, baselines and configuration. A machine the user has never touched arrives configured exactly like every other device in the business, enrolled, encrypted and ready to work.

The problem it solves: no more manual imaging or SOE

The traditional approach was the Standard Operating Environment: you built a master image, captured it, and re-applied it to every new or rebuilt machine. The costs add up. Devices have to be shipped to IT first, imaged, then re-shipped to the user — adding days and double the freight. The image goes stale the moment it is captured and needs constant rebuilding. And it does not scale: imaging a laptop for someone starting in a Dandenong warehouse means shipping it to your office or sending an engineer out.

Autopilot removes the imaging step entirely. The configuration lives in the cloud and is applied at first boot, so the same provisioning works whether the user is in your CBD office or at home in Ringwood.

How a device self-provisions on first login

The sequence when an Autopilot-registered device is unboxed:

1. The user powers on the laptop and connects to Wi-Fi or ethernet — internet access is the only prerequisite.
2. Windows checks in with Autopilot, recognises the device by its hardware identity, and pulls down the assigned profile, which customises the setup screens and applies your branding.
3. The user signs in with their Microsoft 365 work account; Entra ID authenticates them and joins the device to your directory.
4. Intune enrolment kicks off automatically, pulling down your configuration profiles, security baseline, certificates, Wi-Fi settings and assigned apps.
5. The Enrollment Status Page blocks the user from reaching the desktop until the mandatory apps and policies have landed.

When it finishes, the first person to log into that machine is the staff member it was bought for — not an engineer — at a fully managed, encrypted desktop.

The moving parts

Autopilot profiles

A profile is the deployment template you assign to a group of devices in Intune. It controls the out-of-box experience: which setup screens are hidden, whether the user becomes a local administrator or standard user, the deployment mode, the naming convention and your branding. Most businesses run one or two — a user-driven profile for staff laptops, sometimes a separate one for shared devices.

The Enrollment Status Page

The Enrollment Status Page (ESP) shows setup progress and gates access to the desktop until the apps and policies you mark mandatory have installed — so a new starter cannot begin work on a half-configured machine. Block on a slow or flaky app, though, and you leave users staring at a spinner; tuning it well is one of the fiddlier parts of the job.

Hardware hash and device registration

Autopilot identifies each device by a hardware hash — a unique fingerprint of its components — which must be registered against your tenant before first boot. With OEM / CSP registration, the hardware vendor or Cloud Solution Provider partner registers the hash to your tenant at purchase, so the device is Autopilot-ready before it leaves the warehouse — the clean path for volume orders. For devices you already own, manual hash collection exports the hash into Intune with a PowerShell script, but that means handling the device once. Build OEM or CSP registration into your procurement so hardware arrives pre-registered; that is what makes true drop-ship onboarding possible.

Deployment modes: user-driven vs self-deploying and kiosk

Autopilot supports several modes, depending on how the device will be used:

User-driven is what most growing teams use. Self-deploying and kiosk modes suit devices no single staff member owns — a reception terminal in a Hawthorn clinic, a warehouse scanning station — and need a TPM 2.0 chip, which any recent business device has.

Prerequisites: what you need before you start

Autopilot is not a standalone product — it is a capability on top of Microsoft 365. You need:

• Microsoft Entra ID for identity and device join — the standard directory in a Microsoft 365 business or enterprise subscription covers this, though some advanced enrolment options want Entra ID P1.
• Microsoft Intune licensing for the MDM management — included in Microsoft 365 Business Premium and the E3/E5 plans. On a cheaper plan you will need to add Intune first.
• Devices that ship with Windows 11 Pro or Enterprise — the Home edition cannot be managed this way.
• A configured tenant — your Intune profiles, security baselines, app deployments and ESP set up before the first device ships.

That last point is the one businesses underestimate: Autopilot delivers whatever you have built in Intune, so the value is in the policies and app packaging, not the provisioning trick itself. If you are reviewing your licensing, our Microsoft 365 support team can tell you whether your plan already covers what Autopilot needs.

Why this matters: fast onboarding and consistent security baselines

Two things drive most businesses to Autopilot. The first is onboarding speed: a drop-shipped self-provisioning laptop takes the engineer, the queue and the freight out of every hire. The second, and arguably more important, is consistent security baselines. Because every device is built from the same Intune configuration, every machine gets BitLocker encryption, the same firewall and account-protection policies, Defender, conditional access and patching automatically — no engineer remembering to tick a box. An enforced baseline across the fleet is exactly what the Essential Eight mitigation strategies expect, and the same Intune layer lets you wipe a lost device remotely the moment a laptop goes missing on a train at Box Hill — it pairs naturally with conditional access policies in Microsoft 365.

A Melbourne scenario

An engineering consultancy in Camberwell we work with was hiring two or three people a month and rebuilding laptops by hand each time — a machine couriered to their office, half a day of imaging, and a checklist someone occasionally skipped, so no two laptops were quite the same and a couple shipped without disk encryption on.

We stood up their Intune configuration, built a user-driven Autopilot profile with a tuned Enrollment Status Page, and arranged for new hardware to be registered at purchase. Now a laptop is drop-shipped to the new hire; they open the box, sign in, and an hour later are working on a fully configured, encrypted device identical to everyone else’s. Their office manager handles onboarding without touching a technical step, and the fleet has a uniform baseline at last.

The MSP role in setting it up

The provisioning is the easy part to demonstrate and the hard part to build well. The work an MSP does sits underneath what the user sees:

• Designing and hardening the Intune configuration — the compliance policies, configuration profiles, security baselines and app deployments every machine inherits — and packaging line-of-business apps to install silently during enrolment.
• Setting up the procurement pipeline so devices arrive Autopilot-ready, tuning the ESP, and integrating Autopilot with conditional access, encryption and your broader MDM strategy so device management is one coherent system.

TechAssist is a Melbourne MSP, founded in 2014, with thirteen Australian-employed engineers — so the people building your Intune environment are local, not offshore. We bundle this into our managed IT services, so device provisioning, patching and security baselines sit inside the fixed monthly per-user fee, not a per-device charge each time you hire.

Frequently asked questions

Do I need to wipe a new laptop before using Autopilot?

No. Autopilot works with the standard Windows installation the manufacturer ships and transforms it into your corporate configuration during first boot — there is no wiping or imaging step. Devices you already own can be reset and will provision on the next boot once registered.

What happens if there is no internet during setup?

Autopilot needs internet to reach Entra ID and Intune, so the device must connect to Wi-Fi or ethernet during the out-of-box experience. Until it does, the laptop sits at the network screen — which is why drop-ship onboarding assumes the user has working internet.

Is Autopilot the same as Intune?

No, but they work together. Intune is the management platform that holds your policies, apps and baselines; Autopilot hands a new device over to Intune at first boot. You need Intune licensing for Autopilot to do anything.

Where TechAssist fits

Autopilot looks like magic in a demo and falls over in practice if the Intune configuration behind it is thin — the provisioning is the visible part, but the policies, baselines and procurement pipeline are what make the fleet secure and consistent. If manual device setup is slowing your onboarding, get in touch and we will scope what your tenant needs.