What Is Known-Good Enforcement?

Updated 24 October 2026. Outside sources are listed at the end of the page, each with its own date.

Known-good enforcement is a security model that allows only the changes a system is authorized to make. It builds a baseline of the system in its authorized state, checks each attempted change against that baseline at the kernel and stops what falls outside it. It doesn’t need to recognize the attack, so a novel threat gets the same test as a known one.

Why isn’t recognizing threats enough?

Most security tools are built to recognize threats. Signatures, behavioral rules and machine learning models compare activity with what’s known about attacks, and they act on a match. Against a large class of threats that works well. The limit is structural: a control that has to recognize an attack can’t act on one it doesn’t recognize yet.

Three conditions make that limit matter more now:

• Some flaws are exploited by the day they go public. Of the 491 vulnerabilities newly named as exploited in the first half of 2026, attackers were already exploiting 141 when those flaws went public, per the Zero Day Clock, read 24 October 2026.
• Valid accounts look legitimate. MITRE ATT&CK documents adversaries abusing the credentials of existing accounts to get in, persist and escalate privileges (T1078). An action taken with a valid credential through an approved tool may match no threat pattern at all.
• Trusted binaries carry the attack. Adversaries proxy execution of malicious content through signed or otherwise trusted binaries, often signed files already native to the operating system (T1218). That activity can look like routine administration.

A model that has to know the attack in advance carries an exposure window: the time between when an attack becomes possible and when a rule exists to catch it. Known-good enforcement doesn’t close that window by recognizing faster. It asks a question that doesn’t depend on recognition at all.

What is known-good enforcement?

Known-good enforcement is the security model Mimic Networks implements. It establishes a verified baseline of a system’s authorized state (its approved files, processes, services and configuration), then checks each attempted change against that baseline at the kernel before it executes. Authorized changes proceed. Unauthorized changes are stopped, whatever the threat behind them.

The principle isn’t new. NIST defines an application whitelist as “a list of applications and application components that are authorized for use in an organization” (NIST SP 800-167). The wider industry calls the approach a positive security model, or default deny. Known-good enforcement applies it to change on a protected server: not only which software may run, but which changes to files, registry keys, services and configuration may happen.

The baseline

The baseline is the verified record of a server in its authorized state. Mimic builds it by profiling each protected server during onboarding and keeps it current as authorized change happens. It’s a measured record of how the server runs when it’s running correctly, not a policy someone writes from assumptions.

The check at the kernel

Each attempted change to a protected component is checked before it executes, and Mimic decides inline. 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.

Running at the kernel isn’t what sets the model apart. Major endpoint detection products run kernel components too. The difference is the question asked there: detection asks whether activity matches an attack it recognizes, and known-good enforcement asks whether the change was authorized. For the mechanism in depth, see what is kernel-level enforcement security?

How does known-good enforcement differ from detection and allowlisting?

Application allowlisting is the model most often confused with known-good enforcement. NIST describes allowlisting technology as controlling “which applications are permitted to execute on a host” (NIST SP 800-167). A control that decides at launch doesn’t, by itself, check what an allowed application changes afterward. Known-good enforcement checks the change, whichever process makes it, including an approved tool used in an unapproved way.

None of this makes the other controls optional. CISA recommends “application allowlisting and/or endpoint detection and response (EDR) solutions on all assets to ensure that only authorized software is executable and all unauthorized software is blocked” (CISA). On Windows, Microsoft’s App Control is one way to do that (Microsoft Learn). Mimic Networks is designed to run alongside existing EDR, XDR, SIEM, SOAR and BCDR tooling rather than replace it.

How does the known-good enforcement framework work?

The method has a name: the Known-Good Enforcement Guide, by Mimic Networks. It runs in five steps, in the order they happen.

1. Profile the authorized state

   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.

2. Check each change before it executes

   Each attempted change to a protected file, process, service, registry key or setting is checked against the baseline. Mimic decides inline, before the change executes. The question isn’t whether the change looks malicious. It’s whether the change was authorized, whichever process makes it.

3. Stop what falls outside the baseline

   Authorized changes proceed. When a change falls outside the baseline, Mimic stops exploitation at the point of execution. 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.

4. Record each attempt

   Each blocked attempt is recorded with the process behind it and what it tried to change. Teams review the record in DashCam, Mimic’s console. The record comes from where enforcement runs, so it exists whether or not anyone asked for it.

5. Keep the baseline current

   Approved updates are part of the baseline’s lifecycle, so legitimate operations continue as the environment changes. For planned administrative work there’s Maintenance Mode. In Maintenance Mode, Mimic suspends enforcement and keeps monitoring, so plan those windows like any other change.

The Known-Good Enforcement Guide is also a PDF.

Related: Block unauthorized changes

How does known-good enforcement apply across the Mimic Networks platform?

The Mimic platform applies one enforcement model to four problems. What differs is the class of change each product governs.

Ransomware Defense

Encryption requires modifying files (MITRE ATT&CK T1486), and attackers commonly delete shadow copies and turn off recovery features to block recovery (T1490). Ransomware Defense applies known-good enforcement to protected servers. 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. The full method is in how to stop ransomware before encryption.

Mimic AI Guardrails

AI Guardrails governs what AI agents do inside the environment. It applies the same check to what an agent changes on a protected system, whatever credential or tool the agent holds.

Virtual Patching

Virtual Patching closes the exposure that AI-accelerated vulnerability discovery opens before a vendor patch exists. It works in two forms, and both require baselining. Disruption blocks the specific mechanism an analyzed vulnerability depends on, so the exploit doesn’t succeed. Containment limits what an exploit can do once it lands, so one safeguard can cover a whole family of exploits. Before a Virtual Patching safeguard goes live, Mimic replays it against the host’s recorded behavior to show what it would block. Virtual patches roll back instantly. It’s part of Mimic’s known-good enforcement approach.

Change Control

Change Control checks each change to a protected production server against the baseline: authorized changes proceed, unauthorized changes are stopped and recorded. Mimic integrates with ServiceNow through custom deployments for automated ticketing and change management.

Related: Servers you can't patch, Agentic AI Governance

What doesn’t known-good enforcement do?

• It doesn’t remove the vulnerability. An exploitable flaw stays until it’s patched. Enforcement changes what an exploit can do on a protected server, not whether the flaw exists.
• It doesn’t name the attack. It decides whether a change was authorized. Investigation, threat intelligence and attribution stay with detection and response tools.
• It doesn’t retrieve stolen data. CISA’s guide treats ransomware and data extortion as one problem (CISA). Data copied out before an attack was stopped stays copied out.
• It covers the servers it protects. Mimic runs on Windows Server 2016 and later, and Red Hat Enterprise Linux 8 and later. Workstations, mobile devices and network gear need their own controls.
• It doesn’t replace the rest of the stack. Patching, identity controls, detection and offline backups each cover ground enforcement doesn’t.

Related reading: the known-good enforcement glossary defines the terms, and what runs beside EDR to stop ransomware shows where each control sits.