MTTR and MTTE: how to reduce MTTR in the window between alert and compromise

60 to 150 days to fix it. A few days for an exploit to become available. In between, your organization is exposed, often without knowing it.

It's 11am on a Tuesday. Your vulnerability management tool just flagged a critical alert: CVSS 9.6 (a severity score out of 10), an exposed asset within your perimeter is affected. You open a ticket, qualify the severity, assign the network team. Standard procedure, executed correctly.

What you don't know at this moment: the attacker monitoring new CVE publications has already had a working exploit for several days. They were waiting for this bulletin to identify targets. In the vast majority of organizations, it's in this gap between detection and actual remediation that the most avoidable compromises concentrate.

Two numbers will determine what happens next. Your MTTR, meaning how long it will take you to fix it. And the attacker's MTTE, meaning how long it took them to get an exploit. The difference between the two is your real exposure window.

It's a race where you never see your opponent. You know you have to cover a certain distance to fix the flaw. What you don't know is how far behind you the attacker is, or whether they already had a head start before the official starting gun.

Key takeaways

• Average MTTR: 60 to 150 days to fix a critical vulnerability

• MTTE: often negative on critical CVEs, the exploit exists before the patch

• Exposure window = MTTD + MTTR. If it exceeds your MTTE, you're exposed by construction

• NIS2 and DORA require notification within 24-72h: MTTR becomes a regulatory indicator

• Combining continuous visibility, contextual prioritization, and post-remediation re-scanning cuts MTTR by a factor of 3

Before we go further into this Tuesday morning, let's set the basics. These acronyms describe very different realities and rank among the key performance indicators most closely tracked in vulnerability management. Confusing them often skews reporting.

MTTR. MTTR measures the average time needed between detecting a vulnerability and its confirmed fix. The clock starts at detection, not at triage. The MTTR calculation works as follows: total remediation time ÷ number of fixes completed. It must be segmented by criticality level: an aggregated MTTR tells you nothing about your real exposure, and often hides a resolution process that works well on some assets and poorly on others.

MTTE. This is the attacker's metric. According to Pixee data (analysis of 100,000+ remediation PRs, 2025), on critical CVEs this delay is often negative: exploits circulate before the official patch. The Mandiant M-Trends 2026 report confirms the trend at a macro level: average MTTE is now estimated at -7 days, compared to 63 days in 2018. If your MTTR exceeds your MTTE, you're exposed by construction.

Most vulnerability management programs track MTTR without ever comparing it to MTTE. This is the industry's most common blind spot: measuring your own remediation speed without ever comparing it to the threat's actual speed. An MTTR of 30 days might look fine in isolation. Set against an MTTE of -7 days on the same CVE, it reveals a 37-day exposure window during which the exploit already existed.

"MTTR alone tells you nothing. It's confronting it with MTTE that reveals your real exposure. We built Patrowl's entire prioritization logic around that gap, not around MTTR taken in isolation.", explains Vladimir Kolla, co-founder of Patrowl.

MTTR remains a key indicator to measure the effectiveness of a remediation program, but on its own, it's an incomplete performance indicator: it tells you nothing about the speed of the attacker on the other side.

Your ticket is open, the alert qualified, your network team notified. What field data shows in parallel is uncomfortable.

According to the Mandiant M-Trends 2026 report, the time between an attacker's initial access and handoff to another threat group dropped from more than 8 hours in 2022 to 22 seconds in 2025. The industrialization of exploitation is no longer remotely artisanal.

The moment you open your ticket this Tuesday morning, the CVE was published this morning, but the associated exploit has been circulating for several days in private offensive channels. Your qualification, assignment, and remediation process will take between 3 and 4 weeks on a critical vulnerability, which is common even in well-structured teams.

Result: 28 to 35 days of net exposure on a flaw for which an attacker already has a documented vector. This isn't a failure of your teams. It's the structural mismatch between a process built for a weekly rhythm and a threat that operates in real time.

"MTTR isn't just a speed indicator. It's a financial risk indicator. Every additional day of exposure on a critical CVE with a public exploit is an open window someone might decide to use.", explains Florent Montel, co-founder of Patrowl.

This scenario played out across hundreds of organizations in February 2024. It illustrates exactly the MTTR / MTTE mechanics in a real-world context, and remains a textbook case of how critical security flaws turn into full-blown security incidents.

Day −7. Working exploits are circulating in private offensive channels. Your organization has no idea. The flaw already exists in your systems.

Day 0, February 8. Fortinet publishes the bulletin. CVE-2024-21762, CVSS 9.6, unauthenticated remote code execution. Fortinet confirms active exploitation in production at the time of publication. Some organizations are already compromised before receiving the first alert.

Day +1. Public exploits appear on GitHub. CISA (the US cybersecurity agency) adds the CVE to its KEV list (Known Exploited Vulnerabilities, actively exploited flaws). For US federal entities: 14 legal days to fix it. For everyone else: the clock is running.

Day +3 to +7, estimated MTTD: 3 to 7 days. Organizations running weekly scans now discover three uninventoried FortiOS appliances exposed on the internet. Those with continuous monitoring knew within hours of Day 0.

Day +7 to +45, observed MTTR: 21 to 45 days. Triage, network assignment, staging, change management, phased rollout. Teams are doing their job correctly. But every step takes time. Some large organizations exceed 60 days.

Real exposure window: 24 to 52 days on a vulnerability with a public exploit since Day +1. The root causes remain the same across the majority of documented incidents: uninventoried FortiOS appliances, absent from routine scans, detected late, or not detected at all before compromise. When the appliance goes down or has to be isolated in an emergency, an entire IT department ends up depending on a fix applied under time pressure.

Technical impact: unauthenticated remote code execution on the FortiOS appliance, giving the attacker full access to the firewall or VPN concerned, the usual entry point into the rest of the internal network.

Business impact: direct access to the company's network from the outside, with no need for credentials or insider help. Depending on the compromised appliance's role, this can mean shutting down the VPN for all remote staff, a service disruption for DevOps teams who depend on that access, or a pivot point toward production servers. A patch applied 24 hours after Fortinet's bulletin would have prevented several days of downtime for some of the affected organizations.

At 5pm, you notice that the average MTTR on critical vulnerabilities has been stuck above 40 days for months, despite a competent team and documented processes. This paradox is common. Organizations struggling with high MTTR aren't lacking technical skills. They run into structural constraints that scanners can't solve on their own. Even the most experienced security teams struggle to maintain a stable MTTR over a given period if initial visibility is missing.

In short: the problem starts before remediation. It starts at the visibility level.

The asset isn't in the inventory. A subdomain pushed to production six months ago, a cloud instance opened by a dev, an unreferenced third-party API: your scanner only detects what it knows about. This vulnerability will never show up in your history. The exposure clock starts running before detection even happens.

The priority ticket isn't the right one. CVSS 9.8 at the top of the list. Your team tackles it. Except it's an internal server that's never been exposed. Meanwhile, the 7.2 on your public API with a known exploit waits. Without context, you fix what's red, not what's dangerous.

The process eats the time. Detection on Monday, triage on Tuesday, assignment on Wednesday, staging the following week, the change the week after that. In large organizations, this chain accounts for 60 to 70% of total MTTR. It isn't the technical work that creates the bottleneck. The repair process itself is rarely the bottleneck: it's the coordination between incident management, infrastructure teams, and business teams that eats up the mean time to repair.

Nobody wants to take down production. Patching urgently means convincing a dev team mid-sprint, pushing through an express change management process, risking a service outage. Security often loses that trade-off. Reducing false-priority noise helps win the argument for real emergencies, but no tool solves this organizational problem on its own.

"What we consistently see with clients who have a high MTTR isn't a lack of skill. It's a poorly calibrated priority list because the real exposure context is missing. Raw CVSS is a lab score. What matters is CVSS + is the asset exposed + is there an active exploit.", summarizes Vladimir Kolla, co-founder of Patrowl.

In short: MTTR is no longer just an operational KPI. It's what you show your executive committee, your auditors, and your regulators to demonstrate you're in control of your security posture.

Every month, CISOs produce reports for the executive committee, auditors, cyber insurers, or regulators. One question comes up systematically: how many critical vulnerabilities remain open, for how long, and on which assets?

To answer that properly, you need to be able to explain which critical vulnerabilities remain open, for how long, on which assets, why certain fixes were prioritized over others, and how the risk level evolves over time. This is exactly the level of granularity regulators now expect on security matters.

NIS2 requires essential and important entities to notify ANSSI within 24 hours, then provide an interim report within 72 hours. DORA introduces comparable obligations for financial entities. MTTR becomes a compliance indicator as much as a risk management indicator.

Observed targets vary by criticality: critical vulnerabilities between 7 and 15 days, high ones around 30 days, medium ones up to 90 days, low ones up to 180 days. These benchmarks remain insufficient on their own. A CVSS 9.8 CVE on an unexposed internal server often carries less risk than a CVSS 7.2 on a public API with a documented exploit.

"In executive committee meetings, the question that comes up isn't 'what's our MTTR'. It's 'can we prove we know what we expose and that we're managing it'. DORA and NIS2 have made that proof mandatory, with deadlines and associated penalties.", notes Nicolas Mattiocco, co-founder and CEO of Patrowl.

By the end of the day, your dashboard shows an MTTR of 28 days, a figure that looks satisfactory against industry benchmarks. In many organizations, that result is the product of three systematic calculation biases that understate the real exposure.

The clock starts at triage, not at detection. The scanner runs Monday at 2am, the analyst sees the vulnerability Thursday during their weekly review. In most tools, remediation time starts when the ticket is opened, meaning Thursday. Those 3 days disappear. Multiply that bias across all your vulnerabilities, and your real MTTR is systematically understated.

The ticket is closed, the flaw is still open. Patch applied, ticket closed, MTTR improved. But nobody checked that the patch was actually deployed across all three instances, or that the post-patch configuration is correct. A few weeks later, a pentest or an attacker finds the flaw still there. Remediation time should end at confirmed validation, not at ticket closure.

One single number for everything. MTTR of 42 days presented to the executive committee. What it doesn't say: critical MTTR at 88 days, low-severity MTTR at 8 days. Calculate your MTTR by criticality level and by asset type. That's the only number that actually drives anything.

Let's replay the scene: same critical CVE, same CVSS 9.6 score, same Tuesday at 11am. But this time with full visibility into the assets concerned.

Organizations that deploy Patrowl see, on average, their MTTR cut by a factor of three on exposed critical vulnerabilities. This improvement rests on three mechanisms, told through the thread of this Tuesday morning. Implementing this setup isn't just about reducing remediation delays: it's also a direct way to improve MTTR without hiring a single additional person on the incident response team.

11:02am, you already know this asset exists. Patrowl's EASM (External Attack Surface Management, continuous mapping of your exposed perimeter) has already identified the exposed FortiOS appliances, including the ones no inventory referenced. When the CVE lands, you know within minutes whether you're affected and where. MTTD: from 7 days down to a few hours.

11:08am, your priority ticket is the right ticket. Patrowl cross-references internet exposure, the asset's business value, and the existence of a documented exploit. The list your analyst sees reflects your real risk, not raw CVSS. The FortiOS appliance exposed on the internet rises to the top. The internal server with CVSS 9.8 that was never exposed drops down the list.

Day +15, you know the patch was actually applied. Patrowl triggers an automatic re-scan after every reported remediation. If the flaw is still present, the ticket reopens. The loop only closes when it's truly fixed, not when the ticket is closed.

"Post-remediation re-scanning is often where you find the surprises. A patch deployed on two out of three instances, an incorrect post-patch configuration, a twin asset everyone forgot about. Without automatic external validation, these cases stay open without anyone knowing.", adds Florent Montel, co-founder of Patrowl.

The next critical vulnerability won't necessarily hit an asset already sitting in your inventory.

Patrowl continuously maps internet-exposed assets, identifies vulnerabilities that are genuinely exploitable, and helps security teams prioritize the fixes that actually reduce risk.

Do you know how long it would take you to detect a critical CVE on an off-inventory asset?

This Tuesday morning will happen again. A critical CVE will drop, an exploit will be available before the patch, and your teams will do their job correctly within a timeframe that exceeds the exploitation window.

What separates two organizations in this situation is rarely team competence. It's visibility into what they actually expose, the precision of what they fix first, and the certainty that what's been fixed is truly fixed.

MTTR is a symptom. The cause is the gap between your real perimeter and what you think you're monitoring. Implementing cybersecurity best practices isn't enough if this basic visibility is missing.

What is MTTR in cybersecurity?

MTTR (Mean Time to Remediate) measures the average time between detecting a vulnerability and its confirmed fix. In vulnerability management, this window ranges from 60 to 150 days depending on the organization (Cymulate / Praetorian). It's the central indicator of a security program's operational speed, and a regulatory compliance indicator under NIS2 and DORA.

How do you calculate MTTR?

MTTR = total remediation time ÷ number of fixes completed over a period. Calculate it by criticality level, not in aggregate. The clock starts at initial detection, not at ticket creation. The fix is validated by an external re-scan, not by closing the ticket.

How can you reduce MTTR on critical vulnerabilities?

Three levers: continuous visibility into the real attack surface (including off-inventory assets), contextual prioritization rather than raw CVSS, and automatic post-remediation re-scanning. Organizations that combine all three cut their MTTR by a factor of 3 on exposed critical vulnerabilities, according to Patrowl field data.

What MTTR target should you aim for on critical vulnerabilities?

CISA BOD 22-01: 14 days for KEVs (Known Exploited Vulnerabilities, flaws actively exploited in production). NIS2 and DORA: notification within 24-72h. The most responsive organizations aim for 7 to 15 days on critical vulnerabilities with a publicly available exploit. These targets should be defined per asset segment, not globally.

Is a lower MTTR always better?

No. What matters is the MTTR on exposed vulnerabilities with an available exploit. Fixing low-severity vulnerabilities on unexposed internal assets in 2 days while exposed critical ones wait 90 days produces a presentable average MTTR and a disastrous actual exposure.

How do you justify an investment in MTTR reduction to the executive committee?

IBM Cost of a Data Breach 2025: average cost $4.88M. Organizations under 14 days of critical MTTR cut that cost by 30%. Under NIS2 and DORA, a high MTTR increases exposure to regulatory penalties when an incident isn't notified within the required timeframe. The question isn't the cost of the tool, it's the cost of every additional day of exposure.

Mandiant M-Trends 2026 · Veracode State of Software Security 2025 · IBM Cost of a Data Breach Report 2025 · FIRST.org CVE forecast 2026 · CISA Binding Operational Directive 22-01 · Praetorian MTTR Benchmarks 2026 · Cymulate Threat Exposure Validation Impact Report 2025 · Pixee Platform Data 2025 · CESIN Baromètre 2024 · NIS2 Directive (EU 2022/2555) · DORA Regulation (EU 2022/2554) · Fortinet PSIRT FG-IR-24-015