Mean Time to Remediate (MTTR): How to Measure It and Cut It

A vulnerability disclosed today can be the target of an attack within two weeks. If your team needs six weeks to fix it, the math is not in your favor. Mean time to remediate (or MTTR) is the number that exposes that gap. What is mean time to remediate? MTTR is the average time it takes your team to fix a vulnerability, measured from the moment you detect it, to the moment a rescan confirms the fix. It's the core metric for how fast a security program closes real risk. A short MTTR means a small exposure window. A long MTTR means attackers have time to reach the flaw before you close it. The formula is simple: MTTR = Total remediation time / Number of vulnerabilities remediated Total remediation time is the sum of the time each vulnerability took to fix, from detection to verified fix. Divide it by the count of vulnerabilities you closed in the period, and you get the average. Track it by severity, because a blended average hides the number that matters: a 40-day average is fine for a low-severity issue and a disaster for a reachable critical. MTTR sits next to a related metric, mean time to detect (MTTD), the time from a vulnerability existing to your team finding it. The two add up to your real exposure. A team can post a fast MTTR and still run a wide exposure window if detection lags, so measure both. How to measure MTTR (and where teams get it wrong) Measuring MTTR looks simple and goes wrong in three predictable ways. - Ending the clock too early. Many teams stop counting when a pull request merges. - The vulnerability is not fixed when the PR merges. It is fixed when a rescan confirms it is gone. Stop the clock at verification, not at the merge, or your MTTR will read better than your risk. - Blending the average. One MTTR number across every severity tells you nothing actionable. Report MTTR by severity, and separate reachable from unreachable findings, so the metric reflects real risk instead of raw volume. - Measuring what's easy. If you track MTTR for direct dependencies but not transitive ones, or for code but not containers, the number covers a fraction of your exposure. Measure across the full stack, or the metric flatters a program that still has open holes. The number means something when you set the clock from detection to verified fix, break it out by severity and reachability, and cover the whole stack. What drives MTTR up (noise, breaking changes, manual work) Three forces stretch MTTR, and all three are fixable. - Noise. When a scanner reports thousands of findings and most never run, the team spends its time triaging false positives instead of fixing real risk. The data backs this: one 2025 report found that teams working through high alert noise took about two extra days to remediate a critical vulnerability than teams with low noise. Every hour spent sorting noise is an hour the exposure window stays open. - Breaking changes. The fix for a dependency vulnerability is most often an upgrade, and upgrades break builds. When a team cannot tell whether a version bump will take down production, the fix stalls in review while someone tests it by hand. The uncertainty, not the fix itself, is what runs up the clock. - Manual work. Every step a person does by hand adds latency: hand-triaging findings, hand-testing upgrades, hand-writing patches, hand-tracking tickets across tools. The current benchmarks show the cost. A 2026 report found the median time to resolve a vulnerability rose to 43 days. How to cut MTTR (reachability + automated remediation) Cutting MTTR is not about working faster on every finding. It is about working only on the findings that matter, and automating the fix once you know what they are. Start with reachability. Reachability analysis filters out the vulnerabilities that never run, so the team stops spending MTTR on findings that were never exploitable. Fix a hundred real risks instead of triaging ten thousand, and the average time to close each one drops, because the queue is short and every item on it is worth the work. Then automate the fix. Automated remediation compresses each stage that manual work stretches. Reachability ranks the queue, an agent generates the patch, upgrade impact analysis proves the fix will not break the build, and the change ships as a validated pull request. Each step that took a person hours takes the system minutes, and the clock stops at a verified fix, not a hopeful merge. The combination is what moves the number. A team that patches by hand fights the 40-to-55-day benchmark. A team that prioritizes by reachability and automates the deterministic fixes closes the reachable criticals in a fraction of that, which is the outcome agentic remediation delivers. Shorter MTTR is not a vanity metric. It is a smaller window for an attacker to walk through. FAQ What is mean time to remediate (MTTR)? Mean time to remediate is the average time it takes to fix a vulnerability, measured from detection to a rescan that confirms the fix. It is the core metric for how fast a security program closes real risk, and teams track it by severity to keep the average honest. How do you calculate MTTR? Divide the total remediation time by the number of vulnerabilities remediated in a period. Total remediation time is the sum of the time each vulnerability took to close, from detection to verified fix. Report the result by severity and by reachability, not as one blended number. What is a good MTTR benchmark? It depends on severity and exposure. Compliance frameworks like FedRAMP and PCI DSS set ceilings of 30 days for high-severity findings, and an aggressive target for a reachable, internet-facing critical is 48 hours. For context, industry averages for high and critical vulnerabilities ran around 43 to 55 days in 2025, well behind the roughly 15 days attackers take to weaponize a flaw. What is the difference between MTTR and MTTD? Mean time to detect (MTTD) measures how long it takes to find a vulnerability. Mean time to remediate (MTTR) measures how long it takes to fix it once found. Your real exposure window is both combined, so a program should track and cut each one. How does reachability lower MTTR? Reachability filters out the vulnerabilities that never run, which shrinks the queue to the findings that carry real risk. A shorter, higher-signal queue means the team closes each real vulnerability faster, so the average time to remediate drops without anyone working longer hours. What's next? When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: