ACSC’s own worked example for application control doesn’t meet the standard it’s meant to demonstrate

ACSC publishes an official worked example for application control. It’s built on Windows Defender Application Control, configured through Intune, and by ACSC’s own framing, it does not meet the Essential Eight maturity model it’s supposed to demonstrate. Not “meets it poorly.” Genuinely doesn’t meet it. That’s worth twenty minutes of a Business Manager’s attention before anyone assumes the official example is the finished answer.

Why the free official example falls short, and why that’s not ACSC being careless

Application control means deciding in advance which applications, scripts and installers are allowed to run on a device, and blocking everything else by default. It’s one of the more effective controls against ransomware, and one of the more fiddly to configure correctly.

The specific reason ACSC’s own example doesn’t clear the bar: it trusts whatever Microsoft’s Intelligent Security Graph currently rates as reputable, rather than an explicit list of what the school itself has approved. That’s a popularity contest, not an allow list, and the maturity model requires an allow list the organisation defines and re-validates at least yearly. This isn’t ACSC being sloppy. It’s ACSC being upfront that the low-effort version doesn’t clear the bar, and pointing implementers elsewhere if they’re actually trying to meet the requirement. The governance risk is entirely on the school’s side: an ICT team that implements the official example and reports it as “Essential Eight application control, done” has reported something that doesn’t hold up against the standard it’s citing.

The genuinely free path, and the licence fact worth getting exactly right

The good news: the path that actually meets maturity level one, which is realistic for most schools, is more straightforward than ACSC’s own example makes it look. Microsoft’s current guidance says Maturity Level 1 is achievable with AppLocker alone. AppLocker has been part of Windows since Windows 7, deploys through Group Policy, and on an on-premises or hybrid Active Directory fleet, that’s a genuinely free path with no additional licensing and no Intune console required. The starting rule set is narrow and deliberately unglamorous: block execution from the Windows Temp folder and from the parts of a user’s own profile they can write to, mainly AppData\Local and AppData\Roaming, with an exception for the Microsoft Store apps folder so the Start menu keeps working. That single change closes off a lot of where malware and unwanted downloads land first.

Here is the licence fact worth stating precisely, because a related error has already circulated in this exact series and it’s worth correcting directly rather than quietly. The genuinely free, standard Microsoft 365 A1 licence does not include Intune, Intune for Education, or Entra ID P1. Those come with Microsoft 365 A3 or A5. There is a separate, confusingly named licence called Microsoft 365 A1 for devices, low-cost but not free, and device-based, which does include Intune for Education, distinct from the standard free A1 most schools actually run. If a school is planning past Maturity Level 1 into Windows Defender Application Control territory, which requires the full Intune console rather than just Intune for Education, that plan needs to be built against the school’s confirmed licence SKU, not a general impression of what A1 “should” include. This is a reasonable proxy for how easy Microsoft’s own licensing is to get wrong even carefully, and it’s exactly the kind of assumption worth testing before it ends up in a board paper or an MSP’s assurance that “you’ve got Intune, it’s included.”

The population fork: shared devices, not staff versus students

This control’s population question isn’t staff versus students directly, it’s shared devices versus 1:1 devices. Windows Defender Application Control applies one policy to a whole machine; it can’t distinguish a student account from a staff account logged into the same computer. Lab machines, library terminals, and any device used by more than one type of person need AppLocker’s ability to layer per-user or per-group rules on top, so the policy for students and the policy for staff can differ on the same box. On genuinely 1:1 devices this mostly isn’t a problem, since there’s only one person to write a policy for. BYOD sits outside this entirely, regardless of licence tier, since a school can’t push an allow list to a device it doesn’t manage.

Where this leaves you

The test worth asking your ICT lead: if the school currently reports application control as covered, is that based on ACSC’s own official example, or on a genuinely maturity-level-compliant allow list? Those are two different answers, and only one of them holds up against the framework being cited.

Best Practice - This is the way