CRA update timing is therefore risk-based. A remotely exploitable or actively exploited vulnerability can demand much faster action than a low-exposure issue requiring unusual prerequisites. Internal remediation targets can operationalise that urgency, but they should not be presented as universal statutory CRA patch deadlines.
The CRA Does Not Set One Universal Patch Deadline
The Cyber Resilience Act does not set one universal patch deadline that applies identically to every vulnerability. Annex I Part II point 2 requires manufacturers, in relation to the risks posed to their products, to address and remediate vulnerabilities without delay. The wording combines urgency with product-specific risk. Manufacturers therefore need a prioritisation method capable of distinguishing an urgent exposed vulnerability from a lower-risk finding without inventing a fixed statutory number of days.
- Do not invent a universal CRA patch deadline.
- Assess product-specific risk.
- Assign remediation urgency.
- Record the rationale.
Without Delay Applies to Addressing and Remediating Vulnerabilities
Point 2 uses the phrase without delay for addressing and remediating vulnerabilities. That requires manufacturers to move a confirmed vulnerability through assessment and remediation with urgency proportionate to the risks posed. A process that simply places every vulnerability into an ordinary product backlog without security prioritisation can conflict with that objective. The case should have an owner, priority and path toward mitigation or permanent remediation.
- Assign vulnerability ownership.
- Assess the risks posed.
- Define remediation action.
- Escalate high-risk cases.
Secure Distribution Must Support Timely Remediation
Annex I Part II point 7 requires secure update mechanisms that ensure vulnerabilities are fixed or mitigated in a timely manner. This means update infrastructure should not become an avoidable bottleneck after a correction is ready. Manufacturers should consider signing capacity, release approval, package generation, distribution capacity and product-update behaviour when designing an emergency security release path.
- Maintain a secure release path.
- Avoid unnecessary signing or publication bottlenecks.
- Prepare for emergency security releases.
- Test the update path before a crisis.
Once a Security Update Is Available, Dissemination Must Not Be Delayed
Annex I Part II point 8 addresses a later stage in the lifecycle. Once a security update is available to address an identified security issue, it must be disseminated without delay. This is different from the time needed to investigate and develop the correction. A manufacturer should therefore distinguish remediation time from dissemination time and avoid leaving a completed security update unpublished because an unrelated feature release or marketing schedule has not yet arrived.
- Distinguish fix development from dissemination.
- Publish completed security updates promptly.
- Avoid unrelated feature-release delays.
- Record the release timestamp.
Risk Should Drive Operational Urgency
Risk-based timing can consider technical impact, exploitability, exposure, attack prerequisites, affected supported versions and available mitigation. A vulnerability allowing unauthenticated remote compromise of a default-enabled service can justify much faster action than a flaw requiring physical access and an uncommon configuration. The priority should be reassessed as new evidence changes the risk picture.
- Assess impact.
- Assess exploitability.
- Assess exposure.
- Assess affected versions.
- Reassess when new evidence appears.
Active Exploitation Can Change the Priority Immediately
Evidence of active exploitation is an especially important escalation factor. The manufacturer should reassess remediation urgency and separately evaluate Article 14 reporting obligations. Where exploitation is occurring, mitigation and permanent remediation may need parallel work, and ordinary feature-release schedules may be inappropriate. Active exploitation does not create a universal statutory patch duration, but it can materially change what acting without delay means for the product.
- Escalate exploitation evidence.
- Assess Article 14.
- Deploy effective mitigation where necessary.
- Accelerate permanent remediation.
Article 14 Reporting Deadlines Are Not Patch Deadlines
Article 14 reporting deadlines should not be confused with vulnerability-remediation deadlines. The CRA reporting framework includes time limits such as the early warning and subsequent notification stages for qualifying actively exploited vulnerabilities and severe incidents. Those are regulatory notification deadlines. They do not mean every vulnerability must be patched within the same number of hours. Reporting, investigation, mitigation and remediation can proceed in parallel.
- Keep regulatory reporting separate from patch timing.
- Preserve the awareness timeline.
- Continue remediation while reporting.
- Do not convert reporting deadlines into invented patch deadlines.
Internal Remediation Targets Can Make Without Delay Operational
Manufacturers can define internal remediation targets for vulnerability-priority categories. For example, an organisation may use shorter operational targets for actively exploited or remotely exploitable high-impact vulnerabilities and longer targets for lower-risk findings. Internal remediation targets are useful controls, but they remain organisational rules unless a particular legal provision creates a specific statutory deadline. They should not be marketed as universal CRA patch deadlines.
- Define risk-based priority categories.
- Assign internal remediation targets.
- Escalate missed targets.
- Keep internal SLAs distinct from legal deadlines.
Mitigation Can Reduce Immediate Risk While a Fix Is Developed
A permanent security update can require development and testing time. Where immediate remediation is not technically possible, a validated mitigation can reduce exposure while the permanent fix is prepared. Examples can include disabling a vulnerable interface, restricting network access or changing configuration. Mitigation should be tested and communicated appropriately, and it should not silently replace permanent remediation where the underlying vulnerability remains.
- Identify effective mitigations.
- Verify their effectiveness.
- Communicate required user action.
- Continue permanent remediation.
Testing Must Be Proportionate but Real
Urgency does not eliminate the need to verify a security update. The manufacturer should test that the vulnerable condition is corrected and that the update can be installed securely. For an urgent case, the test plan may be focused and expedited, followed by additional regression work, but releasing an unverified update that creates another serious security failure can undermine the remediation objective.
- Verify the original vulnerability is addressed.
- Check critical regression paths.
- Test update installation.
- Document expedited testing decisions.
Keep Timing Evidence in the Vulnerability Case
The case record should preserve important timestamps such as report receipt, validation, priority decision, remediation completion, verification and security-update release. It should also document significant delays and mitigations. This allows the manufacturer to explain how it interpreted the risk-based without-delay requirement and whether an available security update was disseminated promptly.
- Receipt timestamp.
- Validation timestamp.
- Priority decision.
- Remediation completion.
- Security-update release.
- Delay rationale where relevant.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.