The practical objective is not simply to operate a vulnerability scanner. Manufacturers need a controlled workflow that can receive findings from internal and external sources, determine which supported products are affected, assign remediation, verify fixes, release security updates and coordinate regulatory or public communication.
Stage 1: Create a Single Vulnerability Intake Process
Potential vulnerabilities can arrive from many sources, including internal testing, developers, researchers, customers, third-party suppliers, dependency advisories and threat intelligence. A CRA-oriented process should create one traceable vulnerability case regardless of source. The case should preserve the report, receipt time, reporter information where appropriate, affected product information and any evidence supplied. External reports should enter through the manufacturer's coordinated vulnerability disclosure and vulnerability-contact process.
- Create a case identifier.
- Record intake time.
- Record source.
- Record affected product information.
- Preserve technical evidence.
Stage 2: Validate the Report Without Losing the Original Evidence
The team should determine whether the reported behaviour can be reproduced or otherwise substantiated. Validation should not overwrite the reporter's original information because later analysis may depend on exact versions, configuration or proof-of-concept details. Cases that initially appear invalid can still reveal documentation, configuration or usability issues, while confirmed vulnerabilities should progress quickly to affected-version and risk analysis.
- Preserve the original report.
- Attempt controlled reproduction.
- Record test environment.
- Record validation result.
- Escalate confirmed vulnerabilities.
Stage 3: Determine Affected Products and Versions
Before remediation can be prioritised, the manufacturer needs to know where the vulnerable code or component exists. The case should map the finding to product families, supported versions, substantially modified versions and relevant third-party components. SBOM and dependency data can accelerate this work. Version analysis is also necessary for user advisories and for determining which update packages need to be created and tested.
- Identify affected product families.
- Identify affected versions.
- Identify affected components.
- Identify supported branches.
- Record unaffected versions where useful.
Stage 4: Assess Severity, Exploitability and Product Risk
Triage should combine technical severity with product context. A vulnerability can have a high generic severity score but limited reachability in a particular product, while another issue can become critical because it affects a privileged remote interface. Teams should assess exploitability, privileges required, exposure, user interaction, affected assets and potential cybersecurity impact. The cybersecurity risk assessment should be updated where the vulnerability changes material assumptions about the product.
- Assess exploitability.
- Assess attack prerequisites.
- Assess security impact.
- Assess product exposure.
- Update risk assumptions where appropriate.
Stage 5: Run the Article 14 Decision in Parallel
The vulnerability-management process should contain a separate Article 14 decision point. If the manufacturer becomes aware that a vulnerability meets the CRA definition of an actively exploited vulnerability, the regulatory reporting timeline can begin even while technical investigation and remediation continue. Article 14 reporting has applied since 11 September 2026. A vulnerability that does not meet that threshold can still require remediation under Article 13 and Annex I Part II.
- Assess actively exploited vulnerability status.
- Capture manufacturer awareness time.
- Escalate possible Article 14 cases immediately.
- Continue remediation in parallel.
Stage 6: Assign a Remediation Owner and Target
Confirmed vulnerabilities should have explicit remediation ownership. The owner can be an engineering team, component team or supplier-management function depending on the cause. The case should describe the intended remediation or mitigation, affected versions and expected verification. Risk should guide urgency. Annex I Part II requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed to the product rather than establishing one fixed deadline for every vulnerability.
- Assign an owner.
- Define remediation scope.
- Identify affected versions.
- Prioritise according to product risk.
- Track progress.
Stage 7: Test the Security Fix
A code change is not sufficient evidence that the vulnerability has been remediated. The original attack path or failure condition should be retested where practical, and the team should check for obvious bypasses or regression. Important fixes should become repeatable security tests when possible. Verification records should identify the product version and build tested so the evidence can later be linked to the security update actually released.
- Retest the original vulnerability.
- Check for bypasses.
- Run relevant regression tests.
- Record tested version and environment.
Stage 8: Release Security Updates to Supported Products
Where remediation requires a security update, the manufacturer should connect the vulnerability case to the release process. The update should be targeted to the affected supported versions, pass security verification and use the product's secure distribution mechanism. Security fixes should be separable from functionality updates where technically feasible. The release record should identify which vulnerability or vulnerabilities the update addresses.
- Build the required security update.
- Target affected supported versions.
- Verify update authenticity and integrity.
- Connect update and vulnerability identifiers.
Stage 9: Coordinate Disclosure and User Communication
Once the relevant security update has been made available, Annex I Part II requires information about fixed vulnerabilities to be shared and publicly disclosed, subject to the specific possibility of justified delayed publication where security risks outweigh the benefits until users have had an opportunity to apply the patch. The coordinated vulnerability disclosure process should also keep the reporter appropriately informed where applicable and should align public information with the actual affected versions and available remediation.
- Prepare the security advisory.
- Identify affected products and versions.
- Explain severity and impact.
- Provide remediation instructions.
- Coordinate publication timing.
Stage 10: Track the Support Period Before Closing the Case
Closure should consider the support status of affected product versions. Article 13 requires effective vulnerability handling throughout the support period. A product version reaching end of support should therefore not disappear from operational visibility without a defined transition. The manufacturer should know the end date communicated to users, which versions remain supported and whether issued security updates must remain available under Article 13(9).
- Check support status.
- Confirm affected supported versions received remediation.
- Record end-of-support implications.
- Preserve issued security updates for the required availability period.
Stage 11: Feed Lessons Back Into Development
A mature vulnerability process improves the product lifecycle. Repeated authentication flaws can indicate weak access-control requirements. Repeated parser vulnerabilities can indicate missing fuzzing or input-validation controls. Dependency incidents can reveal inadequate component governance. The case should therefore capture root-cause lessons that can improve threat models, coding standards, architecture reviews and regression tests rather than treating every vulnerability as an isolated support ticket.
- Identify root cause.
- Update development controls.
- Update threat models where needed.
- Add regression coverage.
- Review repeated vulnerability patterns.
Keep One Traceable Case Record
The vulnerability case should provide a coherent record from intake through closure. Useful fields include source, receipt time, affected products and versions, component information, technical assessment, Article 14 decision, remediation owner, security-update identifier, test evidence, disclosure status and support-period status. This gives the manufacturer evidence that reports from internal or external sources were actually processed and remediated through an effective vulnerability-management system.
- Source and intake time.
- Affected versions.
- Risk assessment.
- Article 14 decision.
- Remediation evidence.
- Security-update reference.
- Disclosure status.
- Support-period status.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.