Should endpoint teams treat BYOVD as an access-control problem or a malware problem?

Why BYOVD Sits on the Boundary Between Access Control and Malware

Bring your own vulnerable driver is not just “malware with a driver payload,” because the technique depends on a trusted execution path that Windows will accept long enough for the attacker to reach kernel-level leverage. That makes the permissions and trust boundary around driver loading part of the problem, not just the malicious binary itself.

It is also not only an access-control issue, because once a vulnerable driver is loaded, the attacker is effectively using legitimate kernel capabilities to disable security controls, tamper with memory, or escalate impact. The right mental model is therefore abuse of authorised kernel paths, followed by malicious behaviour.

In practical terms, endpoint teams should ask two separate questions at once: who is allowed to load or install drivers, and what damage can a loaded driver do if it is vulnerable or weaponised? Treating only one side leaves a gap.

What Changes When You Start With Access Control

The access-control lens is the first line of defence because BYOVD usually needs some combination of local privilege, installation rights, code-signing trust, or the ability to reach a driver-loading mechanism. If those privileges are tightly scoped, the attacker must do more work before the vulnerable driver can be introduced.

This is where least privilege matters more than many teams expect. The point is not merely to block “obvious admin actions,” but to reduce the number of endpoints and workflows that can legitimately introduce kernel-mode code. If only a small set of controlled workflows can install or load drivers, BYOVD has fewer places to start.

Access control also changes the blast radius. When driver installation is reserved for managed software deployment paths and highly controlled admin roles, security teams can monitor a much narrower set of events, and suspicious driver activity is easier to spot than when endpoint users or broad support roles can trigger it.

Why the Malware Lens Still Matters After the Driver Loads

Once a vulnerable driver is present, the issue becomes behavioural. A malicious actor can use a signed but flawed driver to disable protections, hide activity, read or write kernel memory, or interfere with EDR and other endpoint tooling. At that point, the driver is functioning as an attack enabler, not just a configuration mistake.

This is why malware detection, reputation, and blocklisting still matter. A driver that is technically signed is not automatically safe, and a vulnerable driver that has been abused in the wild should be treated as an operationally dangerous artifact even before a specific endpoint compromise is confirmed.

The useful distinction is that the malware lens focuses on what the attacker does after introduction, while the access-control lens focuses on how the attacker got the driver into a position of trust. Good endpoint policy has to address both stages.

How Endpoint Teams Should Frame the Decision

Endpoint teams should frame BYOVD as an access-control problem first, because stopping unauthorised driver introduction prevents the attack path from forming. But they should manage it as a malware problem as well, because the loaded driver can behave like a post-exploitation tool and create kernel-level persistence or defence evasion.

CIS Controls v8 fits this dual view because it combines account and access governance with malware defence and secure configuration. That combination matches BYOVD better than a single-point response.

Authorisation Models Guide is useful when you need to decide which roles and policies should be allowed to reach driver-loading workflows, especially where support, admin, and deployment privileges overlap.

IAM and IGA Basics helps teams connect driver-loading rights to provisioning, access review, and entitlement cleanup, which is where many BYOVD-prevention failures begin.

Risk and Threat Considerations

BYOVD is attractive because it turns trust into an attack surface. If a vulnerable driver can be loaded through legitimate privilege or an overly broad admin path, the attacker may gain kernel-level capabilities that are much harder to inspect, constrain, or remediate than ordinary user-mode malware.

Failure mechanism: Excessive installation rights, weak driver allowlisting, or trusted deployment paths that are too broad let a vulnerable but signed driver reach the kernel, where it can be abused to disable protections or support post-exploitation activity.

Impact: The result can be security-tool tampering, stealthier persistence, privilege escalation, and a much larger incident response burden because the compromise has moved below the usual user-mode control plane.

Practitioner Guidance

What to prioritise: Start with the paths that can introduce kernel-mode code, not just the files you want to block. If the organisation cannot clearly name which roles, deployment tools, or support processes are allowed to load drivers, the policy is not ready.

What to verify: Confirm that driver installation is limited to tightly controlled admin workflows, that vulnerable-driver blocklists are enforced where possible, and that exceptions are explicit, time-bounded, and reviewable. If an endpoint can accept a new driver without a strong change record, treat that as a control failure.

Decision rule: If the control question is “can this driver be introduced at all?”, treat it as access control. If the question is “what can a loaded driver do inside the kernel?”, treat it as malware containment and response. The best programmes handle the first to prevent the second.

Practitioner takeaway: BYOVD is not an either-or problem, but the most effective control point is upstream: restrict who can create trusted kernel access, then assume any permitted driver still needs malware-style scrutiny.

Related resources from NHI Mgmt Group

• Should teams treat browser sessions and service-to-service access as the same control problem?
• What do identity teams get wrong when they treat SOC and SOX as the same control problem?
• How should security teams use client certificates for endpoint access control?
• Should security teams treat Zero Trust and JIT access as the same control?