Mean Time to Remediate (MTTR)

Mean Time to Remediate (MTTR) is a metric that quantifies the average time between a security vulnerability being identified and a fix being deployed to all affected systems or users. MTTR can be measured at multiple points: from vulnerability identification to patch available (development MTTR); from patch available to patch deployed in production (deployment MTTR); or end-to-end from identification to full fleet remediation. In the context of CRA manufacturer obligations, MTTR primarily refers to the time from vulnerability identification (through CVD report, CVE disclosure, or internal discovery) to security update being available to users. Deployment MTTR is largely outside the manufacturer's control — it depends on users' patching practices — but publishing security updates promptly is the manufacturer's obligation.

The CRA requires manufacturers to address vulnerabilities 'without undue delay'. MTTR is the primary quantitative measure of how well a manufacturer meets this obligation. Industry benchmarks and ENISA guidance provide reference points:

• Critical (CVSS 9.0–10.0): Target MTTR of 30 days or fewer for patch availability. Interim mitigation guidance within 5 days.
• High (CVSS 7.0–8.9): Target MTTR of 60 days for patch availability.
• Medium (CVSS 4.0–6.9): Target MTTR of 90 days, includable in planned release cycles.
• Actively exploited (any severity): Emergency response — patch or mitigation guidance within days; ENISA notification within 24 hours of confirmed exploitation.

Manufacturers should track MTTR by severity band and review it regularly. A consistent trend of exceeding SLA targets is an early warning of a compliance risk and a process capacity issue.

MTTR is influenced by multiple factors across the vulnerability handling workflow:

• Triage speed: Slow triage (days to validate and score a vulnerability) delays the start of remediation. Automated SBOM-based CVE correlation reduces triage time for known CVEs.
• Development process: A development team that can context-switch to security patches quickly has lower MTTR. Teams with rigid sprint structures and no emergency patch capacity have higher MTTR for critical vulnerabilities.
• Testing requirements: Safety-critical products with extensive regression testing requirements have structurally higher MTTR due to test cycle length. This should be reflected in the PSIRT SLA — a longer target MTTR for these products is legitimate if justified by testing constraints.
• Build and release automation: Manual build and release processes add days to MTTR. CI/CD automation that enables rapid emergency releases significantly reduces MTTR.
• OTA update infrastructure: Products with OTA capability have lower effective MTTR (from user's perspective) than products requiring manual update procedures.

To measure and improve MTTR, manufacturers need:

• Tracking system: A vulnerability case management system (PSIRT ticketing) that records the date of identification, date of fix availability, and date of advisory publication for each vulnerability.
• Reporting: Regular MTTR reports by severity band, ideally reviewed in monthly PSIRT performance reviews and reported to senior management quarterly.
• Root cause analysis: For SLA misses, conduct root cause analysis — was the miss due to triage delays, development capacity constraints, testing cycle length, or release process bottlenecks? Different root causes require different remediation investments.
• Trend tracking: Track MTTR trends over time. An increasing MTTR trend despite constant vulnerability volume suggests process degradation. A decreasing trend demonstrates continuous improvement.

CVD Portal tracks MTTR automatically from intake to advisory publication, providing the reporting data needed for CRA compliance evidence.