To reduce MTTR for critical vulnerabilities, cut the time a finding spends waiting, not the time an engineer spends typing the fix. Most critical findings sit for days in three queues: waiting to be triaged, waiting for an owner, and waiting for a pull request someone trusts enough to merge. Shrink those queues by triaging on reachability and exploitability instead of raw severity, routing each finding to the person who owns the code, and handing them a validated fix instead of a ticket.
This guide explains what critical MTTR measures, where the time actually goes, and seven practical steps to bring it down.
What is MTTR for critical vulnerabilities?
Mean time to remediate (MTTR) is the average time between a vulnerability being found and that vulnerability being fixed. "Critical MTTR" is the same metric filtered to the findings your program treats as critical.
The formula is simple:
MTTR = total time from detection to fix, across all remediated findings ÷ number of remediated findings
Two definitions decide whether the number means anything:
- When the clock starts. Detection time (when a scanner first reported it) is the honest choice. Starting the clock at triage or ticket creation hides the slowest queue.
- What "remediated" means. A merged fix that's deployed is remediation. A closed ticket, a suppressed alert or an accepted risk is not, so track those separately.
MTTR has other expansions in operations (mean time to repair, recover, respond or resolve). For how it relates to reliability metrics such as MTBF, see MTTR vs MTBF.
Why critical MTTR matters
A critical vulnerability is only dangerous while it's open. MTTR is the closest single number to "how long are we exposed when it counts."
It's also the number regulators and customers now ask about. In June 2026, CISA issued Binding Operational Directive 26-04, which replaced the old fixed deadlines of BOD 22-01 for federal agencies with risk-based remediation timelines. Urgency is set by four factors: whether the asset is publicly exposed, whether the CVE is in the Known Exploited Vulnerabilities catalog, whether exploitation can be fully automated, and how much control exploitation gives an attacker.
That's a useful model even if you're not a federal agency. It says the deadline should depend on real-world risk, not on a severity label.
Where the time goes in critical remediation
Writing the fix for most critical findings takes minutes to hours. The rest of the MTTR clock runs while the finding waits.
Waiting to be triaged
A scanner reports a critical. Someone on the security team has to decide whether it's real, whether the code runs in production, and whether an attacker can reach it. When scanners are noisy, that queue grows faster than the team can drain it. In one study across five Nullify production tenants, 57% of 14,847 SAST findings triaged over 90 days were ultimately classified as false positives. Every one of those had to be looked at before the real criticals could be found.
Waiting for an owner
Once a finding is confirmed, it needs a person. If routing means "file a ticket in the platform team's backlog," the finding waits for sprint planning, then for someone to recognize the code, then for them to ask who actually wrote it.
Waiting for a fix someone trusts
The owner now has to understand the vulnerability, write a fix, make sure it doesn't break anything, and get it reviewed. If the security advice is generic ("sanitize user input"), they start from scratch. If the fix breaks the build, it bounces.
Waiting for merge and deploy
A correct pull request can still sit unreviewed for days, especially if no one is accountable for chasing it.
How to reduce MTTR for critical vulnerabilities
Each step below removes one of those waits. None of them requires a specific tool.
1. Define "critical" by exploitability, not only by CVSS
CVSS describes the theoretical impact of a vulnerability class. It doesn't know whether the vulnerable function is reachable from the internet in your deployment. If every CVSS 9.0+ finding is a critical, your critical queue fills with findings in test fixtures, dead code and internal-only services.
Use a short set of questions, similar to the BOD 26-04 factors:
- Is the vulnerable code reachable from untrusted input?
- Is the asset exposed to the internet?
- Is the vulnerability known to be exploited, or is there public exploit code?
- What does an attacker get if it works?
A smaller, truer critical queue has a lower MTTR almost by definition, and the team trusts it.
2. Triage automatically, and keep the evidence
Manual triage is the biggest queue. Automate the first pass: reachability analysis, filtering of test-only and unreachable code, and checks against exploited-vulnerability lists. Record why each finding was kept or dismissed, so a reviewer can audit the decision instead of redoing it.
3. Route to the code owner, not to a team backlog
The fastest person to fix a vulnerability is the one who wrote or owns the code. Route using the commit author first, then CODEOWNERS, then the wider team. Respect their current workload, because a fifth urgent ticket on one engineer's plate doesn't move faster than the first.
4. Hand over a fix, not a description
A finding that arrives as a pull request with a minimal, root-cause fix gets merged faster than a ticket that says "this endpoint is vulnerable to SSRF." The fix should:
- Close the vulnerability at its root cause, not suppress the symptom.
- Pass the existing build and tests before anyone is asked to review it.
- Explain itself: what was wrong, how it was exploitable, and what changed.
Keep a human approving every merge. Speed that comes from skipping review just moves the risk somewhere else.
5. Set SLAs by risk tier and escalate automatically
Set a target remediation time for each risk tier and measure against it. When a critical fix stalls, escalate to the owner and their lead in the channel they actually read, with the risk and the deadline stated. Escalation that depends on someone remembering to check a dashboard doesn't happen consistently.
6. Fix classes of vulnerability in campaigns
If the same critical shows up across 40 repositories (a vulnerable dependency, a leaked secret pattern, an unsafe deserialization helper), treat it as one campaign with one owner and a progress count, not 40 separate tickets. Campaigns cut MTTR for the whole class and stop the long tail of forgotten repos.
7. Catch criticals in the pull request
The cheapest critical to remediate is the one that never merges. Scanning every pull request means the author fixes the issue while the code is still fresh in their head, and the finding never enters the backlog at all.
Common mistakes that make MTTR look better than it is
- Starting the clock late. Measuring from ticket creation instead of detection hides triage time.
- Counting suppressions as fixes. Closing a finding as "won't fix" or "accepted risk" lowers MTTR without lowering risk. Report those separately.
- Using the mean alone. One finding open for a year can hide behind fifty fixed in a day, and the reverse is also true. Report the median and the 90th percentile next to the mean.
- Ignoring the open backlog. MTTR only counts findings that were fixed. Track the age of open criticals too, or old findings simply disappear from the metric.
- Comparing teams on raw MTTR. Teams with harder code or older stacks will look worse. Compare each team against its own trend.
Critical MTTR checklist
Use this to audit your current process:
- The MTTR clock starts at first detection.
- "Critical" accounts for reachability, exposure and known exploitation.
- Unreachable and test-only findings are filtered before a person sees them, with the reason recorded.
- Findings route to the commit author or code owner automatically.
- Fixes arrive as pull requests that already pass the build and tests.
- A human approves every merge.
- SLAs exist per risk tier, with automatic escalation in Slack or email.
- Recurring vulnerability classes are handled as campaigns.
- Mean, median, 90th percentile and open-critical age are all reported.
- Every pull request is scanned before merge.
How Nullify reduces MTTR for critical vulnerabilities
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 itself, 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: your engineers approve every change. Stalled security PRs are escalated through Slack with the risk and SLA stated, and MTTR and SLA compliance are reported per team. See how it works on the triage and remediation page.
Frequently asked questions
What is a good MTTR for critical vulnerabilities?
There isn't one universal number. A good target depends on exposure and exploitability: an internet-facing, actively exploited critical needs days at most, while a critical in an internal service with no known exploit can take longer. Set targets per risk tier and track your own trend against them.
What's the difference between MTTR and MTTD in security?
Mean time to detect (MTTD) measures how long a vulnerability or threat exists before you find it. MTTR measures how long it takes to fix it once found. Together they describe your total exposure window.
Does reducing MTTR mean skipping code review?
No. Most remediation time is spent waiting for triage, an owner and a trustworthy fix. Remove those waits and keep human review on every merge.
Should accepted risks count toward MTTR?
No. Accepted risks, suppressions and "won't fix" decisions should be reported separately. Counting them as remediations makes MTTR fall while exposure stays the same.
How do you calculate MTTR for vulnerabilities?
Add up the time from first detection to deployed fix for every remediated finding in the period, then divide by the number of remediated findings. Report the median and 90th percentile alongside the mean.
