Remediation Timeline

A remediation timeline is the defined period within which a manufacturer commits to delivering a fix for an identified vulnerability — from initial identification or validated report receipt to a security update being available to users. Remediation timelines are a component of a manufacturer's broader vulnerability handling policy and PSIRT processes. They set internal SLAs for engineering teams and provide predictability for security researchers and users who need to plan their own risk mitigation. The CRA's requirement to address vulnerabilities 'without undue delay' is intentionally vague — it does not set specific days — but regulators and standards bodies treat severity-differentiated SLA frameworks as the accepted method for demonstrating what 'without undue delay' means in practice.

Industry best practice and ISO/IEC 30111 (vulnerability handling processes) both recommend severity-differentiated remediation timelines. A typical framework:

• Critical (CVSS 9.0–10.0): Patch within 30 days; interim mitigation guidance within 5 days.
• High (CVSS 7.0–8.9): Patch within 60 days; interim guidance if exploitation is plausible.
• Medium (CVSS 4.0–6.9): Patch within 90 days, included in the next scheduled release cycle.
• Low (CVSS 0.1–3.9): Patch within 180 days or included in the next major version.
• Actively exploited (any CVSS): Treat as Critical regardless of base score; notify ENISA within 24 hours per CRA Article 14.

These SLAs should be documented in the manufacturer's PSIRT policy and published as part of the CVD policy where appropriate.

Several factors legitimately extend or compress remediation timelines:

• Root cause complexity: A vulnerability requiring architectural changes to the product's authentication model takes longer than a missing bounds check.
• Testing requirements: Safety-critical products (medical devices, industrial controllers) require extensive regression testing before any patch release.
• Update mechanism limitations: Products without over-the-air update capability may require field service interventions, dramatically extending the time between patch availability and user protection.
• Dependency on upstream vendors: When the vulnerability is in a third-party library, the manufacturer must wait for an upstream patch before they can integrate and release their own fix.
• Multi-vendor coordination: Simultaneous disclosure with other affected manufacturers requires all parties to be ready before release.

Manufacturers should document these factors in their triage records to justify timelines that extend beyond SLA targets.

Tracking remediation performance against defined SLAs enables continuous improvement and provides audit evidence for CRA compliance. Key metrics include: mean time to remediate (MTTR) by severity band; percentage of vulnerabilities remediated within SLA; percentage of vulnerabilities with interim mitigation guidance issued; and SLA miss rate with documented justifications. These metrics should be reviewed in regular PSIRT process reviews and reported to senior management as part of the product security function's accountability framework. Manufacturers with consistently high SLA miss rates for critical vulnerabilities are at elevated CRA enforcement risk and should treat this as a signal to invest in remediation capacity or process improvement.