Security-fix priority answers an operational question: which vulnerability should the manufacturer act on first and how urgently? The answer should reflect actual product risk rather than simply sorting a spreadsheet by one severity score.
The CRA Uses Risk-Based Urgency
Annex I Part II point 2 requires manufacturers, in relation to the risks posed to products with digital elements, to address and remediate vulnerabilities without delay, including by providing security updates. The Regulation does not assign one universal number of days to every vulnerability. Manufacturers therefore need a repeatable priority process that translates product risk into remediation urgency and records why one issue was handled ahead of another.
- Assess the risks posed to the product.
- Assign remediation urgency.
- Record the priority rationale.
- Reassess when new evidence emerges.
Start With Severity but Do Not Stop There
Severity provides an important description of technical consequences, but it does not always determine which fix should ship first. A high-severity weakness that requires physical access and an unusual configuration can present less immediate exposure than a moderate vulnerability reachable from the internet without authentication. The manufacturer should therefore combine severity with operational context rather than use one rating as the entire prioritisation rule.
- Use severity as an input.
- Add product context.
- Consider attack prerequisites.
- Document exceptions to ordinary priority rules.
Exploitability Can Increase Urgency
A vulnerability that can be reliably exploited under practical operational conditions can deserve higher remediation priority than one requiring unrealistic prerequisites. Teams should assess whether public exploit code exists, whether exploitation is technically simple, which privileges are required and whether an attacker can reach the vulnerable function. Exploitability should be reassessed when new proof-of-concept material or threat intelligence appears.
- Assess practical exploitability.
- Review attack prerequisites.
- Monitor new exploit information.
- Reassess after proof-of-concept publication.
Active Exploitation Should Trigger Immediate Escalation
Reliable evidence that a malicious actor is exploiting a vulnerability changes the operational situation. The case should receive immediate product-security and Article 14 assessment, and remediation or mitigation work should be escalated. Active exploitation can justify moving a vulnerability ahead of higher-scored issues that are not currently exposed to real attacks. Regulatory reporting and fix development should run in parallel where Article 14 applies.
- Escalate evidence of active exploitation.
- Assess Article 14 immediately.
- Accelerate remediation or mitigation.
- Preserve awareness and decision timestamps.
Consider Exposure and Attack Surface
Priority should reflect whether attackers can reach the vulnerable function. Internet-facing services, remotely reachable management interfaces and functionality enabled by default can increase urgency. Vulnerabilities reachable only after local privileged access or through disabled optional functionality may have lower immediate exposure, although the underlying weakness can still require remediation. Exposure should be assessed using real product configurations and foreseeable use.
- Review internet exposure.
- Review default configuration.
- Review privileged interfaces.
- Review foreseeable deployment environments.
Identify Which Supported Versions Are Affected
A remediation decision should identify every affected supported version. The vulnerability may require several fixes, backports or platform-specific update packages. Article 13 requires vulnerabilities to be handled effectively throughout the support period, so supported branches should remain visible even if most customers have moved to a newer release. Product usage and deployment scale can also affect how urgently different branches need remediation.
- Identify affected supported versions.
- Identify required backports.
- Identify platform-specific fixes.
- Connect each fix to the support-period status.
Evaluate Potential Impact on Users and Systems
Priority should reflect the consequences of successful exploitation in the actual product environment. Compromise of an authentication boundary, update mechanism or high-privilege management function can justify urgent action because one vulnerability may undermine several security controls. Availability impact can also be critical where the product supports essential operational functions. Teams should record the affected security properties and realistic downstream consequences.
- Assess confidentiality impact.
- Assess integrity impact.
- Assess availability impact.
- Assess privilege and control impact.
Verify Compensating Controls Before Reducing Priority
A mitigation or compensating control can reduce immediate risk while a permanent fix is developed. Examples can include disabling a vulnerable function, restricting network access, changing configuration or applying an external filtering rule. The control should be tested against the actual attack path before the vulnerability is given lower remediation priority. A theoretical control that customers do not have enabled should not be treated as effective mitigation.
- Identify available mitigations.
- Verify effectiveness.
- Determine whether users can deploy them.
- Keep permanent remediation visible.
Distinguish Mitigation From Remediation
Mitigation reduces the likelihood or impact of exploitation without necessarily removing the vulnerable condition. Remediation addresses the underlying vulnerability. Temporary mitigations can be important when an urgent permanent fix is not yet ready, but the vulnerability case should make the distinction explicit. A case should not be marked fully remediated merely because one deployment workaround exists.
- Record mitigation separately.
- Record permanent remediation.
- Track residual risk.
- Retest after the permanent fix.
Consider the Time Needed to Build and Verify the Fix
Remediation complexity should inform execution planning without becoming an excuse for indefinite delay. A small configuration correction may be deployable quickly, while a vulnerability in a protocol or hardware component can require architectural changes and extensive regression testing. High-risk cases with complex fixes may need interim mitigation, additional engineering resources or a staged update strategy so users are not left exposed while the permanent correction is developed.
- Estimate fix complexity.
- Identify verification requirements.
- Use interim mitigation where necessary.
- Allocate resources according to risk.
Do Not Let Functionality Releases Delay Security Fixes
Annex I Part II point 2 states that where technically feasible, new security updates should be provided separately from functionality updates. Product teams should therefore avoid allowing an urgent security correction to wait for an unrelated feature release merely because both changes normally use the same release train. The remediation workflow should support security-only releases when the technical architecture permits them.
- Separate security updates where technically feasible.
- Avoid unnecessary feature-release dependency.
- Maintain an emergency security release path.
- Test the security-only update process.
Use Priority Targets as Internal Controls, Not Invented CRA Deadlines
Manufacturers can define internal remediation targets for priority categories to make operations predictable. Those targets can be stricter for remotely exploitable or actively exploited vulnerabilities and longer for lower-risk issues. Internal targets should be described as organisational controls rather than statutory CRA deadlines unless a specific legal reporting or other regulatory deadline actually applies. The legal requirement remains risk-based remediation without delay.
- Define internal priority categories.
- Define operational target times.
- Escalate missed targets.
- Do not mislabel internal SLAs as CRA deadlines.
Record the Priority Decision and Reassess It
The vulnerability case should record the priority classification, severity, exploitability, exposure, affected versions, active-exploitation status, impact, compensating controls and remediation owner. Priority should be reassessed when new evidence appears. This creates a defensible history showing why the manufacturer considered the risk urgent or less urgent and how it responded as the technical picture changed.
- Priority classification.
- Priority rationale.
- Affected versions.
- Active-exploitation status.
- Mitigation status.
- Remediation owner.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.