Essential Eight AC-ML3.2 Application control restricts driver execution to an approved set
What it says
Application control restricts the execution of drivers to an organisation-approved set.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure only approved drivers can run to prevent malicious code execution.
Think of drivers as the software that helps your computer talk to various hardware like printers and monitors. If these drivers are not approved or checked, they might contain harmful code that could let someone take control of your computer. This control limits which drivers can run to prevent any sneaky actions and keep your systems safe.
Free. Save your status, tasks and notes.
Why it matters
Unapproved drivers can execute kernel-level code, enabling attackers to bypass security controls, persist, or destabilise systems.
How to implement
IT team should identify all necessary drivers used by the organisation and list them for approval.
This ensures only safe, needed drivers are considered for use.
System administrators should update system policies to prevent unapproved drivers from running.
This can be done using the operating system's built-in tools like AppLocker.
Security officers should conduct regular reviews of the approved driver list to ensure it stays current and only contains safe drivers.
These reviews should involve checking for any vendors that might have been compromised.
IT team should remove any drivers that are no longer needed from computers.
This can be done during regular maintenance checks or when updating hardware.
System administrators should configure systems to use Microsoft's vulnerable driver blocklist.
This can be implemented through the system's security settings to block known risky drivers automatically.
Keep it running
Maintain a driver allow-list, block unsigned/unapproved drivers, and review new or updated vendor drivers before adding them.
Evidence and audit
- Check 1 of 2What an auditor asks for
Ask for
Can you show me the list of approved drivers for your organisation?
Look at
Examine the documented list of approved drivers maintained by the IT team.
Good evidence
The list is detailed, up-to-date, and includes recent reviews.
- Check 2 of 2What an auditor asks for
Ask for
How are unauthorised drivers prevented from running on company systems?
Look at
Check the system policies or configurations like AppLocker settings.
Good evidence
Policies are in place that effectively block non-approved drivers and are regularly reviewed.
Mappings
Closest match in ASD Information Security Manual: ISM-1658, Restrict execution of drivers via application control, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.19.
E8-AC-ML3.2 requires application control to restrict driver execution to an organisation-approved set. ISO/IEC 27001:2022 Annex A 8.19 requires secure software installation procedures across operational systems, which includes controlling what software (including drivers) is introduced and how it is authorised. E8-AC-ML3.2 is a specific technical enforcement mechanism for one high-risk software class (drivers), whereas A 8.19 is broader process and control coverage for software installation generally.
This control partially overlaps A.8.18.
Annex A 8.18 requires restricting and tightly controlling utilities that can override system and application controls, which includes limiting low-level components that can change system behaviour. E8-AC-ML3.2 relates by restricting driver execution to an organisation-approved set, preventing unauthorised drivers that can bypass or undermine security controls. However, Annex A 8.18 covers a wider class of utilities and administrative tools beyond drivers, while E8-AC-ML3.2 is narrowly focused on driver execution allowlisting.
ASD Information Security Manual: 6 mappings
This control is equivalent to ISM-1658.
ISM-1658 requires application control to restrict the execution of drivers to an organisation-approved set. E8-AC-ML3.2 states the same requirement using the same mechanism (application control) and the same scope (drivers only). Implementing either control would largely satisfy the other for driver execution restrictions.
This control is broader than ISM-1656.
E8-AC-ML3.2 requires application control to restrict the execution of drivers to an organisation‑approved set to prevent unauthorised code running in kernel context. ISM-1656 requires application control to be implemented on non‑internet‑facing servers, which would typically include controlling executable content such as drivers as part of that deployment. ISM-1656 is broader in scope (where to deploy application control), while E8-AC-ML3.2 is a specific application control outcome focused on driver execution restrictions.
This control partially meets ISM-1657.
ISM-1657 requires restricting execution to an organisation-approved set for a wide range of application artefacts (executables, libraries, scripts, installers, HTML/CHM/HTA, and control panel applets). E8-AC-ML3.2 focuses specifically on restricting driver execution to an approved set, which is one component of overall execution control. ISM-1657 does not explicitly call out drivers, but its broader execution control objective encompasses this subset in practice for many platforms.
This control partially overlaps ISM-0955.
ISM-0955 requires application control to be implemented using cryptographic hash, publisher certificate, or path rules. E8-AC-ML3.2 applies application control concepts specifically to drivers by restricting driver execution to an approved set, which can be implemented using the rule types described in ISM-0955. E8-AC-ML3.2 is narrower to drivers and approval scope, while ISM-0955 is broader across applications and focused on the technical rule constructs.
This control supports ISM-1392.
E8-AC-ML3.2 requires application control to restrict driver execution to an approved set, which is only effective if the allow-list cannot be modified by unauthorised users. ISM-1392 requires that when path rules are used for application control, only approved users can modify approved files and write to approved folders, reducing the risk of swapping or tampering with allow-listed items. This is a prerequisite hardening condition that helps ensure E8-AC-ML3.2 cannot be bypassed via file/folder modification on allow-listed paths.
This control supports ISM-1746.
E8-AC-ML3.2 requires restricting driver execution through application control to an organisation-approved set. ISM-1746 requires that when path rules are used, only approved users can change file system permissions for approved files and folders, preventing attackers from weakening ACLs and replacing trusted binaries/drivers. This underpins the integrity of the approved set and reduces bypass opportunities, making it a prerequisite support condition for effective application control enforcement.
ASD Essentials for enterprise IT: 1 mapping
- IT.PRO-07.1Restrict execution to supported, verified and authorised software with time-bound exceptionsPartially overlaps
This control partially overlaps IT.PRO-07.1.
IT.PRO-07.1 requires that only supported, verified and organisation-authorised software can execute; E8-AC-ML3.2 restricts the execution of drivers to an organisation-approved set, applying the authorisation part to drivers.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.