What Maturity Level Two actually asks of a mobile fleet
The Essential Eight maturity model was built around workstations. Translating each level to a mobile estate is possible, and nobody has written it down for you.
We have written before that the Essential Eight leaves your phones out. The obvious next question is what to do about it, and specifically what each maturity level would mean if the mitigation strategies were applied to a mobile fleet honestly.
The ACSC model does not answer that, because it was designed around a Windows workstation and says so. But an agency being asked to state its maturity has a mobile estate inside the same boundary, and “not applicable” is an answer that will not survive being read closely.
Here is the translation we use. It is our reading, not a standard — but it is defensible, and it is better than the silence most assessments contain.
Patch operating systems
This is the one that translates most cleanly, and it is where most fleets fail on the timeframe rather than on the capability.
Level one means devices update, eventually, and you know the version spread. Most fleets can claim this.
Level two means an enforced minimum version with a deadline, and reporting on the devices that resist. The mechanism exists on both platforms — this is what declarative software update enforcement is for on Apple, and what update policies do on Android — but it needs a decision about what happens to a device that misses the deadline.
Level three means the deadline is enforced by losing access rather than by a report. A device below the minimum version fails device compliance and Conditional Access blocks it. That is the difference between a policy and a control, and it needs the compliance signal actually wired into identity.
Patch applications
Mobile applications update through the store rather than through your patch process, which makes this easier in one way and harder in another.
The achievable version: managed applications deployed through the managed catalogue with automatic updates enabled, and reporting on installed versions across the fleet. The harder part is applications distributed outside the store — in-house builds are exactly as stale as your release process, and they are the ones with your data in them.
Application control
The closest mobile equivalent is a managed catalogue with an allow-list posture, plus a policy on sideloading.
Level one is a managed catalogue with an approved application list. Level two is blocking installation from outside it on corporate-owned devices, which requires the device to actually be corporate-owned in the platform’s sense — one of the reasons the ownership model decides more than people expect. Level three adds a documented assessment process for what enters the catalogue, and periodic review of what is already in it.
Restrict administrative privileges
On mobile this maps to two things: who holds administrative access to the management platform, and whether users can escalate on the device.
The platform side is frequently the weakest control in a fleet. Administrative access to an MDM console is access to every device in the organisation, and it is regularly held by more people than can be justified, without privileged access management, and sometimes by the outgoing provider. Role-based delegation, time-bound elevation and a reviewed access list are all achievable and rarely present.
The device side is largely handled by the platform — a supervised device does not offer administrative escalation — provided jailbreak and root detection is present and actually blocks access rather than logging.
Multi-factor authentication
Mobile is usually the token, which quietly obscures the fact that the device itself is protected by a passcode and a biometric.
Level two on a fleet means MFA is enforced for access to organisational data from the device, and the device is a factor rather than only a carrier of one. Level three implies phishing-resistant methods, which on mobile means passkeys — and which addresses the failure mode we have written about in why SMS phishing works.
Application hardening, macro settings, backups
User application hardening translates to browser and mail client configuration delivered by policy: content restrictions, blocking untrusted sources, and disabling the features that exist for consumer convenience.
Configure Microsoft Office macro settings is genuinely close to not applicable on mobile, and that is a defensible answer — provided it is stated rather than left blank.
Regular backups applies to organisational data reachable from the device rather than to the device itself. A managed handset should hold no unique data; if it does, that is the finding.
What to actually do with this
Write the mobile column. For each of the eight strategies, state what applies to the fleet, at what level, with what evidence — including the ones where the honest answer is “not applicable, because”.
That document is worth more than any individual control, for two reasons. It converts an unstated gap into a stated position, which is the difference between a finding and a decision. And it tells you where the real work is, which is almost never where people assume.