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.
