Autonomous Mitigation, Defined: Whitepaper on Closing the Exploitability Window

Thank you!

You're subscribed!

Oops! Something went wrong while submitting the form.

Today we are publishing Autonomous Mitigation: Closing the Exploitability Window, a whitepaper for security leaders who need to keep vulnerabilities from being exploited while the permanent fix is still on its way. It defines the category, lays out the standard a mitigation approach must meet, and gives teams a way to measure how long their exposures actually stay open.

This post previews the paper’s core ideas: why mitigation needs to run on its own, faster clock; what does and does not qualify as Autonomous Mitigation; how to measure whether an exposure window is actually closed; and how security teams can adopt autonomy one scope at a time.

Finding the Risk Is Not the Same as Reducing It

Defenders have never been better at discovering risk. Scanners, pentests, bug bounties and AI-driven research surface more findings than ever. A finding, however, does not change the security state. A vulnerability stays usable by an attacker until something actually stops the exploit path from succeeding.

The whitepaper frames the response as two clocks. Remediation is the slow clock: it removes the root cause, but it is bound to engineering workflows, regression testing, change management and release schedules. Mitigation is the fast clock: it changes the security state so the exploit path can no longer succeed, using controls already in the environment, without waiting for a code change. Organizations need both. The problem is that most programs still run only the slow one, which means risk is discovered at machine speed and remediated at human speed.

The Standards Already Point This Way

The evidence for a faster response is not theoretical. CISA's Known Exploited Vulnerabilities catalog held 1,717 entries as of September 21, 2026, with 233 added during 2026 and 360 linked to known ransomware campaigns. CISA's Binding Operational Directive 26-04 now requires federal agencies to address the highest-risk vulnerabilities within three calendar days, and it does not require that the fix be a patch. NIST SP 800-40r4 likewise lists mitigation as a formal risk response.

What Autonomous Mitigation Is, and What It Is Not

The whitepaper defines Autonomous Mitigation as the ability to deploy and sustain verified, environment-specific protection at machine speed, within policy-defined bounds, preventing exploitation while permanent remediation proceeds.

The definition rests on outcome rather than on the control being deployed. The test is whether the security state changed so the exploit path can no longer succeed, and whether you can prove it. A rule that can be bypassed does not pass that test, and neither does a detection that only raises an alert.

This is where virtual patching fell short of its promise. Virtual patches typically come from rules a vendor writes for its own product without knowledge of any customer’s environment, or from rules security teams handcraft themselves.

Autonomous Mitigation can be broken down into a seven-stage loop, from knowing the live environment to retiring the protection once the fix is deployed.

A seven-stage loop: know the live environment, prove exploitability in the attack path, choose the optimal action, deploy the mitigation, verify and adapt to the environment, govern and improve, and retire. — *The Autonomous Mitigation loop runs from knowing the live environment to retiring the protection once remediation lands.*

The difference is measurable. In our Beat the Bypass research, the best-performing generic managed ruleset blocked 48% of real exploit bypasses, while environment-specific mitigation blocked 91%. A generic rule is written against a payload someone has already seen; a derived mitigation is written against what any exploit must do to reach the vulnerable function, which is why it holds up against mutation.

A Metric that Measures the Window Itself

Most programs measure speed to patch. Time to Verified Mitigation (TTVM) measures how long an exploitable vulnerability actually stays open: from the moment it is confirmed as requiring mitigation in your environment to the moment the exploit path is provably closed.

TTVM should always be reported as p50 and p90, because the tail is where breaches happen.

Speed alone does not prove the window is safely closed, so the paper pairs TTVM with a six-part scorecard covering mitigation coverage, adversarial efficacy, operational safety, resilience and autonomy rate.

Autonomy Is Earned One Scope at a Time

No security team should hand production controls to a machine on day one. There is a path of driving automation, from Level 0, in which the system observes and the human decides, to Level 4, in which the human sets policy and the system acts within it. The map below shows which stages the system owns at each level, and where the human stays in control.

A grid of five autonomy levels (Observe, Advise, Prepare, Supervised, Policy-bounded) against six stages (Identify, Generate, Lab test, Deploy, Verify, Block), showing whether the system or a human acts at each stage. — *At each level, the system takes on more of the work, and the human moves from acting to approving to setting policy.*

Teams grant autonomy per scope, such as an asset class, a vulnerability type or a control, and move each scope up a level as the system builds a record of verified mitigations. There is deliberately no Level 5: humans always set the rules.

What You Will Find in the Whitepaper

Where Autonomous Mitigation sits alongside exposure management, offensive validation, and other detection and enforcement controls
The category standard: seven requirements a product must meet to qualify, and the capabilities that do not qualify on their own
The TTVM breakdown and the Autonomous Mitigation scorecard
A four-step assessment for measuring your own exploitability window

The paper is written for CISOs, vulnerability management leaders, application and product security teams who are finding risk faster than they can protect against it, and for anyone evaluating whether their program needs Autonomous Mitigation capabilities.

This paper sets out the approach and the standard. We will share more on how Miggo puts it into practice soon.

Read the whitepaper now

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>