ASD ISM 1659 Implement Microsoft's vulnerable driver blocklist
What it says
Microsoft's vulnerable driver blocklist is implemented.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse Microsoft's list to stop harmful drivers from running on systems.
Microsoft's vulnerable driver blocklist is a tool that helps stop problematic software drivers from running on your computer systems. If these drivers aren't blocked, they can let viruses or hackers into your system, potentially causing personal data theft, financial loss, or business disruption.
Free. Save your status, tasks and notes.
Why it matters
Unblocked vulnerable Windows drivers can be abused to gain kernel access, bypass EDR, and cause data breaches or outages.
How to implement
The IT team should regularly update their systems with the latest blocklist from Microsoft.
This can be done by enabling Windows Update, which automatically downloads and installs the latest list as part of security updates.
A manager or system owner should ensure that any third-party tools used in the organisation adhere to Microsoft's security practices, including how they handle drivers.
They can do this by confirming with vendors that the tools are compliant with Microsoft's blocklist policy.
System owners should hold a quarterly review session with the IT team to confirm that Microsoft's blocklist is applied on all company computers.
This involves checking system settings and updates logs for evidence of the blocklist being active.
IT managers should train staff on identifying and avoiding the installation of questionable drivers.
This can be done by organising workshops or providing training material explaining the risks associated with harmful drivers.
The HR department should work with IT to incorporate blocklist policy into the onboarding process.
This ensures new employees understand the importance of not bypassing security measures related to driver installations.
Keep it running
Keep Microsoft's vulnerable driver blocklist enabled, update it via Windows updates, and validate blocked driver events in logs/EDR.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A report from the IT team that lists systems where the blocklist is implemented.
Look at
The update logs to confirm the blocklist is applied.
Good evidence
Logs indicating regular updates with timestamps matching recent blocklist updates.
- Check 2 of 5What an auditor asks for
Look at
Vendor confirmations or agreements that mention the blocklist.
Good evidence
Signed vendor documents or emails stating compliance with blocklist policies.
- Check 3 of 5What an auditor asks for
Ask for
To see the meeting records where driver security was discussed.
Look at
The minutes or notes for discussion of the blocklist implementation.
Good evidence
Dated notes with attendees and action items focusing on blocklist checks.
- Check 4 of 5What an auditor asks for
Look at
The content for mention of driver security and blocklist practices.
Good evidence
Detailed materials covering risks of bad drivers and steps to report suspicious activities.
- Check 5 of 5What an auditor asks for
Ask for
To see the onboarding checklist from HR.
Look at
Sections that cover security measures related to drivers.
Good evidence
A checklist that includes steps to inform new hires about the blocklist and driver security protocols.
Mappings
Closest match in ASD Essential Eight: E8-AC-ML3.3, Microsoft's vulnerable driver blocklist is implemented, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.7.
ISM-1659 requires organisations to implement Microsoft's Vulnerable Driver Blocklist to reduce the chance malware or attackers can use vulnerable kernel drivers for privilege escalation or defence evasion. Annex A 8.7 requires implementing protection against malware, which can include hardening controls that prevent malicious components (including drivers) from running. Annex A 8.7 is broader and includes awareness and multiple malware controls, whereas ISM-1659 targets one specific driver-execution risk.
This control partially meets A.8.8.
ISM-1659 requires organisations to implement Microsoft's Vulnerable Driver Blocklist as a specific technical measure to reduce exposure to vulnerable drivers. Annex A 8.8 requires obtaining information about technical vulnerabilities, assessing exposure, and applying appropriate measures, which includes implementing preventative controls like driver blocking. Annex A 8.8 is broader (process and governance for vulnerabilities), while ISM-1659 is a concrete Windows hardening action.
ASD Essential Eight: 2 mappings
This control is equivalent to E8-AC-ML3.3.
E8-AC-ML3.3 requires organisations to implement Microsoft's vulnerable driver blocklist to prevent known vulnerable drivers from loading on Windows systems. ISM-1659 states the same requirement to implement Microsoft's vulnerable driver blocklist. Both controls have the same technical intent and implementation focus (blocking vulnerable kernel drivers) with no material difference in scope.
This control partially overlaps E8-AC-ML2.3.
E8-AC-ML2.3 requires implementing Microsoft's recommended application blocklist to prevent execution of risky user-mode applications. ISM-1659 requires implementing Microsoft's vulnerable driver blocklist, which similarly uses Microsoft-curated deny rules but targets kernel drivers to reduce privilege escalation and kernel compromise. They overlap in using Microsoft-maintained blocklists as preventative controls, but they cover different artefact types (applications versus drivers) and mitigate different attack paths.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.