D3-DLIC Driver Load Integrity Checking: What It Hardens and How to Verify It

A malicious or vulnerable kernel driver runs with the highest privilege on the host, so whatever checks a driver before it loads is one of the last lines of defence. D3-DLIC Driver Load Integrity Checking is the MITRE D3FEND countermeasure for this. D3FEND defines it as "Ensuring the integrity of drivers loaded during initialization of the operating system." It sits in the Harden tactic under Platform Hardening and authenticates the Hardware Driver artefact. This card covers the two mechanisms D3FEND describes (signature checking and early-loading security agents), the single ATT&CK relationship D3FEND infers, how the control is configured on Linux, macOS and Windows, how to verify it, and its well-known limits. It is written for endpoint engineers, platform owners and detection teams. Operating systems are listed alphabetically.

Key takeaways

• Signature checks prove origin, not safety. A correctly signed driver can still be vulnerable, which is why signature enforcement needs a blocklist or allowlist on top.
• Enforcement mode matters more than signing. Linux module signing in permissive mode loads unsigned modules and only taints the kernel; enforcement needs CONFIG_MODULE_SIG_FORCE or module.sig_enforce=1.
• Stolen signing keys are D3FEND's main caveat. The technique's own considerations list stolen private keys and compromised or lax certificate authorities.
• D3FEND infers only one ATT&CK link. T1652 Device Driver Discovery shares the Hardware Driver artefact; the stronger practical value against rootkits and vulnerable drivers is context, not a D3FEND mapping.
• Verify with events and status queries. Windows logs Code Integrity events, and Linux records a taint flag when an unsigned module loads in permissive mode.

D3-DLIC at a glance

How it works

D3FEND describes two ways to achieve the technique:

• Signed kernel components: drivers carry a signature over a hash of the component, often with a certificate chain, added before distribution. The operating system checks it before loading the driver and refuses or flags drivers that fail.
• Early-loading security agent: a kernel-level security agent arranges for its own driver to initialise first, so it can inspect or control the drivers that follow. D3FEND's notes on the CrowdStrike reference explain the reason: attackers can change initialisation order to load a malicious driver before the defender.

Both rely on a trust anchor. D3FEND's considerations are blunt about it: signing keys of reputable companies have been stolen and used to sign malicious executables, root certificate authorities have been compromised, an attacker can set up an organisation that obtains a certificate, and a lax authority can issue incorrect certificates.

ATT&CK techniques D3FEND relates to D3-DLIC

Relationship type: inferred. D3FEND lists no direct ATT&CK mapping. The inferred relationship comes from a shared digital artefact: D3-DLIC authenticates Hardware Driver, and the only ATT&CK technique in D3FEND's model that touches Hardware Driver is T1652. Checked November 2026.

See T1652 Device Driver Discovery. In practice, teams deploy driver load checks against behaviour such as T1014 Rootkit, T1543.003 Windows Service (drivers are installed as kernel services), T1068 Exploitation for Privilege Escalation through vulnerable drivers, and T1553.006 Code Signing Policy Modification, where an adversary tries to switch enforcement off. That list is our context, not a D3FEND mapping. See MITRE ATT&CK T1553 Subvert Trust Controls and the Bring Your Own Vulnerable Driver and EDR Killers Guide.

Where it is implemented

Linux

• Module signature verification: CONFIG_MODULE_SIG turns on checking. With CONFIG_MODULE_SIG_FORCE off (permissive), unsigned modules and modules signed with unknown keys still load and the kernel is tainted with flag E. With it on, or with module.sig_enforce=1 on the kernel command line, only validly signed modules load.
• Trusted keys: built-in keys sit in the .builtin_trusted_keys keyring, visible in /proc/keys. Extra keys can be added only if signed by a key already in that keyring.
• Signing key handling: the kernel documentation warns that anyone holding the private key can sign malicious modules, so it should be moved somewhere secure or destroyed rather than left in the source tree. Keys can also be referenced by a PKCS#11 URI.
• Boot chain: distributions combine module signing with Secure Boot; see the Linux Secure Boot and Shim Guide.

macOS

• Kext signature checks: Apple states that with System Integrity Protection (SIP) on, the signature of each kernel extension is verified before it is included in the kernel collection, and that with SIP off the kext signature is not enforced.
• Approval: user consent and administrator authorisation are required to load kernel extensions installed on macOS 10.13 or later. A device management service can specify a list of kernel extensions that load without user consent.
• Apple silicon: kexts must be explicitly enabled from recoveryOS, which sets secure boot to Reduced Security.
• Alternatives: Apple recommends solutions that do not extend the kernel, such as those built on DriverKit, EndpointSecurity and NetworkExtension.

Windows

• Kernel-mode code signing policy: from Windows 10 version 1607, new kernel drivers must be signed through the Windows Hardware Dev Center. Microsoft documents exceptions: systems upgraded from earlier releases, Secure Boot off, and drivers signed with an end-entity certificate issued before 29 July 2015 that chains to a supported cross-signed CA.
• Microsoft vulnerable driver blocklist: a list of drivers with known vulnerabilities or malware links. Microsoft documents it as on by default from the Windows 11 2022 update, and enforced with memory integrity, Smart App Control or S mode. It is updated quarterly and through monthly updates, and can be deployed as an App Control for Business policy.
• Memory integrity (HVCI): runs kernel-mode code integrity inside virtualisation-based security, so a compromised kernel cannot simply switch the check off. It is set under Windows Security, Device security, Core isolation details.
• Early Launch Antimalware (ELAM): ELAM drivers initialise before other boot-start drivers and classify each as known good, known bad or unknown. The DriverLoadPolicy value under HKLM\System\CurrentControlSet\Control\EarlyLaunch sets which classes initialise; Microsoft labels 0x3 as the default.

For allowlisting drivers by policy, see App Control for Business (WDAC).

Choosing a configuration

Implementation steps

1. Inventory drivers. List kernel modules and drivers per platform image, with signer, version and owner. Unknown signers are the first finding.
2. Turn on enforcement in audit first. On Windows, deploy the blocklist or a driver allowlist in audit mode and review audit block events. On Linux, run permissive mode on a pilot group and look for tainted kernels.
3. Fix or replace incompatible drivers. Microsoft notes that memory integrity can break incompatible drivers and that the remedy is an updated driver.
4. Enforce by ring. Move pilot, then broad, then critical systems to enforcement. Plan for reboots: Microsoft notes a policy change does not stop drivers already running.
5. Protect the signing keys. Organisation keys used for drivers or modules live in hardware-backed storage, with named approvers. See the Code Signing Security Guide.
6. Keep a rollback path. Document recovery: on Windows, Microsoft describes switching memory integrity off from Windows RE; on Linux, keep a known-good kernel entry. Test recovery before broad rollout.

How to verify it works

Metrics to track (examples, not standards): share of endpoints with enforcement on, number of distinct driver signers in the estate, unsigned or tainted loads per month, and time from a blocklist update to fleet-wide coverage.

Limits, bypasses and failure patterns

• Signed but vulnerable drivers: the signature is valid, so only a blocklist or allowlist stops the load. Microsoft also notes its attack surface reduction rule for vulnerable signed drivers stops the file being written, not an existing driver loading.
• Stolen or expired certificates still trusted: in the NVIDIA code-signing certificates theft, leaked expired certificates issued before the July 2015 cut-off remained usable for driver signing, and policy-based blocking was the suggested response.
• Permissive mode left on: Linux module signing without enforcement records a taint but loads the module.
• Exceptions nobody tracks: Secure Boot switched off for one device or test signing left enabled removes the protection silently.
• Signing keys on build servers: a module signing key left in the kernel tree or a CI workspace lets anyone with access sign drivers. The key is a machine credential; manage it like one with the Code Signing Policy Template.
• Blocklist merged into allowlist: Microsoft notes the blocklist policy contains Allow All rules that must be removed before merging with an explicit allowlist.

Framework mapping

See M1045 Code Signing.

Related countermeasures

• Boot chain: D3-BA Bootloader Authentication checks the loader before the operating system starts, and D3-TBI TPM Boot Integrity measures the chain.
• Executable allowlisting: D3-EAL Executable Allowlisting applies the same idea to user-mode code.

Practitioner checklist

• Inventory kernel drivers and modules with signer and owner for each platform image.
• Run Linux kernels with module signature enforcement, not permissive mode.
• Keep SIP on for Macs and approve only required kernel extensions through device management.
• Keep memory integrity and the vulnerable driver blocklist on for Windows endpoints and servers.
• Add an explicit driver allowlist for high-value systems.
• Store driver and module signing keys in hardware-backed storage with named approvers.
• Track Secure Boot off, test signing on and similar exceptions as risks with owners.
• Alert on tainted kernels, Code Integrity block events and enforcement being switched off.
• Test rollback and recovery before enforcing across the fleet.

Standards and references

• MITRE D3FEND: Driver Load Integrity Checking (D3-DLIC)
• Linux kernel documentation: Kernel module signing facility
• Apple Platform Security: Securely extending the kernel in macOS
• Microsoft Learn: Driver signing policy
• Microsoft Learn: Microsoft recommended driver block rules
• Microsoft Learn: Enable memory integrity
• Microsoft Learn: ELAM driver requirements
• NIST: SP 800-53 Rev 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Bring Your Own Vulnerable Driver and EDR Killers Guide · App Control for Business (WDAC) · Code Signing Security Guide · Linux Secure Boot and Shim Guide · MITRE D3FEND Guide