On June 23, 2026 a patent issued that is directed at one of the more durable problems in endpoint defense: what happens when the attacker is operating from inside the kernel, below the security agent that is supposed to stop them. Titled "Preventing EDR termination using vulnerable drivers," the patent is assigned to Palo Alto Networks, Inc. and carried at US12664255B2. Before the substance, the label that matters: this is a granted patent, not a pending application. The claims below are the ones an examiner allowed and that the assignee can now assert, not a wish list filed for consideration. With that fixed, the question is what the granted independent claim actually covers.

The technique it addresses has a name in the field: bring-your-own-vulnerable-driver, or BYOVD. The pattern is well established. An attacker who has gained execution on a machine wants to disable the endpoint-detection-and-response (EDR) agent watching it. Rather than fight the agent in user space, the attacker loads a legitimately signed but exploitable kernel driver, then uses that driver's kernel-level privileges to reach the operating-system primitive that terminates processes — and points it at the EDR's own protected processes. Because the kill comes through a trusted driver running in the kernel, conventional user-space protections do not see it coming. The granted claim is directed at intercepting exactly that path.

As claimed, the method deploys, in memory used by the operating-system kernel, a hooked version of a syscall configured to modify the execution status of processes — the syscall an attacker would call to terminate one. The hooked version carries injected program instructions that generate a notification whenever that syscall is called to terminate a process. One or more protected processes belonging to a security-software application are specified in advance. When the hook fires for a call requesting termination of one of those protected processes, the claimed method does three things: it inhibits execution of the hooked syscall — the kill is stopped — and then it traces the lineage of the attempt. It identifies the driver that conveyed the call, identifies a first process that loaded that driver into memory, and identifies a second process that instructed the driver to make the call. Finally, it inhibits execution of all three: the driver, the loader, and the instructor.

deploying, in a memory of the computer and used by an operating system kernel of the computer, a hooked version of a syscall that is configured to modify an execution status of processes executing on the computer; specifying one or more protected processes belonging to a security software application executing on the computer; receiving, from the hooked version of the syscall, a notification of a call to the syscall requesting to change the execution status of a given process executing on the computer by terminating execution of the given process ... and in response to receiving the notification and upon ascertaining that the given process is one of the protected processes, i) inhibiting execution of the hooked version of the syscall, ii) identifying a given driver that conveyed the call to the syscall, identifying a first process that loaded the given driver to the memory, and identifying a second process that instructed the given driver to call the syscall to terminate the execution of the given process, and iii) inhibiting execution of the identified given driver, the identified first process, and the identified second process.— Preventing EDR termination using vulnerable drivers, US12664255B2

What the independent claim reaches

The structure of claim 1 is worth reading closely, because the scope is not just "block the kill." The claimed response has a defensive half and an attributive half. The defensive half is the inhibition of the hooked syscall — the protected process survives. The attributive half is the three-way identification: the conveying driver, the process that loaded it, and the process that instructed it. That tripartite trace is what distinguishes the claim from a generic process-protection mechanism. It is directed not only at surviving the termination attempt but at pinning the components that carried it out, and then inhibiting each. The dependent claims narrow and vary the mechanism: claim 2 specifies that deploying the hook means injecting instructions into the syscall; claims 3 through 7 enumerate the forms of "modifying execution status" the syscall covers — terminating a process, terminating a thread, suspending a process or thread, or closing a process handle; and claim 11 adds a heuristic for picking the culprit driver, identifying the one with the most recent load date among multiple drivers in memory. Claim 14 situates the whole method in an endpoint agent executing on the computer, and claims 17 and 18 restate the invention as a computer and as a non-transitory computer-readable medium — the standard apparatus and software-product forms.

Where it sits in the patent landscape

The classification places this where the disclosure lives. The patent's main CPC is G06F 21/56 — the subclass for detecting, monitoring, and counteracting malicious program activity, the malware family within the broader G06F 21/ security arrangements. That is the right neighborhood: the claimed contribution is not a cryptographic mechanism or an access-control policy but a runtime malware-countering technique operating at the kernel boundary. Within that landscape, BYOVD defenses are an active area precisely because driver-signing trust is the seam attackers exploit, and a kernel-resident hook on the termination syscall is a structurally different approach from blocklisting known-vulnerable drivers after the fact. The claim is directed at the moment of the call rather than at the driver's reputation.

Read against Palo Alto Networks' broader granted record, the endpoint-protection patent is one face of a wider security portfolio that also reaches the network layer. Two patents granted in the same window illustrate the spread. US12665875B2, "Networking and security split architecture," claims receiving a flow at a security service, processing it at a network layer to perform networking functions, and offloading it to a security layer that performs security enforcement based on a policy — a separation of the networking and enforcement planes inside a single security service. US12665881B2, "Load balancing secure network traffic," claims monitoring per-branch enterprise traffic and load-balancing those branches across security processing nodes running in a cloud-based security service, distributing branches to nodes through a set of tunnels via a network load balancer in communication with network processing nodes. Those two are directed at the cloud-delivered, distributed-enforcement side of the business; the hero patent is directed at the host itself. Together they trace a portfolio that spans from the kernel of a single protected endpoint out to the load-balanced fabric carrying enterprise traffic to cloud security nodes.

What the granted patent claims, then, is specific and now enforceable: a kernel-memory syscall hook that, on a request to terminate a designated security-software process, inhibits the termination and inhibits the vulnerable driver and the two processes behind the attempt, classified under the malware-countering subclass G06F 21/56. The dependent claims extend the same mechanism across thread termination, suspension, and handle closure, and add a load-date heuristic for identifying the offending driver. As a granted record, its coverage is fixed in the issued claim language rather than open to prosecution — which is what makes the independent claim, with its three-way trace from the blocked call back to driver, loader, and instructor, the part of the document worth reading first.