Mean time to remediate (MTTR) for vulnerabilities: how to measure it

Mean time to remediate, usually shortened to MTTR, is one of the most common measures of how well a vulnerability management program works. It answers a simple question: once we find a weakness, how long does it take to fix it? A falling MTTR shows a team getting faster. A rising one is often the first sign that remediation is falling behind.

In incident response the same letters can mean mean time to recover or to respond. In vulnerability management, MTTR means time to remediate.

How to calculate MTTR

For each vulnerability that was fixed during the period, take the number of days between the date it was first detected and the date it was confirmed fixed. Add them up and divide by the number of fixed vulnerabilities.

The overall MTTR here is (3 + 14 + 28 + 56) / 4, about 25 days. That number on its own says little. Split by priority, it shows the known exploited finding was fixed in 3 days and the Medium one took 8 weeks, which may be exactly what the policy intends.

When does the clock start and stop?

Decide this once and write it down, because different choices give very different numbers.

• Start: first detected. The date of the first scan that reported the finding on that host. This is the most common choice and the easiest to evidence. Some teams use the CVE publication date instead, which measures exposure rather than team speed.
• Stop: confirmed fixed. The date of the first rescan that no longer reports the finding, not the date a ticket was closed. A closed ticket is a claim; a clean rescan is evidence.
• Accepted risks and false positives are not remediations. Leave them out of MTTR and report them separately.

Because the stop date depends on the next scan, scan frequency sets a floor on MTTR. If you scan monthly, nothing can be shown fixed in less than a month unless you rescan sooner. Fast rescans after urgent fixes keep the number honest. See how often to run vulnerability scans.

Traps that make MTTR misleading

Findings that keep coming back usually have a root cause, such as an old system image or an update policy that skips a product. See why the same vulnerabilities keep coming back.

Metrics to report with MTTR

• Open finding age: how long the oldest and average open findings have been open, per priority.
• SLA compliance: the share of findings fixed within the deadline in your remediation SLA.
• Known exploited open: the number of CISA KEV CVEs still open, and for how long.
• Fixed, new and still open since the last scan: the simplest view of progress for a client or manager.

Together these tell a fuller story than any single number. They also make a good quarterly review slide: MTTR per band, open KEV items, and a fixed-versus-new chart.

How to bring MTTR down

1. Rank by real-world risk so the first work goes to the findings that matter. See risk-based vulnerability management.
2. Group findings into actions. One update often closes dozens of rows.
3. Give every action a named owner and a date in the tool your team already uses.
4. Rescan soon after urgent fixes rather than waiting for the next cycle.
5. Fix the causes of repeat findings, not only the findings.

We built Varaxon Scan Hub to make this measurable without a spreadsheet. Each scan is compared with the previous one, so every finding has a first-seen date, a fixed date when it disappears from a later scan, and an age while it stays open. Reports show what was fixed, what is new and what is still open, per client. Every new account gets a 14-day free trial, no card needed: see how it works.

Common questions