Apple Device Lifecycle: Buying, Enrolling, Redeploying and Disposing

The decision that determines how painful the next four years will be is made at the purchase order, not at deployment. Buy Apple hardware through a reseller linked to your Apple Business account and every device enrols itself, stays supervised and can be recovered when an employee leaves. Buy the same machine at retail and you inherit a manual process and, eventually, an Activation Lock problem.

This is the end-to-end lifecycle for an Australian business: procurement, enrolment, assignment, redeployment, the Activation Lock trap, residual value, and what the law actually requires when the device reaches the end of its life.

First, a naming change that matters

Apple replaced Apple Business Manager with a service called Apple Business on 15 April 2026. Apple’s own announcement is explicit: “Apple Business Manager and Apple Business Connect will no longer be available once Apple Business launches”, and Apple Business is “available as a free service” across more than 200 countries and regions. Apple Business is Apple’s free web platform for buying, assigning, enrolling and managing company-owned Apple devices, and it now includes built-in mobile device management alongside the brand and location tools that used to live in Business Connect.

Everything below uses the current naming. If your documentation still says Apple Business Manager, or your provider does, that is a small but useful signal. More on that in Apple’s business device portal.

Procurement: the ABM-linked reseller versus retail decision

Zero-touch deployment only works when Apple knows the device belongs to you. Apple’s own footnote on the Apple Business launch says it plainly: “Zero-touch deployment is available when devices are purchased through Apple or Apple Authorised Resellers.”

How the link works. You exchange three identifiers, and people mix them up constantly:

• Organisation ID is your unique identifier in Apple Business. You give this to your reseller.
• Reseller Number identifies the Apple Authorised Reseller or authorised carrier. You add this to your account.
• Apple Customer Number is the account number Apple assigns your organisation for purchasing. Apple notes this is not the same as your GSX account number, and to omit leading zeros.

The step almost everyone misses is in Apple’s own documentation: after the identifiers are exchanged and verified, you must arrange with the reseller to submit your orders through their portal, because “it won’t happen automatically”. Devices do not appear in Apple Business just because you bought them from a participating reseller. Someone has to lodge the order correctly.

Apple publishes a list of Preferred Device Enrolment Resellers for Australia, which is the right place to check before you commit to a supplier. If your incumbent hardware supplier is not on it and will not lodge your Organisation ID, that is a reason to change supplier, not a reason to change your deployment model.

What retail purchases cost you. Devices bought at an Apple Store, JB Hi-Fi or anywhere else can still be added, using Apple Configurator. Apple Configurator for iPhone can add iPhone, iPad, Apple Vision Pro and Mac (Apple silicon or T2, macOS 12.0.1 or later). Apple Configurator for Mac can add iPhone, iPad and Ethernet-model Apple TV, but cannot add Macs.

The catch is real and worth knowing before you rely on it. Apple’s documentation states that after a device is added this way and handed to a user, “they have a 30-day provisional period to release the device from Apple Business, supervision, and the device management service”. A device supplied through the reseller channel has no such escape hatch. If you are buying at retail to save a few days on lead time, understand that you are also handing every new starter a one-month opt-out from management.

You also have to catch each device at a specific Setup Assistant screen (macOS at “Select Your Country or Region”, iOS and iPadOS at “Choose a Wi-Fi Network”). Miss it and you restart the machine and try again. It is fine for one device. It does not scale.

Enrolment and assignment

Automated Device Enrolment is designed, in Apple’s words, for devices an organisation owns, and “lets organisations configure and manage devices from the moment someone removes a device from its box”. A device enrolled this way is automatically supervised on iOS 13, iPadOS 13.1, macOS 10.14.4 and later.

Supervision is not a bureaucratic nicety. Several controls only work on a supervised device. Apple’s Privacy Preferences Policy Control payload, the one that pre-approves your management agent, security agent and backup client for the access they need, states that “supervision is required if you apply this payload using a device management service”. Without it, every agent you deploy throws consent dialogs that users dismiss, and half your tooling silently does nothing.

The assignment checklist that actually matters:

1. Device appears in Apple Business with the correct serial number and order.
2. Device assigned to your device management service before it is unboxed.
3. Enrolment profile set to mandatory and non-removable.
4. Managed Apple Account created for the user, so organisational data stays separate from anything personal.
5. FileVault enabled with the recovery key escrowed and a test retrieval performed.
6. Bootstrap token escrowed to your management service. On Apple silicon Macs this is required for a remote erase to work later.
7. Asset record created, linking serial number to person, cost centre and purchase date.

Steps 5, 6 and 7 are the ones skipped under time pressure and the ones you regret. The mechanics sit in enrolment, policy and the bits that break, and the asset side belongs with IT asset management that holds up.

Redeployment when someone leaves

Redeployment is an offboarding problem before it is a hardware problem. The sequence that works:

1. Disable the user’s directory account and revoke sessions.
2. Confirm their data is in the tenancy, not only on the device.
3. Clear Activation Lock before you erase (see below, this order is not negotiable).
4. Issue a remote erase from your management service.
5. Verify the device reappears in Apple Business unassigned and clear of Activation Lock.
6. Reassign to the next user, or route to trade-in or disposal.

If your offboarding process does not include steps 3 and 5, you are building a cupboard full of expensive bricks. This should be wired into your onboarding and offboarding checklist rather than remembered on the day.

Activation Lock: the part businesses get burnt by

Activation Lock ties a device to an Apple Account so it cannot be reactivated without those credentials. Apple now distinguishes two kinds, and the distinction is the whole story.

Organisation-linked Activation Lock requires Apple Business and lets your device management service turn it on and off through server-side interactions. That is the version you want.

User-linked Activation Lock happens when a user signs in with their own personal Apple Account and turns on Find My. Apple’s own device-state table is blunt about the consequences: when user-based Activation Lock is on, it can be turned off in Apple Business, but not through an external device management service.

Three specific traps, all from Apple’s documentation:

The ordering trap. Apple states that “if Activation Lock was already turned on, you won’t be able to turn it off in Apple Business unless the user first turns it off”. If the employee enabled Find My before the device was added to Apple Business, your escape hatch is gone. Add devices to Apple Business first, always.

The bypass code window. On iPhone and iPad the device-generated bypass code is only available for up to 15 days after the device is first supervised. Apple is explicit: “If a device management service doesn’t retrieve the bypass code within 15 days, that bypass code is unretrievable.” Confirm your MDM is actually retrieving and storing these. Confirm it again if you ever change MDM, because Apple warns that on migration you must either receive a copy of the codes or have the outgoing service clear Activation Lock for all enrolled devices.

The macOS 11 trap. For a Mac running macOS 11 or later enrolled via Device Enrolment, Apple notes it “may be possible for Activation Lock to already be turned on when the Mac enrols”, and in that case “you can’t turn it off using a device management service”.

Releasing the device makes it worse, not better. Apple says twice on the same page that “managing Activation Lock using Apple Business isn’t possible after a device is released”, and the interface makes you tick a box confirming you understand the release cannot be undone. Never release a device to try to fix a lock. Also never release a device you are sending to Apple for repair, because if Apple replaces it, the replacement will not appear in your account.

When all else fails, Apple runs an Activation Lock support request process for owners who have proof of purchase documentation. Keep your invoices. This is the entire reason to keep them.

Erasing does not clear the lock. Apple’s guidance is unambiguous: keep Find My on and Activation Lock survives a remote wipe. Clear the lock first, then erase.

Trade-in and residual value

Apple runs Apple Trade In in Australia for both consumer and business customers. Worth knowing how it is structured: Apple’s own terms state that “Apple Trade In is a service provided by Apple’s third-party trade-in vendor”, and the Australian business trade-in runs on a partner platform linked from Apple’s Shop for Business page. It is a real programme; it is not Apple handling your hardware in-house.

Two clauses from Apple’s Australian trade-in terms deserve to be in your process document. First: “You are responsible for backing up and/or deleting data on your trade-in device. Neither Vendor nor Apple will be liable for your data.” Second, the vendor may revise the quoted value if Find My is not removed. Your Activation Lock hygiene has a direct dollar consequence, which is the argument to use when someone asks why offboarding needs to be done properly.

On the buy side, Apple Certified Refurbished in Australia includes a one-year warranty and full functional testing, and AppleCare+ can be added. For non-critical roles it is a legitimate way to lower fleet cost without leaving the managed hardware pool. We do not quote figures here because Apple’s pricing moves and any number in a blog post is out of date within a quarter.

We deliberately publish no dollar amounts for trade-in residual values. Anyone who does is guessing.

Secure erasure: what Apple actually does

On a Mac with Apple silicon or the Apple T2 Security Chip running macOS 12 or later, Erase All Content and Settings performs a cryptographic erase. Apple’s platform security documentation describes the mechanism precisely: volume encryption keys are wrapped with a media key that is “designed to enable swift and secure deletion of data because without it decryption is impossible”, and on these Macs “the media key is guaranteed to be erased by the Secure Enclave supported technology”. Erasing it “renders the volume cryptographically inaccessible”.

Two practical consequences. Disk Utility no longer offers multi-pass secure erase for SSDs at all, and Apple’s advice there is to turn on FileVault instead. And a remote erase on an Apple silicon Mac needs a bootstrap token escrowed to your management service. Without it, Apple’s documentation warns the Mac can fall back to a behaviour called obliteration, after which macOS must be reinstalled before the machine is usable.

Note for anyone quoting ASD: the Information Security Manual’s media guidelines require non-volatile flash memory to be overwritten at least twice with a random pattern and read back for verification, and note that wear levelling means “it is possible that not all memory blocks will be overwritten during sanitisation processes”. The ISM does not address cryptographic erase on self-encrypting devices. Do not claim it endorses the Apple method. Cite Apple for the Apple mechanism and the ISM for the general principle.

Disposal obligations in Australia

Privacy. Australian Privacy Principle 11.2 requires an APP entity that no longer needs personal information, where the information is not a Commonwealth record and is not required to be retained by law, to “take such steps as are reasonable in the circumstances to destroy the information or to ensure that the information is de-identified”. OAIC’s guidelines note that for electronic information it may be possible to sanitise the hardware, and where hardware cannot be sanitised, reasonable steps must be taken to destroy the information another way.

Losing a device that holds personal information can be a data breach. OAIC lists “a device with a customer’s personal information is lost or stolen” as an example. Whether it becomes an eligible data breach turns on likely serious harm and whether remedial action prevented it, which is exactly where a properly escrowed FileVault key and a verified cryptographic erase become the argument you make to the regulator rather than a line item in your incident report.

A certificate of destruction is not a legal requirement in Australia. It is good practice and it is often a contractual requirement. What OAIC actually expects is that you verify and document destruction, including where you have instructed a third party to destroy information. A certificate is the ordinary commercial way to discharge that. OAIC also warns that relying on certification “may not of itself be considered ‘reasonable steps'”. Do not treat the certificate as immunity.

E-waste in Victoria. E-waste has been banned from Victorian landfill since 1 July 2019 and it is illegal to dump it. Business is treated more strictly than households: EPA Victoria states that most e-waste from business and industry is pre-classified as priority waste under Schedule 5 of the Environment Protection Regulations 2021, and that duties under the Environment Protection Act 2017 “apply to the generator, transporter and receiver of e-waste”. You do not discharge your obligation by handing devices to somebody with a ute.

Note that Sustainability Victoria closed on 30 June 2026. If your disposal procedure names it, update the procedure. EPA Victoria is the regulator.

The national scheme. The National Television and Computer Recycling Scheme gives households and small businesses free access to industry-funded collection and recycling for televisions and computers, including printers, computer parts and peripherals. It now sits under the Recycling and Waste Reduction Act 2020, which replaced the Product Stewardship Act 2011 in December 2020. Two limits worth knowing: mobile phones are not covered by the NTCRS, and the scheme is not designed to absorb a corporate fleet refresh. For volume, use a commercial IT asset disposal provider. The detail sits in secure device disposal and e-waste obligations.

Tax. Disposing of a depreciating asset is a balancing adjustment event, and the ATO requires you to compare termination value against adjustable value, with the difference either assessable income or an allowable deduction in the year the event occurs. Note also that if you stop using an asset and never expect to use it again while still holding it, the termination value is the market value at the time you make that decision. Machines shoved in a cupboard are not automatically worthless. Check current thresholds and rules with your accountant or on ato.gov.au rather than trusting a figure in a blog post.

The one-page checklist

At purchase: Organisation ID lodged with the reseller. Order submitted through the reseller portal. Serial numbers confirmed in Apple Business before delivery. Invoice filed and retrievable.

At deployment: Assigned to your management service before unboxing. Supervised. Managed Apple Account issued. FileVault key escrowed and test-retrieved. Bootstrap token escrowed. Activation Lock managed by the organisation, not the user. Asset record created.

At offboarding: Directory account disabled. Data confirmed in the tenancy. Activation Lock cleared. Remote erase issued and verified. Device shown unassigned in Apple Business with Activation Lock cleared. Reassigned, traded or disposed.

At end of life: Cryptographic erase performed and evidenced. Asset tags and markings removed. Licensed disposal or trade-in provider engaged. Destruction verified and documented. Asset register updated. Balancing adjustment recorded.

If most of that list is news to your current provider, that is worth knowing before your next hardware refresh rather than after it, and it is the practical test in whether your provider can actually support Macs.

Bring us your serial number list and we will tell you which devices are in Apple Business, which are Activation Locked to a person who no longer works for you, and what it will take to fix. Call 1300 028 324 or use https://techassist.au/contact/. It is a quicker conversation than most people expect.

Apple Business, until recently called Apple Business Manager, is Apple’s free web portal for buying, assigning and automatically enrolling company-owned Apple devices, and for issuing staff with work-owned Managed Apple Accounts. If you have Macs or iPhones in the business and you are not using it, you do not own those devices in any administrative sense. You just paid for them.

The name changed on 14 April 2026, and the change is not cosmetic. Apple folded Apple Business Manager, Apple Business Essentials and Apple Business Connect into a single free platform called Apple Business. Existing accounts migrated automatically. If a supplier or a provider is still quoting you on Apple Business Essentials, they have not looked at Apple’s documentation since April.

What Apple Business actually is, and what it is not

It is a directory and an inventory, not a management tool by itself. Historically that was the entire point of confusion. Apple Business holds three things: a record of which devices your organisation owns, a record of which people work for you, and the licences for apps and books you have bought in volume. It then hands those records to a device management service that does the actual configuring.

What is new since April is that Apple now includes a built-in device management service at no cost, using what Apple calls Blueprints and Configurations. This capability was previously the paid, United States only Apple Business Essentials. It is now free and available in Australia. You can use Apple’s built-in service, link an external one such as Intune or Jamf, or run both.

It is free. Apple charges nothing to sign up, nothing per device, and nothing for the built-in device management. The paid components are subscriptions layered on top, and as covered below, most of those are not sold in Australia.

Which features Australia actually gets

Apple publishes a feature availability table by country, and Australia is grouped with India and New Zealand. This is the part most articles written for a United States audience will mislead you on.

Available in Australia:

• Built-in device management
• Zero-touch deployment
• Managed Apple Accounts
• Get Apps and Get Books, so volume purchasing of both
• Brand and Location Management, and Branded Mail
• Tap to Pay on iPhone

Not available in Australia:

• Mail, Calendar and Directory, Apple’s new business email service
• Buying AppleCare+ for Business through the portal
• Buying additional iCloud storage for Managed Apple Accounts
• Verify with Wallet on the Web

The practical read is good news. Everything that matters for managing a fleet works here. Everything Apple is selling as a subscription on top of it currently does not. Do not build a plan around Apple business email in Australia.

A Managed Apple Account is not a personal Apple Account

A personal Apple Account, which Apple used to call an Apple ID, belongs to the person. A Managed Apple Account belongs to your organisation. You create it, you can reset its password, you control which Apple services it can reach, and when the person leaves you take it back.

The distinction matters most at offboarding. If a designer bought fonts, plug-ins and a decade of App Store software against a personal Apple Account using their work email address, none of that is yours and none of it transfers. If the same purchases were made against volume licences in Apple Business, they are yours, and they can be reassigned.

There is a sting in moving from one to the other. Before Apple will let you federate a domain, you must verify it and then turn on Domain Capture. Apple’s documentation is blunt about what follows: anyone using a personal Apple Account on your domain is notified and given 30 days to transfer their account, the date is fixed and cannot be extended, and turning on Domain Capture cannot be undone. Download the list of unmanaged Apple Accounts on your domain first, tell those people what is about to happen, and give them a path to move personal purchases to a personal address. We have seen this go badly purely because nobody sent the email.

Federation works with Entra ID or Google, but only one at a time

Apple Business can link to Microsoft Entra ID over OpenID Connect, to Google Workspace, or to a generic identity provider using OIDC or SCIM. Staff then sign in to their Managed Apple Account with their existing work credentials, and you can sync users and groups across.

Apple states explicitly that you can link to Google Workspace, Microsoft Entra ID, or your own identity provider, but only one at a time. If you run both Microsoft 365 and Google Workspace, this forces a decision, and it is one of several reasons the identity layer has to be settled before the Apple layer. That argument is set out in full in the guide to running Windows, Mac and Google together.

Two constraints worth knowing before you start. Apple supports the Entra ID global service only, so national clouds are out. And the user principal name in Entra must match the email address, because alternate IDs and UPN aliases are not supported.

Automated Device Enrolment only works if the seller enrols the device

This is the single most commercially important thing in this article, and it turns on how you buy.

Automated Device Enrolment means a Mac or iPhone taken out of its box connects to Apple, discovers it belongs to your organisation, and enrols itself into your management service before the user reaches the desktop. No technician touches it. It can be shipped straight to a home address. Enrolment cannot be skipped or removed by the user.

For that to happen, the device has to be in your Apple Business account, and Apple gives you a limited set of ways to get it there. Buying direct from Apple requires linking your Apple Customer Number. Buying through an Apple Authorised Reseller or an authorised mobile network operator requires exchanging your Organisation ID with them and adding their Reseller Number to your account. Apple then adds a warning that most people miss: once those numbers are exchanged, you still have to arrange for the reseller to submit your orders through their portal, and Apple says it will not happen automatically.

So the failure mode is not exotic. It is a business that has a reseller relationship, has an Apple Business account, and still finds devices are not appearing, because nobody ever told the reseller to submit the orders against the Organisation ID.

The Australian purchasing reality

Australia has a healthy Apple Authorised Reseller channel, and this is where the buying decision bites. A Mac bought over the counter on a company card at a general electronics retailer is a consumer transaction. It is not submitted against your Organisation ID, so it will not appear in Apple Business, and it will not auto-enrol.

Set the account up before the hardware order, not after, and give your reseller the Organisation ID as part of onboarding them. The cost difference on the hardware is usually trivial. The cost difference on twenty devices that have to be manually rebuilt is not. This is one strand of a broader discipline covered in the full Apple device lifecycle and in ordinary IT asset management.

The retail purchase myth, corrected

The common claim is that a Mac bought at retail can never be enrolled. That is not what Apple’s documentation says, and getting this wrong costs businesses money in needless replacements.

You can add retail-bought devices using Apple Configurator, and Apple says so directly, describing it as a way to add devices even when they were not purchased from Apple, an Apple Authorised Reseller or an authorised mobile network operator. For Mac there are specific conditions:

• It is done with Apple Configurator for iPhone, not the Mac version of the app. You hold an iPhone next to the Mac and scan a pairing image.
• The Mac must have Apple silicon or an Apple T2 Security Chip, and macOS 12.0.1 or later.
• It must be sitting at the Select Your Country or Region pane in Setup Assistant. Go past it and you restart.
• A Mac that has already been set up must be erased first.

Then comes the catch that makes the reseller channel worth insisting on. Apple gives Configurator-added devices a 30-day provisional period, beginning once the device is assigned and enrolled, during which the user can release it from Apple Business, from supervision and from the management service. Devices added through a reseller or bought direct from Apple have no such escape hatch.

For a phone handed to a contractor, thirty days of risk may be acceptable. For a fleet, it is not. Buy properly and the window never exists.

Apps and books are not the same licence

Volume purchasing through Apps and Books is one of the clearest wins in the platform, but the two halves behave differently and people assume they do not.

Apps can be assigned to devices or to users, and Apple confirms you retain full ownership and can revoke and reassign them. Buy fifty licences of a design tool, and when someone leaves, you pull the licence back and give it to their replacement.

Books can only be distributed to users, not devices, and Apple states they cannot be revoked and reassigned. Budget for books as consumed, not as recoverable.

Your App Store locale is set by the address you signed up with, so sign up as an Australian entity and you get the Australian App Store.

What businesses most often get wrong

Treating it as optional because the fleet is small. Ten Macs is enough. The setup takes an afternoon and it is free.

Setting it up after buying the hardware. The account has to exist before the purchase order for auto-enrolment to work.

Confusing it with an MDM. Apple Business now includes a device management service, and for a simple fleet it may be all you need. For anything involving detailed policy, scripting or reporting you will still want a full platform, which is the subject of choosing between Jamf and Intune and the practicalities of managing the Mac fleet itself.

Letting staff enrol their own devices under personal accounts. That is a mobile device management policy question, and it needs answering before the devices arrive rather than after.

Losing the account. Apple Business is a single point of control. If the person who created it leaves without handing over, you have a problem that Apple support cannot always solve quickly. Document it, hold more than one administrator, and treat those credentials like the domain registrar.

Setting up Apple Business properly takes an afternoon, and it is free. The version we would want to walk you through covers domain capture sequencing, reseller onboarding and the identity decision, because those are the three that are painful to reverse. 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 deploy and manage Apple fleets through Apple’s business deployment programmes, usually alongside the Windows estate the same business is already running.

If you have Apple devices in the business and no Apple Business account, or one nobody can log in to, call 1300 028 324 or get in touch at https://techassist.au/contact/. We will audit what is already enrolled, what is not, and what it takes to bring the rest in without erasing anyone’s machine.

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.

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.