To calculate MTTR for a vulnerability, divide the total time elapsed between vulnerability discovery and confirmed remediation by the total number of vulnerabilities remediated in that period. The result tells you, on average, how long it takes your team to close a security gap from the moment it is identified. For manufacturing operations teams, this metric is especially consequential because an unpatched vulnerability in an OT environment or connected field asset can cascade into unplanned downtime quickly.
MTTR (Mean Time to Remediate) is one of the clearest indicators of how well a security or maintenance operation is functioning. The sections below walk through how to measure it correctly, what benchmarks to aim for, and how to drive it down.
What counts as the start and end point when measuring MTTR?
The start point for MTTR is the moment a vulnerability is detected and logged, not when it is assigned or prioritized. The end point is confirmed remediation, meaning the patch, configuration fix, or compensating control has been applied and verified. Any ambiguity in these boundaries distorts your MTTR and makes benchmarking meaningless.
Getting these boundaries right matters more than most teams realize. A common mistake is starting the clock at assignment rather than detection, which hides the time lost in triage and prioritization queues. Another is stopping the clock at patch deployment rather than verified closure, which masks reopen rates.
- Start point: Timestamp of initial detection or scanner alert, whichever comes first
- End point: Verified remediation confirmed by a rescan, ticket closure with evidence, or sign-off from a responsible owner
- Exclude: Accepted-risk items and false positives, since including them inflates MTTR without reflecting real remediation work
- Include: All time in queue, including weekends and holidays, unless your SLA explicitly excludes them
In asset-heavy industrial environments, the end point often requires a field technician to physically verify a fix on equipment. That verification step is part of MTTR and should not be omitted from tracking.
What is the formula for calculating MTTR for a vulnerability?
The MTTR formula for vulnerability remediation is straightforward: MTTR = Total remediation time across all vulnerabilities / Number of vulnerabilities remediated. For example, if your team closed 50 vulnerabilities in a month and the combined time from detection to verified fix was 1,500 hours, your MTTR is 30 hours.
Apply the formula in this sequence:
- Pull every vulnerability closed within the measurement period from your tracking system
- For each item, calculate the elapsed time between detection timestamp and verified closure timestamp
- Sum all individual remediation times to get the total
- Divide by the count of vulnerabilities remediated in the same period
- Express the result in hours or days depending on the scale of your operation
Segment the calculation by severity tier (critical, high, medium, low) rather than mixing all vulnerabilities into a single figure. A blended MTTR can look acceptable on a dashboard while critical vulnerabilities are sitting open for weeks.
How does vulnerability severity affect MTTR targets?
Severity directly determines what your MTTR target should be. Critical vulnerabilities demand the shortest remediation windows because they carry the highest likelihood of exploitation and the greatest potential impact. Lower-severity findings can tolerate longer remediation cycles without a meaningful risk increase, so applying the same MTTR target across all severity levels wastes resources.
Industry practice generally maps severity to target MTTR like this:
- Critical: 24 to 48 hours from detection to remediation
- High: 7 to 14 days
- Medium: 30 days
- Low: 60 to 90 days, or managed through scheduled maintenance cycles
For manufacturing operations, severity assessment should account for asset criticality, not just the CVSS score. A medium-severity vulnerability on a production line controller that runs 24/7 is functionally more critical than a high-severity finding on an isolated administrative workstation. Risk-adjusted MTTR targets that factor in asset importance give operations leaders a more accurate picture of actual exposure.
What is a good MTTR benchmark for vulnerability remediation?
A good MTTR for critical vulnerabilities is under 48 hours. For high-severity findings, teams performing well typically close issues within 7 days. Organizations with mature security programs often achieve sub-30-day MTTR across all severity levels combined, though this varies significantly by industry, team size, and the complexity of the asset environment being protected.
Context matters when interpreting benchmarks. A 30-day blended MTTR at an organization managing thousands of OT assets across multiple plant sites is not directly comparable to the same figure at a software company with a cloud-native stack. The key is trending your own MTTR over time and comparing against your own historical baseline before looking outward.
What consistently separates high-performing teams from the rest is not the benchmark they target but the process discipline behind it: clear ownership of each vulnerability, automated detection-to-ticket workflows, and a defined escalation path when SLA windows are at risk of being missed.
How can teams reduce MTTR for vulnerabilities?
Teams reduce MTTR by eliminating the delays that occur between detection and action, not by rushing the remediation itself. The biggest time losses typically happen in handoff gaps: between the scanner and the ticketing system, between security and operations, and between patch deployment and verification. Closing those gaps has a greater impact on MTTR than increasing remediation speed.
Practical steps that consistently shorten MTTR include:
- Automate detection-to-ticket creation so no vulnerability sits in a queue waiting to be manually logged
- Pre-assign ownership by asset type or system so every finding has a responsible party from the moment it is detected
- Standardize remediation workflows by vulnerability class so technicians follow a known checklist rather than improvising each time
- Build in verification steps at the point of closure so reopens do not inflate future MTTR figures
- Review MTTR weekly at the team level, not monthly at the management level, so slow-moving items surface before they breach SLA
In environments where field technicians service connected assets, offline access to asset history and remediation checklists is a practical lever. When a technician arrives at a machine without connectivity and cannot access the work order, remediation stalls. Ensuring technicians have the right information available regardless of network conditions directly shortens the time between identification and confirmed fix.
How Gomocha Helps Reduce MTTR in Manufacturing Field Operations
Unplanned equipment downtime and slow remediation cycles cost manufacturing operators far more than the fix itself. Every hour a vulnerability or equipment fault sits unresolved is an hour of production risk, SLA exposure, and technician inefficiency. That is the operational reality our field service platform is built to address.
Here is what we bring to the table for manufacturing service teams:
- Offline-capable mobile app: Technicians access full asset history, safety documentation, and remediation checklists on the plant floor, with or without connectivity, driving a 19% improvement in first-time fix rates
- No-code Workflow Designer: Operations teams configure remediation checklists and escalation paths by asset type without waiting on IT, so the right process reaches the right technician automatically
- Guaranteed ERP integration: Native connections with AFAS and Microsoft Dynamics, plus SAP and JDE via connectors, mean detection-to-work-order handoffs happen without manual re-entry
- Purpose-built for asset-heavy industrial ops: Across 177,484 work orders and 13 customers, teams using our platform have achieved a 41% reduction in unplanned downtime
If your team is losing time between vulnerability detection and confirmed remediation, the fastest way to find where the delays are hiding is to start with an honest operational baseline. We offer an Efficiency Assessment designed specifically for industrial manufacturing teams to surface where MTTR is being inflated and what can be fixed without a lengthy implementation project. Request yours and we will show you where the hours are going.
Frequently Asked Questions
How do I handle vulnerabilities that are partially remediated or temporarily mitigated — do they count toward MTTR?
Partial remediations and compensating controls should not close the MTTR clock unless they are formally accepted as the permanent resolution with documented sign-off. If a compensating control is applied as a temporary measure — such as network segmentation while a patch is being tested — the vulnerability should remain open in your tracking system with a flag indicating interim mitigation. This prevents your MTTR from appearing artificially low while real exposure still exists.
What tools or systems should we use to track MTTR accurately across a large asset environment?
The most reliable setups combine a vulnerability scanner (such as Tenable, Rapid7, or Claroty for OT environments) with a ticketing or CMMS system that timestamps every status change automatically. The critical requirement is that detection timestamps flow directly from the scanner into the work order without manual re-entry, since manual handoffs introduce data gaps that make MTTR calculations unreliable. For manufacturing environments specifically, your field service platform should be integrated into this chain so that technician verification timestamps are captured at the point of closure, not entered retroactively.
How should we calculate MTTR when the same vulnerability affects hundreds of assets simultaneously — is it one data point or many?
Treat each affected asset as a separate remediation instance rather than rolling them into a single data point. A vulnerability affecting 200 PLCs may be remediated on 180 of them within 24 hours and sit open on 20 others for two weeks due to access scheduling — a blended single figure would hide that tail risk entirely. Tracking per-asset closure gives you an accurate distribution and surfaces which asset types or plant locations are consistently slower to remediate.
What are the most common mistakes teams make when first starting to measure MTTR?
The three most common mistakes are: starting the clock at ticket assignment rather than detection (which hides triage delay), including accepted-risk and false-positive items in the denominator (which inflates the count and artificially lowers MTTR), and measuring a single blended MTTR across all severity levels (which can mask critically slow closure rates on high-severity findings). The fastest way to get a reliable baseline is to fix the detection-to-log timestamp first, then segment by severity — everything else can be refined from there.
How often should we review and report on MTTR, and who should own it?
MTTR should be reviewed weekly at the team or supervisor level and reported monthly to operations and security leadership. Weekly reviews are what actually move the metric — they surface items approaching SLA breach while there is still time to act, whereas monthly reviews only confirm what already went wrong. Ownership should sit with the team responsible for remediation execution, not the team that detects vulnerabilities, since MTTR is fundamentally a measure of response speed and process discipline rather than detection capability.
Can MTTR be used as a technician performance metric, or is that the wrong way to apply it?
MTTR is best used as a process and system metric rather than an individual performance metric. Most of the time embedded in MTTR accumulates in queues, handoff gaps, and scheduling delays — factors largely outside a technician’s control. Using it to evaluate individual technicians can incentivize rushing verifications or marking items closed prematurely, both of which inflate reopen rates and ultimately worsen MTTR over time. The right application is to use it to identify where the process is breaking down, then improve the system those technicians work within.
How do planned maintenance windows affect MTTR in OT and manufacturing environments, and should downtime windows be excluded from the calculation?
Planned maintenance windows are a genuine constraint in OT environments and should be accounted for in your SLA definitions rather than excluded from MTTR calculations. If a patch requires a production line shutdown and the next available window is 10 days out, that wait time is real exposure time and should remain in the MTTR figure — it reflects the operational cost of the remediation, which is exactly what the metric is meant to capture. The appropriate response is to set severity-specific MTTR targets that are realistic given your maintenance cadence, and to flag vulnerabilities awaiting a maintenance window separately so leadership understands the reason for the extended timeline.