ASD ISM 2127Enforce Driver Digital Signature Verification Before Loading
Operating systems must check every driver's digital signature and refuse to load any driver that fails the check, with the enforcement locked on so it cannot be bypassed.
Plain language
Drivers are small pieces of software that run inside the core of the operating system (the kernel) so that hardware such as network cards, storage, graphics and printers can work. Because they run at that level, a driver can see and do almost anything on the machine. A digital signature on a driver proves who published it and that it has not been altered since it was signed. This control requires that the operating system's signature-checking feature is not just available but actively enforced, so that a driver whose signature is missing, invalid or untrusted is refused before it is ever loaded. It matters because loading a malicious or tampered driver is one of the most powerful footholds an attacker can get: kernel-level code can disable security tools, hide itself from the operating system, capture credentials and survive reboots. Enforcing signature verification closes that door by default, rather than relying on someone noticing a bad driver after it is already running. The key word is enforced. Most operating systems can verify driver signatures, but if the check can be turned off, set to warn-only, or bypassed at boot, the protection is not really there. The control expects the verification to be mandatory and in place before drivers load, on every system in scope.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
Operating system hardeningTopic
Hardening operating system configurations
Official control statement
Digital signature verification functionality for drivers is enforced before they are loaded.
Why it matters
If driver signature verification is not enforced, an attacker or a piece of malware with administrative access can load an unsigned or tampered driver into the kernel. From there it can disable antivirus and endpoint detection tools, hide files and processes, intercept keystrokes and credentials, and persist across reboots in a way that is very hard to detect or remove. Even without a deliberate attack, unsigned or modified drivers from untrusted sources can introduce instability and crashes. Systems that allow this will typically be found non-compliant with the ISM control and expose the organisation to rootkit-style compromise that undermines every other security control on the device.
Operational notes
Day to day, this control is mostly about keeping enforcement switched on and not creating exceptions for convenience. The main friction point is legitimate but poorly packaged software (older hardware, niche peripherals, some vendor tools) that ships with unsigned drivers or asks users to disable signature enforcement to install. Teams should treat those requests as a procurement and vendor problem to solve (obtain a properly signed driver or an alternative product), not as a reason to weaken enforcement on the fleet.
Operating system upgrades, re-imaging, firmware changes and boot configuration edits can silently alter enforcement settings, so it is worth confirming the setting is still enforced after major changes. Test-signing or debug modes that relax signature checks should be confined to isolated development machines and never left enabled on production or user devices. Where systems are managed centrally, the enforcement setting should be applied by policy so that a local administrator cannot quietly turn it off.
Implementation tips
- The endpoint or platform engineering team should identify every operating system in scope (workstation, server, virtual and physical) and confirm which built-in mechanism enforces driver signature verification on each, for example Windows kernel-mode code signing enforcement, Linux kernel module signature enforcement, and macOS system extension policies.
- The systems administrator should turn on the enforcement setting through central configuration management (such as Group Policy, MDM or configuration-as-code), rather than per-device manual settings, so the setting is applied consistently and reapplied if it drifts.
- The platform engineer should lock down boot-time bypasses by enabling Secure Boot in firmware and ensuring boot options that disable driver signature enforcement (such as test-signing or disable-enforcement modes) are blocked or password protected, so the check cannot be sidestepped with a reboot.
- The desktop and server build teams should bake enforced signature verification into the standard operating environment images and build pipelines, then verify it on a freshly built machine before the image is released for use.
- The procurement and IT support teams should establish a rule that any hardware or software requiring an unsigned driver is rejected or returned to the vendor for a signed version, and document any temporary exceptions with an owner and expiry date so they are removed rather than forgotten.
Audit / evidence tips
- AskAsk for the configuration policy or baseline that sets driver signature enforcement for each operating system in scope.Look atLook for a specific, named setting that requires signed drivers and refuses unsigned ones, applied by a central mechanism rather than left to individual devices.GoodGood practice is a documented, centrally applied policy that mandates enforcement on all workstations and servers, with no warn-only or audit-only mode in use.
- AskAsk to see the effective setting on a sample of live devices, chosen by you rather than the team.Look atCheck the actual running configuration on each device and compare it with the policy to confirm enforcement is present and active, not just intended.GoodEvery sampled device shows signature verification enforced and matches the documented policy, including recently built and recently upgraded machines.
- AskAsk how boot-time bypasses are prevented, including Secure Boot status and any test-signing or enforcement-disable options.Look atReview firmware settings, boot configuration and any protections that stop a local administrator from rebooting into a mode that skips signature checks.GoodSecure Boot is enabled, boot configuration is protected, and there is no evidence of test-signing or enforcement-disabled modes on production systems.
- AskAsk for the list of any exceptions or systems where enforcement is relaxed, and the reasons for them.Look atExamine whether exceptions are documented, justified, time-limited and owned, and whether they cover production or user devices.GoodExceptions are rare, confined to isolated development or test environments, have an owner and expiry date, and are reviewed for removal.
- AskAsk for evidence that enforcement is verified after changes such as operating system upgrades, re-imaging or firmware updates.Look atLook at build checklists, image validation records or compliance scans showing the setting was rechecked after change.GoodThere is a repeatable check in the build and change process, with results showing enforcement confirmed rather than assumed.
Cross-framework mappings
How ISM-2127 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.9 | ISM-2127 requires the operating system to enforce kernel-mode driver digital signature verification before any driver is loaded and to pr... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System hardening
See all Guidelines for system hardening controls, or browse the full ASD ISM library.