Why MTTR Stays High, And How Exposure-Centric Security Finally Changes That
Enterprise MTTR has barely moved in a decade, still 60 to 100 days for critical vulnerabilities despite record tool spend. The bottleneck isn't detection or prioritization. It's the manual coordination behind every fix.
TL;DR
- Mean time to remediation (MTTR) in cybersecurity has barely moved in a decade despite massive tool investment. Enterprise MTTR still sits between 60 and 100 days for critical vulnerabilities.
- The bottleneck isn't detection or even prioritization - it's manual coordination. Ownership discovery, remediation design, and validation are all done by hand, at scale, for every finding.
- Decision-Based Exposure Management structurally eliminates the repetitive steps that inflate MTTR - encoding human decisions once and executing them at machine speed across every matching pattern.
Ask any CISO what keeps them up at night and MTTR will surface quickly - not because they don't understand the metric, but because they can't move it. They've bought the scanners, deployed the dashboards, run the remediation sprints. And yet mean time to remediation stays stubbornly measured in weeks or months.
That gap between investment and outcome is not an accident. It's the inevitable result of optimizing a manual process at the margins rather than rethinking the process itself.
At Onit Security, we've spent the last year working directly with security teams across industries on exactly this problem. What we've found consistently is that MTTR doesn't stay high because teams aren't trying hard enough. It stays high because the architecture of how remediation work gets done is fundamentally broken, and no amount of faster task execution fixes a broken architecture.
MTTR doesn't stay high because teams aren't trying. It stays high because the architecture of how remediation work gets done is broken.
This article is about what actually drives MTTR, what exposure-centric security operations look like when it's working, and how the shift from task-based to decision-based execution changes the math entirely.
What Actually Keeps MTTR So High
When we engage with new customers, one of the first things we do is map the actual lifecycle of a finding from initial detection to validated remediation. In almost every case, the time spent on
resolution is a small fraction of total MTTR. The overwhelming majority of elapsed time is consumed by three things:
Ownership discovery. As we've written about in the context of exposure management broadly, identifying who has authority to approve remediation for a given asset can take days or weeks in a large enterprise. CMDB data is stale. Org structures don't reflect operational reality. The right person has to be found, contacted, and re-educated about the finding before remediation can even begin.
Resolution design. Patching is not always possible. When it isn't - because of downtime constraints, production dependencies, or compatibility issues - someone has to design a compensating control. That means evaluating firewall rules, endpoint agent configurations, or network segmentation changes, and confirming they actually reduce risk without creating new problems. This is skilled work. It takes time. And it happens manually for each finding.
Validation. After remediation is executed, someone has to confirm it worked - that the vulnerability is genuinely resolved, that the compensating control is active and effective, and that the risk has actually decreased. Without validation, MTTR numbers are meaningless: you're measuring ticket closure, not risk reduction.
None of these steps get faster by adding more analysts. They get faster by eliminating the need to repeat them for every finding. That's the structural insight at the core of how we build Onit Security.
Structural MTTR Reduction vs Accelerating Tasks: An Important Distinction
There's a meaningful difference between making a broken process faster and replacing it with a better one.
Most exposure management software on the market today - including the generation of tools built on top of legacy vulnerability management platforms - accelerates tasks. Better prioritization means faster triage. Integrated ticketing means less context-switching. Workflow automation means ownership assignments route more quickly. Each of these improvements is real, and each delivers incremental MTTR reduction.
But the bottleneck is not speed. It's repetition.
Consider a specific vulnerability family - say, an outdated TLS configuration - appearing across hundreds of similar assets with a consistent ownership profile and a known remediation path. In a task-based model, each instance generates its own investigation, its own ownership resolution, its own remediation ticket, its own validation step. Automating each of those individual steps faster still means doing them hundreds of times.
Decision-Based Exposure Management takes a different approach: identify the pattern, surface it to a human analyst for a single decision, encode that decision, and execute it via agents across every matching instance simultaneously. Concretely: one decision about how to handle a class of exposures, for example "deploy this WAF rule whenever TLS 1.0 shows up on an internet-facing asset," closes every matching instance the moment it's encoded, not just the finding that prompted it. A single decision resolves thousands of exposures instead of generating thousands of tickets. The first occurrence takes human time. The second doesn't. By the hundredth, the cumulative time savings are enormous, and the organizational knowledge embedded in that decision has been preserved and is compounding.
Accelerating tasks reduces MTTR incrementally. Eliminating repetition reduces it structurally. Only one of those changes the economics of security operations.
This is why we believe the correct framing isn't "how do we patch faster" but "how do we make good decisions once and execute them everywhere." The unit of progress isn't the task. It's the decision.
Autonomous Resolution: Where We Are and Where We're Headed
Autonomous resolution is a question we get asked about constantly, and the answer requires more nuance than the technology press typically allows.
The analogy we find most useful: think about how Cursor changed the relationship between engineers and code. Engineers used to write every line themselves. Now they mostly govern agents that do the work, stepping in for judgment calls and architectural decisions rather than typing every function by hand. Security is on the same trajectory, just on a slightly longer timeline.
Today, roughly 90% of the resolution lifecycle can be automated. Agents handle context aggregation, ownership discovery, exploitability validation, and remediation proposal generation. What remains in human hands are the authorization checkpoints - the moments where a proposed action could cause business disruption comparable to or greater than the risk being addressed.
That boundary matters. A firewall rule that accidentally blocks legitimate business traffic is not a minor inconvenience - in some environments, it's more damaging than the vulnerability it was meant to address. A patch that breaks a production dependency can take down a revenue-generating system. Until trust in agentic validation controls is fully established for a given class of change, human authorization at those checkpoints is not a limitation - it's sound risk management.
90% of the resolution lifecycle can be automated today. The remaining 10% is not a technical problem - it's a trust problem. And trust is earned through demonstrated accuracy, not assumed.
How we're addressing the trust problem: every action our agents take is validated against discrete, verifiable checks - not just the agent's own reasoning. Exploitability assessments are cross-validated against authoritative sources. Remediation proposals are checked for dependency conflicts before being presented for human approval. The goal is to earn the right to expand autonomy incrementally, action class by action class, as confidence in the validation layer grows.
Our expectation, and we believe this is realistic within 6 to 12 months for most enterprise environments, is that the authorization checkpoints will become narrower and the autonomous execution layer will expand significantly. The teams that build trust in agentic infrastructure now will be positioned to capture that capability when it's available.
Where Automation Belongs - and Where Humans Must Stay in Command
That trust boundary, the one we just described between automated and human-authorized action, is where the decision-based model does its heaviest lifting. The question of human vs. machine authority in remediation is not binary, and treating it as such leads to both under-automation (because "it's too risky to let agents act") and over-automation (because "the agents are accurate enough now").
Our framework at Onit Security divides the remediation lifecycle into two zones:
Automation owns: context aggregation across fragmented data sources; exploitability validation using discrete verification against known exploit databases and environmental controls; ownership graph construction from CMDB, IAM, and organizational data; resolution proposal generation based on encoded decision patterns; execution of low-impact, high-confidence changes (configuration updates, agent policy adjustments, non-production environment patching); and post-remediation validation that risk actually decreased.
Humans authorize: any resolution action whose failure mode could cause business disruption; changes to network segmentation or firewall rules in production environments; patches with known compatibility risks; and any action class not yet covered by an established, validated decision pattern. Over time, as decision patterns accumulate and validation accuracy compounds, more action classes move from the human authorization zone into the automation zone.
The practical implication: a security analyst using our platform today doesn't spend their day investigating findings. They spend it reviewing a small set of high-stakes decisions that agents have prepared for their authorization. Everything else - the research, the ownership resolution, the remediation design, the execution, the validation - happens without them having to touch it.
That is what MTTR reduction in practice actually looks like. Not faster triage. Not better dashboards. Fewer human hours per finding, because fewer human hours are required.
If You Want to Cut MTTR in Half in 12 Months: A Practical Framework
We get asked this directly by CISOs evaluating Onit Security, so we'll answer it directly here.
Cutting MTTR in half within 12 months requires movement on all three dimensions - tools, mindset, and process - but not in equal measure and not in any order.
Start with tooling. The agentic retooling wave is real and it's happening now across every security domain. You cannot build a decision-based remediation model on top of a legacy task-management platform - the architecture doesn't support it. The first 90 days should be focused on standing up infrastructure capable of capturing decisions, executing them via agents, and tracking MTTR from detection to validated resolution. Without that foundation, the mindset and process changes have nowhere to land.
Then shift mindset. The security leaders who are most effective at this transition are the ones who reframe their team's job description: from "process every finding" to "govern the decisions that determine how every finding gets processed." That's a meaningful psychological shift for experienced analysts who are used to being in the weeds. It requires deliberate reinforcement - new metrics, new reporting cadences, new definitions of what a productive day looks like.
Finally, adapt the process. Don't try to automate existing workflows - redesign them around agentic execution. The question to ask at every step is not "how do we do this faster?" but "does a human need to be involved in this step at all, and if so, at what point exactly?" Processes built around that question look fundamentally different from processes that were built for manual execution and then had automation bolted on.
The organizations we've seen make the most progress fastest are the ones that resist the urge to run the new model in parallel with the old one indefinitely. At some point, you have to commit to the new architecture. The teams that do that earliest gain the most. That commitment also changes what you should expect to be measuring a few years from now, which is worth addressing directly.
Will MTTR Still Be the Right Metric Five Years From Now?
Probably not - at least not in its current form.
MTTR is a useful proxy for remediation velocity, but it's still a process metric rather than a risk metric. It tells you how fast you resolved findings; it doesn't tell you which findings actually mattered to the business, or whether resolving them moved the needle on your actual threat exposure.
Five years ago, the primary challenge in cybersecurity was visibility: organizations didn't know what was running on their networks or where their exposures were. That problem has been largely solved. Today, the challenge is execution at scale. Five years from now, the challenge will be something different again, assuming the trajectory of AI-native security operations continues. We believe it will, and at a pace most people are underestimating.
Our expectation is that as agentic infrastructure matures, the interesting metrics won't be about remediation speed at all. They'll be about continuous posture - what percentage of exposures never became dwell-time risks because they were addressed before exploit availability; what the organization's actual residual risk profile looks like in business terms; and how that profile changes in real time as the threat landscape evolves.
MTTR measures how fast you close the gap after it opens. The real goal is a posture where the gap rarely opens at all.
That's the trajectory we're building toward at Onit Security. Not faster remediation of an endless backlog, but a model where the backlog itself becomes structurally smaller because decisions compound, agents execute, and exposure windows shrink before attackers can exploit them.
Cybersecurity five years from now will look fundamentally different from today. The teams that start building toward that model now - encoding decisions, deploying agents, and measuring risk reduction rather than activity - will be the ones best positioned when the pace of change accelerates further.
Frequently asked questions
Mean time to remediation measures the average time from when a vulnerability or security finding is identified to when it is confirmed as resolved. In cybersecurity, this spans the full lifecycle: detection, triage, ownership assignment, remediation execution, and validation that risk actually decreased. Industry benchmarks from Ponemon and Tenable place enterprise MTTR between 60 and 100 days for critical vulnerabilities - a number that has barely improved despite a decade of security tool investment.
Because the root bottleneck is manual coordination, not tool coverage. Confirming exploitability, locating the right asset owner across fragmented systems, designing a remediation that doesn't break production dependencies, and validating the fix are all done manually at scale. Adding more tooling makes this pipeline slightly faster - it does not eliminate the pipeline. MTTR drops structurally only when recurring decisions are encoded and agents execute them automatically.
Exposure-centric security operations measures effectiveness by actual risk reduction rather than detection volume or patch counts. Instead of asking how many vulnerabilities were found or tickets closed, it asks: how quickly did we reduce real business risk, and can we prove it? This requires connecting vulnerability findings to asset criticality, business process dependencies, and organizational ownership - translating raw CVE data into business-level risk that CISOs can defend to their boards.
Accelerating tasks means doing the same manual steps faster - quicker triage, faster ticket routing, more efficient patching. MTTR improves incrementally. Structural MTTR reduction eliminates the repetitive steps entirely: decisions about how to handle recurring vulnerability patterns are encoded once, and agents execute those decisions automatically. The hundredth instance of a pattern takes the same time as the first - close to zero human hours.
Human authorization should remain at any point where an automated action could cause business disruption equal to or greater than the risk of the vulnerability itself. A firewall rule that blocks legitimate business traffic, or a patch that breaks a production dependency, can be more damaging than the exposure being fixed. Until trust in agentic validation controls is fully established for a given action class, humans should authorize high-impact steps. Agents handle everything upstream: context aggregation, ownership discovery, exploitability validation, and remediation proposal generation.
Start with tooling: retool toward agentic, AI-native exposure management software capable of capturing decisions and executing them at scale. Then shift mindset: reframe the security team's job from processing every finding to governing the decisions that determine how findings are handled. Finally, redesign processes around agentic execution rather than retrofitting automation onto legacy manual workflows. Tooling creates the foundation; mindset and process changes determine how much of that capability actually gets captured.
Onit Security is building the agentic platform that makes exposure-centric security operations real. If you want to see how Decision-Based Exposure Management reduces MTTR in practice, we'll show you exactly what that looks like in your environment.