Mean time to remediate (MTTR) is the average time it takes a security program to fix a vulnerability after it's found. You calculate it by adding up the time from detection to deployed fix for every vulnerability remediated in a period, then dividing by the number of vulnerabilities remediated. A lower MTTR means a shorter window in which attackers can use a known weakness.
This guide defines MTTR in security, walks through the formula with a worked example, compares it with related metrics, and explains what a good MTTR looks like.
What is mean time to remediate?
Mean time to remediate is a security metric that measures the average elapsed time between the discovery of a vulnerability and its remediation. It's usually reported per severity or risk tier, per team, and per period (a month or a quarter).
Two definitions decide what the number means:
- Detection: the moment a scanner, test or researcher first reports the vulnerability.
- Remediation: the moment a fix is merged and deployed, or an approved mitigation is in place.
A finding closed as a duplicate, suppressed or accepted as a risk was not remediated. Count it separately, or it will lower MTTR without lowering exposure.
The MTTR formula
MTTR = sum of (remediation time − detection time) for every remediated finding ÷ number of remediated findings
Only findings that were actually remediated in the period go into the formula. Findings still open don't count, which is why MTTR always needs an open-backlog number beside it.
How to calculate MTTR: a worked example
Say your team remediated five High findings last month. These numbers are illustrative:
| Finding | Detected | Remediated | Days open |
|---|
| SQL injection in reporting API | Oct 1 | Oct 3 | 2 |
Vulnerable lodash version | Oct 2 | Oct 5 | 3 |
| SSRF in webhook handler | Oct 6 | Oct 10 | 4 |
| Hardcoded token in CI config | Oct 8 | Oct 18 | 10 |
| IDOR in billing service | Sep 20 | Oct 31 | 41 |
Total days open: 2 + 3 + 4 + 10 + 41 = 60. Divide by five findings, and the MTTR is 12 days.
The median is 4 days. Four of the five findings were fixed in 10 days or less, and one long-running IDOR pulled the mean to 12. That gap is the reason to report the median and 90th percentile alongside the mean. The mean tells you how much exposure time accumulated. The median tells you what a typical fix looks like.
Why MTTR matters in security
A known, unfixed vulnerability is the cheapest way into a system, because the attacker doesn't have to find anything new. MTTR is the closest single number to "how long do we stay exposed once we know."
It also sits behind the commitments most programs report on. Remediation SLAs are deadlines per risk tier, and MTTR is the measured reality those deadlines are tested against. In June 2026, CISA's BOD 26-04 moved US federal agencies to risk-based remediation timelines driven by exposure, KEV status, exploit automation and technical impact. A program that can't measure its time to remediate can't show it meets timelines like these.
What MTTR stands for in security vs. other fields
The acronym MTTR has several expansions, and they get mixed up in dashboards.
| Metric | Stands for | Measures | Common in |
|---|
| MTTR | Mean time to remediate | Detection to fix of a vulnerability | Vulnerability management, AppSec |
| MTTR | Mean time to respond | Alert to containment of an incident | SOC, incident response |
| MTTR | Mean time to repair / recover | Failure to restored service | SRE, IT operations |
| MTTD | Mean time to detect | Introduction to discovery | Both |
| MTTA | Mean time to acknowledge | Alert to someone taking ownership | Both |
In vulnerability management, MTTR almost always means remediate. In a SOC report, it usually means respond. State which one you mean on every chart.
MTTD and MTTR together describe the full exposure window: how long a weakness existed before you found it, plus how long it stayed open after.
What is a good MTTR?
There is no universal benchmark, because MTTR depends on what you count. A program that includes every low-severity dependency finding will have a very different number from one that only counts confirmed, reachable Criticals.
Three better questions than "is our MTTR good":
- Is MTTR within SLA for each tier? Compare each tier's MTTR with its deadline.
- Is it trending down? Compare each team against its own last quarter, not against other teams.
- Is the open backlog aging? MTTR can improve while old findings quietly sit open.
What drives MTTR up
Writing the fix is rarely the slow part. Most of the clock runs while a finding waits:
- Triage: someone has to decide whether the finding is real and reachable. Noisy scanners make this queue long.
- Ownership: a finding filed into a team backlog waits until someone recognizes the code.
- The fix: a ticket that says "this endpoint is vulnerable" makes the developer start from zero.
- Review and merge: a correct pull request can sit unreviewed for days if no one is chasing it.
The way to cut MTTR is to remove those waits: triage on reachability and exploitability, route to the code owner, hand over a fix instead of a description, and escalate stalls before the deadline.
How to start tracking MTTR
If you don't report MTTR yet, four steps get you a number you can trust:
- Record a detection timestamp for every finding. Use the first time any scanner reported it, and keep that date if the finding is re-imported or re-scored.
- Record a remediation timestamp only for real fixes. That means a merged and deployed fix, or an approved mitigation. Tag suppressions, duplicates and accepted risks with a different close reason.
- Split by tier and team. A single program-wide MTTR mixes fast dependency bumps with slow architectural fixes, so nobody can act on it.
- Report monthly, with the median and open-finding age beside it. One number on its own invites the wrong conclusion.
Most scanners and ticket trackers already store both timestamps. The work is agreeing on the definitions and applying them the same way every month.
Related metrics to report with MTTR
| Metric | Why it belongs next to MTTR |
|---|
| Median and 90th percentile time to remediate | Shows the typical case and the long tail the mean hides |
| Open findings by age | Catches old findings MTTR never counts |
| SLA compliance by tier | Ties MTTR to the commitments you report on |
| Accepted risks and suppressions | Keeps closures that weren't fixes visible |
| Mean time to detect | Completes the exposure window |
How Nullify reduces mean time to remediate
Nullify works on the waiting time. Triage scores every finding continuously on reachability, exploitability, business context and confidence, and filters unreachable code, test fixtures and benign configuration before a person reviews it. Confirmed findings route to the commit author, then CODEOWNERS, then the wider team.
For the fix, Nullify opens a minimal, root-cause pull request that's validated against your build before it opens, then manages it through review by reading CI output and fixing failures. It never auto-merges, so your engineers approve every change. MTTR and SLA compliance are reported per team. See how it works on the triage and remediation page.
Frequently asked questions
What does MTTR mean in cybersecurity?
In vulnerability management, MTTR means mean time to remediate: the average time from discovering a vulnerability to fixing it. In incident response, MTTR usually means mean time to respond, the average time from an alert to containment. Always state which one a report uses.
How do you calculate mean time to remediate?
Add up the days from detection to deployed fix for every vulnerability remediated in the period, then divide by the number of vulnerabilities remediated. For example, five findings open a total of 60 days gives an MTTR of 12 days. Report the median and 90th percentile next to the mean.
What is the difference between MTTR and MTTD?
Mean time to detect (MTTD) measures how long a vulnerability exists before it's found. Mean time to remediate (MTTR) measures how long it takes to fix once found. Together they make up the full exposure window for a vulnerability.
Is a lower MTTR always better?
A lower MTTR is better when it comes from fixing faster. It isn't better when it comes from closing findings without fixing them, such as suppressions or accepted risks, or from counting only easy findings. Pair MTTR with open-finding age and SLA compliance to make sure the improvement is real.
