Kernel-Level Enforcement Guide

Updated 28 October 2026.

Mimic Networks publishes this guide. Every outside source in it is dated and listed at the end. The questions in Section 02 work for any vendor that puts code in your kernel, Mimic Networks included.

Section 01 · The Mechanism

The short answer

Mimic Networks checks each attempted change to a protected server at the kernel, against a verified record of that server's authorized state. A change in the record proceeds. A change outside it stops at the point of execution. The check asks whether a change was authorized, not whether it looks like an attack, so it needs no signature for the threat.

This guide covers the mechanism: why the check runs at the kernel, how it works on Windows and Linux, what the sandbox around the logic isolates and how Mimic protects its own processes. Section 02 covers running it in production, where it stops and what to ask any vendor that puts code in your kernel. The model behind the check has its own guide: the Known-Good Enforcement Guide, by Mimic Networks.

Why the kernel question matters now

Ransomware complaints keep rising. The FBI's Internet Crime Complaint Center received 3,611 in 2025, up from 2,825 in 2023, and identified 63 new ransomware variants. Each new variant is another pattern a recognition-based control has to learn. A check against the server's own authorized state doesn't have to learn it.

• 3,611: Ransomware complaints the FBI's IC3 received in 2025, up from 2,825 in 2023.
• 63: New ransomware variants the IC3 identified in 2025.
• 141 of 491: Vulnerabilities newly named as exploited in the first half of 2026 that attackers were already exploiting when they went public, per the Zero Day Clock.

Sources: FBI IC3, 2025 IC3 Annual Report; Zero Day Clock (Sysdig), first-half 2026 counts, read 28 October 2026. The Zero Day Clock dates each flaw by when a catalogue listed it, not by when exploitation began.

The kernel itself is the other half of the question. CrowdStrike traced the July 2024 outage to a content update that caused an out-of-bounds memory read in its driver, and Microsoft estimated 8.5 million Windows devices were affected.

So the question for a CISO isn't whether to allow code in the kernel. Many endpoint security products already load drivers there. It's what that code decides, what holds when someone goes after it and how it's built and updated. This section answers those questions for Mimic Networks. Section 02 turns them into questions for any vendor.

Why the check runs at the kernel

Because that's where the change happens. On Windows, file operations pass through the file system stack, where a minifilter can see each one before it completes and, in Microsoft's words, "even prevent" it. On Linux, eBPF programs run inside the kernel itself. A control at that point can decide on a change before it executes, rather than report it afterward.

The check covers changes to a protected server's files, processes, services and settings, plus registry keys on Windows. It's deterministic: a change is in the server's baseline or it isn't, so a new ransomware strain gets the same test as a familiar one. Detection estimates whether activity looks malicious, and an estimate can miss in either direction. Bob Blakley, Mimic's Co-Founder and Chief Product Officer, frames the design philosophy this way:

"There is, in principle, infinitely much bad behavior, so you never get done working through the list. What Mimic does instead is it tries to understand the finite amount of good behavior of the application that we protect, and then ensure that the application never departs from that pattern." Bob Blakley, Co-Founder and Chief Product Officer, Mimic Networks

Blakley states the consequence directly: "If you try to succeed by understanding all the bad behavior in the world, instead of by understanding the known-good behavior in the world, you're just going to lose the race."

How a change is checked

The baseline

During onboarding, Mimic profiles each protected server in its approved state and records the files, processes, services, registry keys and settings it uses in normal operation. That record is the baseline, and it becomes the enforcement policy. It describes the server, not the threat, so it doesn't need an update when a new variant appears. It's built from what the server actually runs, so a finance server and a domain controller carry different baselines. Approved updates become part of it.

The check

Enforcement runs as a file system mini-filter driver on Windows and through eBPF on Linux, with the enforcement logic in a WebAssembly sandbox implemented in Rust, from a single module on both.

Microsoft describes minifilters as optional drivers that "attach to the file system software stack," where "filter can mean log, observe, modify, or even prevent." The eBPF project says eBPF "can run sandboxed programs in a privileged context such as the operating system kernel."

Mimic decides inline, before the change executes. When a change falls outside the baseline, Mimic stops it at the point of execution. DashCam, Mimic's console, records each blocked attempt with the process behind it and what it tried to change. Change Intelligence is Mimic's running picture of how a protected system is changing: what changed, in what order, how fast and against what baseline. That picture is what lets Mimic stop a harmful sequence of changes before it completes.

What the sandbox isolates, and what it doesn't

Kernel teams ask first: if the logic misbehaves, what does it take down with it?

The WebAssembly project says each module "executes within a sandboxed environment separated from the host runtime using fault isolation techniques." That boundary is around the logic, not the code that hosts it.

On Windows, the driver that hosts the sandbox is still kernel code. On Linux, eBPF programs run inside the kernel, and this guide makes no claim about where the sandbox itself runs there. Ask for that in writing.

The same documentation is plain about limits: "other classes of bugs are not obviated by the semantics of WebAssembly." A sandbox narrows what a fault in the logic can reach. It doesn't make the driver around it safe, and nothing in this guide says it does.

Signing. On Windows, Mimic's enforcement driver passes Microsoft's Hardware Lab Kit tests and carries Microsoft's dashboard signature, which Windows Server 2016 and later require. Microsoft's documentation says "Windows Server 2016 and greater only loads dashboard signed drivers that successfully pass the HLK tests." Signing decides what loads. It doesn't endorse any product's security design.

Language. CISA's June 2025 announcement of its guidance with the NSA says "Memory safety vulnerabilities pose serious risks to national security and critical infrastructure" and that adopting memory safe languages "offers the most comprehensive mitigation against this class of vulnerabilities." It doesn't name a language, and memory safety in the logic says nothing about the driver that hosts it.

How Mimic protects its own processes

Attackers go after the defenses. MITRE ATT&CK's T1685 covers adversaries who "disable, degrade, or tamper with security tools," and it lists stopping services and killing processes among the ways they do it.

Any agent in the kernel has to answer for that. Mimic's own processes are protected at the kernel, so user-space processes, including privileged ones, can't terminate or modify them, and an attempt to tamper with enforcement is itself an unauthorized change that fails the same check.

That's protection for Mimic's processes. It isn't kernel self-protection. The Linux kernel documentation defines that as "the design and implementation of systems and structures within the Linux kernel to protect against security flaws in the kernel itself." One hardens the kernel. The other uses it to decide. Mimic's claim stops at user space: it says nothing about code already running in the kernel, and neither does this guide. Section 02 takes that question head on.

How it differs from the controls around it

Mimic runs alongside EDR. The difference is the question each asks at the kernel: EDR asks whether activity matches an attack it recognizes; Mimic asks whether the change was authorized. EDR sensors run kernel components too, and EDR can block. What separates the controls in Figure 4 is the question each one asks and when it acts.

Network access control decides who and what joins the network. NIST's glossary describes access "based on a user's credentials and the results of health checks" on the device. A session that passes it can still attempt a change on a server, and that change gets its own check.

Allowlisting decides what may run. NIST defines an application allowlist as "a list of applications and application components that are authorized for use in an organization." Kernel-level enforcement applies the same test to changes. CISA recommends "application allowlisting and/or endpoint detection and response (EDR) solutions on all assets." The controls work together.

Figure 4 · The question each control asks

• Network access control. What it checks: a user's credentials and the device's health, before granting access. When it acts: at connection. What it needs to know in advance: who may connect and what a healthy device looks like.
• Model-layer controls. What it checks: prompts, model outputs and the tools an agent may call. When it acts: before the model responds or the tool call runs. What it needs to know in advance: policies for content and tool use.
• EDR. What it checks: process and system behavior against signatures, patterns and models. When it acts: when it recognizes a threat: it alerts, blocks or responds. What it needs to know in advance: what malicious activity looks like.
• Application allowlisting. What it checks: which applications and components may execute. When it acts: when code tries to run. What it needs to know in advance: the approved application inventory.
• Kernel-level enforcement. What it checks: each change to a protected server's files, processes, services and settings, plus registry keys on Windows. When it acts: at the point of execution. What it needs to know in advance: the server's authorized state, not the attack.

AI agents

Mimic AI Guardrails governs what AI agents do inside the environment. The same check applies to what an agent changes on a protected system, whatever credential it holds. After an AI agent finishes a task, Mimic compares the resulting system state with the intent approved before it ran and reports changes outside that intent as violations.

The gap between an instruction and a change is real. In The Register's report of 22 July 2025, SaaStr founder Jason Lemkin detailed how Replit's AI-assisted coding tool "deleted a production database, ignored instructions to freeze code, and invented data." Replit's CEO called it "Unacceptable and should never be possible." The freeze lived in the instructions. The deletion happened in the system.

Blakley makes the design point directly: a control meant to stop a malfunctioning or malicious agent has to be deterministic. A second, non-deterministic agent watching the first can be prompted, confused or made to hallucinate in exactly the same way.

None of this says what any product would have done in Replit's environment, and this guide doesn't claim it.

The Known-Good Enforcement Guide, by Mimic Networks, covers the model as it applies to AI agents.

Section 02 · In Practice

Three techniques, one question

These are scenarios, not customer outcomes. Each pairs a technique MITRE ATT&CK documents with a CISA advisory that reports it in use, then shows what a detection-first control does and what known-good enforcement does.

Deleting shadow copies before encryption (T1490)

The technique. MITRE ATT&CK lists volume shadow copies among the recovery features adversaries remove. CISA and the FBI report (AA24-109A) that Akira's encryptor "uses PowerShell commands to delete Volume Shadow Copy Service (VSS) copies on Windows systems."

What a detection-first control does. CISA's guide tells teams to look for anomalous use of built-in Windows tools such as vssadmin.exe and wbadmin.exe, and calls their misuse "a common ransomware technique to inhibit system recovery."

What known-good enforcement does. Deleting a protected server's shadow copies isn't part of its baseline. Mimic checks the change against the baseline and stops it at the point of execution.

Turning off a security tool (T1685, which replaced T1562.001)

The technique. T1685 covers adversaries who "disable, degrade, or tamper with security tools," including by stopping services, killing processes and changing configuration files and registry keys. CISA and the FBI report (AA25-050A) that "Ghost frequently runs a command to disable Windows Defender on network connected devices."

What a detection-first control does. Security tools defend themselves. Microsoft's tamper protection keeps settings such as real-time protection turned on. CrowdStrike says its sensor uses its kernel-mode presence "to continue to operate even if an attacker would tamper with its user-mode service."

What known-good enforcement does. Stopping a protected service or changing its registry settings is a change outside the server's baseline. Mimic checks it like any other change and stops it at the point of execution.

Installing a new service for persistence (T1543.003)

The technique. Adversaries "may install a new service or modify an existing service to execute at startup in order to persist on a system," as MITRE ATT&CK puts it. The August 2026 update to CISA and the FBI's Medusa advisory (AA25-071A) lists a command that installs conhost.exe as a service with a Cloudflared token.

What a detection-first control does. Windows logs event 4697 when a service is installed. Microsoft recommends monitoring for it "because a new service installation should be planned and expected," and says "Unexpected service installation should trigger an alert."

What known-good enforcement does. A new service isn't in the server's baseline. Mimic checks its creation against the baseline and stops it at the point of execution.

Running it in production

A control in the change path of production servers has to fit how those servers are run. Plan around five things.

• Watching before enforcing. In Active Mode, the node observes and reports. It enforces once a configuration with protections turned on is applied. That gives your team a window to review what it reports before anything is stopped.
• Planned change. A planned deployment goes through an approval gate: a person approves it, or an approved automated approval process does. Approved updates become part of the baseline.
• No connection to the management plane. A protected server with no connection to the management plane stays in enforcement. Upgrades, updates and changes to its known-good profile go in from physical media, such as a USB drive or CD.
• Maintenance windows. In Maintenance Mode, Mimic suspends enforcement and keeps monitoring. Plan those windows like any other change, because enforcement is off while they're open.
• Reboots and overhead. No reboots required. Enforcement overhead is tunable. Mimic doesn't publish a latency figure, so measure overhead on your own workload in a pilot group before you widen enforcement.

One thing this section can't settle for you is how Mimic's driver and module updates are built, tested, staged and rolled back. Ask for it in writing. It's the first question in the vendor table at the end of this section.

The platform in brief

Four Mimic Networks products build on this mechanism: Change Control, Ransomware Defense, AI Guardrails and Virtual Patching. The Known-Good Enforcement Guide, by Mimic Networks, covers each in depth.

• Change Control. Mimic Networks Change Control monitors and tracks every change on a protected server, authorized and unauthorized, so security and GRC teams have a forensic record of what changed. It feeds SIEM and SOAR platforms, and works with ServiceNow, through custom deployments, for ticketing and change approval.
• Ransomware Defense. For protected critical applications, Mimic blocks the unauthorized change before it reaches the data, so there's no window of data loss to clean up. Where a restore is still needed, Mimic creates a restore point the moment it detects the change.
• AI Guardrails and Virtual Patching. Mimic AI Guardrails and Virtual Patching are separate solutions in the Mimic Platform. Both govern threats that agentic AI presents. AI Guardrails governs what AI agents do inside the environment. Virtual Patching closes the exposure that AI-accelerated vulnerability discovery opens before a vendor patch exists.
• Platform support. Windows Server 2016 and later, and Red Hat Enterprise Linux 8 and later. Mimic keeps supporting Windows Server 2016 after Microsoft's Extended Support ends on 12 January 2027.

How it fits the stack you run

Kernel-level enforcement adds a check. It doesn't replace the tools around it.

• EDR and XDR. Keep them. Mimic runs alongside EDR, and the two answer different questions.
• SIEM and SOAR. Mimic feeds enforcement events to your security information and event management (SIEM) and security orchestration, automation and response (SOAR) platforms, so your security operations team sees them alongside the rest of its telemetry.
• ServiceNow. Mimic integrates with ServiceNow through custom deployments for automated ticketing and change management.
• Backups. Keep them. CISA's guide says to keep "offline, encrypted backups of critical data" and to "regularly test the availability and integrity of backups."
• Microsoft's user-mode move. It's part of Microsoft's Windows Resiliency Initiative, introduced at Ignite 2024. Microsoft said on 18 November 2025 that it had released a private preview of its Windows endpoint security platform, which "shifts AV enforcement from the kernel to user mode." The same post says Microsoft is extending its "driver resiliency playbook" beyond antivirus and "will continue to support third-party kernel mode drivers." It gives no date for general availability. On Windows, Mimic's enforcement runs as one of those third-party drivers, a file system mini-filter driver.

What it doesn't do

A control you can't bound is one you can't plan around. Here's where this one stops.

• It protects servers. Laptops, workstations and network appliances need the controls built for them.
• It doesn't replace the rest of the stack. Detection, patching, backups and identity controls all stay.
• It's only as precise as each server's baseline. Keep the baseline current as the server changes.
• It pauses in Maintenance Mode. In Maintenance Mode, Mimic suspends enforcement and keeps monitoring.
• It doesn't remove the flaw. PHP2Shell is the current example. On a server Mimic Networks protects, containment keeps the PHP worker inside its known-good behavior, so what an attacker tries next stops at the point of execution when it falls outside that baseline. Mimic doesn't stop the memory corruption itself, or activity that never leaves the PHP process. Mimic covers Windows Server 2016 and later, and Red Hat Enterprise Linux 8 and later. Mimic's PHP2Shell post covers what to check and ask.
• It makes no claim about code already running in the kernel. That's the kernel question, below.

The kernel question

CVE-2026-68820 is a use-after-free in the Windows Ancillary Function Driver for WinSock, a kernel driver. NVD says it "allows an authorized attacker to elevate privileges locally," and Microsoft flagged it as exploited when it shipped the fix on 11 August 2026. It raises the question a skeptical kernel engineer should ask any vendor: what happens when the attacker is already in the kernel? Here's what this guide claims and what it doesn't.

• An attempt on Mimic itself. Mimic's own processes are protected at the kernel, so user-space processes, including privileged ones, can't terminate or modify them, and an attempt to tamper with enforcement is itself an unauthorized change that fails the same check.
• What an attacker does with elevated privileges. Deleting shadow copies (T1490), stopping a protected service (T1685) and installing a new service (T1543.003) are changes outside the baseline, whatever account makes them. Mimic stops them at the point of execution, as the scenarios show.
• Where the logic runs. In a WebAssembly sandbox implemented in Rust. That's a statement about the logic, not a claim that the kernel code around it is safe.

What this guide doesn't claim is anything about code that's already running in the kernel. Code in kernel mode runs with the kernel's privileges, which is why that case is hard for any kernel-mode control. Ask each vendor, Mimic Networks included, what it claims there.

What to ask any kernel vendor

These are the questions we'd put to anyone who wants to run code in your kernel, Mimic Networks included. Ask for the answers in writing.

The vendor table

• How are your driver and module updates tested and staged? Why it matters: CrowdStrike traced the July 2024 outage to a content update that caused an out-of-bounds memory read in its driver. A useful answer covers: test rings, staged rollout, who controls the timing on your servers and how a bad update is rolled back.
• What runs in kernel mode, and what's isolated? Why it matters: Microsoft suggests security vendors use minimal kernel-mode sensors and run the rest isolated in user mode, "where recoverability is possible." A useful answer covers: each component and where it runs on each operating system, what the isolation boundary is and what a fault inside it takes down.
• What holds once an attacker has code running in the kernel? Why it matters: kernel driver flaws get exploited. CVE-2026-68820 was listed as exploited the day it went public. A useful answer covers: what the vendor claims for that case, what it has tested and what it will put in writing.
• Can a privileged user stop your agent? Why it matters: MITRE ATT&CK's T1685 covers adversaries who stop services and kill processes to impair defenses. A useful answer covers: what an administrator account can and can't do to the agent on each operating system, and how authorized maintenance works.
• How do we measure the overhead on our own workload? Why it matters: overhead depends on the workload, so a number from someone else's test may not hold on yours. A useful answer covers: a test plan on your servers: what to measure, what's tunable and what the vendor will put in writing.

What a demo shows on your servers

Tell us which server matters most to your team, and we'll shape the session around it. A demo shows five things on one of your servers:

• The baseline. Mimic profiles the server in its approved state, and you see what the baseline records.
• A change checked inline. An approved change goes through. Mimic decides inline, before the change executes.
• A stopped attempt. With protections turned on, a change outside the baseline stops at the point of execution, and the attempt appears in DashCam with the process behind it and what it tried to change.
• Maintenance Mode. In Maintenance Mode, Mimic suspends enforcement and keeps monitoring. You see what that looks like on the server.
• How updates reach the node. Your kernel team sees how a driver or module update gets to a protected server and can put the questions above to the real process.

Bring the questions from the table. When you'd like a demo, the form is at mimic.com/demo.

Questions kernel teams ask

What is kernel-level enforcement?

Kernel-level enforcement checks each attempted change to a protected server at the kernel, before it executes, against a verified record of that server's authorized state. Authorized changes proceed. Mimic stops a change outside the record at the point of execution. It needs no attack signature or prior knowledge of the threat.

Does it run on Windows and Linux?

On servers: Windows Server 2016 and later, and Red Hat Enterprise Linux 8 and later. Enforcement runs as a file system mini-filter driver on Windows and through eBPF on Linux, with the enforcement logic in a WebAssembly sandbox implemented in Rust, from a single module on both.

Can it stop zero-days and new ransomware?

Within what enforcement covers, yes. It doesn't prevent the vulnerability from existing or the exploit from running. It checks the change an exploit or a new ransomware strain needs to make on a protected server, and Mimic stops exploitation at the point of execution when that change falls outside the baseline.

Does it slow servers down?

Enforcement overhead is tunable. Mimic decides inline, before the change executes, without a separate scanning or review step. No reboots required. Mimic doesn't publish a latency figure, so test it on your own workload first.

Is it the same as network access control?

No. Network access control decides who and what joins the network. Kernel-level enforcement decides whether a change to a protected server was authorized. Passing a network access check says nothing about the next change on the server.

How is it different from EDR?

Mimic runs alongside EDR. The difference is the question each asks at the kernel: EDR asks whether activity matches an attack it recognizes; Mimic asks whether the change was authorized. EDR sensors run kernel components too, and EDR can block.

Does it replace my existing security tools?

No. It adds a check. Detection, patching, identity controls and offline backups all stay. Mimic feeds enforcement events to your SIEM and SOAR platforms.

Is it the same as kernel self-protection?

No. The Linux kernel documentation defines kernel self-protection as "the design and implementation of systems and structures within the Linux kernel to protect against security flaws in the kernel itself."

Kernel-level enforcement uses the kernel as the place to check changes to a protected server against its authorized state. One hardens the kernel. The other uses it to decide.

Is Mimic a kernel driver, and what does the CrowdStrike outage mean for it?

On Windows, yes. Mimic's enforcement runs as a file system mini-filter driver, kernel code like other security drivers. CrowdStrike traced the July 2024 outage to a content update that caused an out-of-bounds memory read in its driver, and Microsoft estimated 8.5 million Windows devices were affected. Mimic's enforcement logic runs in a WebAssembly sandbox, but the driver around it is still kernel code. Ask any kernel vendor, Mimic included, how updates are tested and staged.

What does Microsoft's move toward user-mode security mean for Mimic?

Microsoft said on 18 November 2025 that it had released a private preview of its Windows endpoint security platform, which "shifts AV enforcement from the kernel to user mode." The same post says Microsoft is extending its "driver resiliency playbook" beyond antivirus and "will continue to support third-party kernel mode drivers." It gives no date for general availability. On Windows, Mimic's enforcement runs as one of those third-party drivers, a file system mini-filter driver.

Sources

Each outside source was read on 28 October 2026. Dates are the dates each source shows.

• FBI Internet Crime Complaint Center: 2025 IC3 Annual Report (no publication date shown)
• Zero Day Clock (Sysdig): first-half 2026 counts (observed to 24 Oct 2026)
• CrowdStrike: External Technical Root Cause Analysis, Channel File 291 (6 Aug 2024)
• Microsoft: Helping our customers through the CrowdStrike outage (20 Jul 2024)
• CISA: New Guidance Released for Reducing Memory-Related Vulnerabilities (24 Jun 2025)
• Windows Experience Blog: Preparing for what's next: Windows security and resiliency innovations help organizations mitigate risks, recover faster and prepare for the era of AI (18 Nov 2025)
• MITRE ATT&CK: ATT&CK v19 (28 Apr 2026)
• MITRE ATT&CK: T1685 Disable or Modify Tools (created 14 Apr 2026, updated 11 Sep 2026)
• CVE-2026-68820: Microsoft Security Response Center (11 Aug 2026); NIST National Vulnerability Database (published 11 Aug 2026); CISA Known Exploited Vulnerabilities Catalog (added 11 Aug 2026, due 25 Aug 2026)
• Microsoft Windows Server Blog: Planning ahead for Windows Server 2016 end of support (25 Feb 2026)
• Microsoft Learn: About file system filter drivers (updated 1 May 2025)
• eBPF.io: What is eBPF? (no date shown)
• WebAssembly: Security (no date shown)
• Microsoft Learn: Driver signing options and best practices (updated 14 Apr 2026)
• The Linux Kernel documentation: Kernel Self-Protection (no date shown)
• NIST Computer Security Resource Center glossary: network access control, from SP 800-41 Rev. 1 (no date shown)
• NIST: SP 800-167, Guide to Application Whitelisting (October 2015)
• CISA: #StopRansomware Guide (September 2023)
• The Register: Replit makes vibe-y promise to stop its AI agents making vibe coding disasters (22 Jul 2025)
• MITRE ATT&CK: T1490 Inhibit System Recovery (updated 12 May 2026)
• CISA, FBI and partners: AA24-109A, #StopRansomware: Akira Ransomware (updated 13 Nov 2025)
• CISA, FBI and partners: AA25-050A, #StopRansomware: Ghost (Cring) Ransomware (19 Feb 2025)
• Microsoft Learn: Protect security settings with tamper protection (updated 30 Jul 2026)
• CrowdStrike: Tech Analysis: CrowdStrike's Kernel Access and Security Architecture (9 Aug 2024)
• MITRE ATT&CK: T1543.003 Create or Modify System Process: Windows Service (updated 12 May 2026)
• FBI, CISA and MS-ISAC: AA25-071A, #StopRansomware: Medusa Ransomware (updated 18 Aug 2026)
• Microsoft Learn: 4697(S): A service was installed in the system. (updated 7 Sep 2021)
• Microsoft Security Blog: Windows security best practices for integrating and managing security tools (27 Jul 2024)

The web version of this guide is at mimic.com/whitepapers/kernel-level-enforcement-guide.

Mimic Networks is the enterprise security company at mimic.com. It isn't the Mimic ransomware family.

If your kernel team has questions this guide doesn't answer, send them our way: sales@mimic.com