AA-sec logo AA-sec
Vulnerability Management

How to Build a CRA Vulnerability Handling Process

A practical guide to building a CRA vulnerability handling process that connects intake, triage, remediation, disclosure, updates, component coordination, and evidence.

AA-sec13 August 2026
  • Cyber Resilience Act vulnerability handling process
  • CRA vulnerability handling process
  • Cyber Resilience Act vulnerability management
  • CRA Annex I vulnerability handling
  • product vulnerability remediation CRA
  • CRA post market security
AA-sec cover graphic showing a practical vulnerability handling workflow under the Cyber Resilience Act

A Cyber Resilience Act (CRA) vulnerability handling process should connect the full lifecycle of a finding: intake, affected-product identification, technical assessment, remediation, verification, disclosure, secure update distribution, component coordination, retained evidence, and escalation when a separate reporting obligation may apply. The legal requirement is broader than incident reporting. Annex I Part II of Regulation (EU) 2024/2847 sets a continuing vulnerability-handling framework that manufacturers need to operate for their products with digital elements during the support period.

Start with the eight CRA vulnerability-handling duties

Annex I Part II gives manufacturers eight categories of vulnerability-handling work. In practical terms, the process needs to support all of them rather than treating vulnerability management as a ticket that ends when code is changed.

Manufacturers must:

  1. identify and document vulnerabilities and product components, including through a software bill of materials (SBOM) in a commonly used machine-readable format covering at least top-level dependencies;
  2. address and remediate vulnerabilities without delay in relation to the risks posed to the product, including through security updates, and provide security updates separately from functionality updates where technically feasible;
  3. perform effective and regular security tests and reviews;
  4. after a security update is available, share and publicly disclose information about fixed vulnerabilities, including affected-product identification, impact, severity and remediation information, subject to a justified possibility to delay publication when the security risks of immediate disclosure outweigh the benefits;
  5. put in place and enforce a coordinated vulnerability disclosure policy;
  6. facilitate the sharing of information about potential vulnerabilities, including by providing a contact address for vulnerability reports;
  7. provide secure mechanisms for distributing updates so that vulnerabilities can be fixed or mitigated in a timely manner; and
  8. disseminate available security updates without delay, normally free of charge, with advisory information that explains relevant user action.

These requirements describe a system, not eight independent documents. A useful implementation connects the same product identity, component information, risk assessment, decision history, fix, verification result, advisory and release evidence across the workflow.

Vulnerability handling is broader than Article 14 reporting

One of the most important design decisions is to keep routine vulnerability handling separate from mandatory CRA reporting.

The vulnerability-handling duties cover vulnerabilities in products and their components throughout the support period. Article 14 reporting, by contrast, is triggered only for specified events such as actively exploited vulnerabilities and severe incidents affecting product security. The European Commission states that those reporting obligations apply from 11 September 2026, before the CRA's main obligations apply from 11 December 2027.

A mature process therefore needs two connected paths:

  • the normal vulnerability path, which receives, assesses, remediates, verifies, documents and discloses vulnerabilities; and
  • the reporting-escalation path, which evaluates whether the evidence also meets an Article 14 trigger and, if it does, preserves the awareness time and supports the required staged notification.

Do not make the reporting branch the entry point for every vulnerability. Most vulnerability work still needs to proceed even where no Article 14 notification is required.

Build one controlled intake for internal and external findings

Article 13 requires manufacturers to have appropriate policies and procedures, including coordinated vulnerability disclosure policies, for processing and remediating potential vulnerabilities reported from internal or external sources. Annex II also requires user information to include a single point of contact where vulnerability information can be reported and received and where the coordinated vulnerability disclosure policy can be found.

Operationally, all intake channels should converge into one controlled record. Sources may include:

  • internal security testing;
  • developers and support teams;
  • customers and operators;
  • independent security researchers;
  • suppliers and component maintainers;
  • public vulnerability databases;
  • threat-intelligence or monitoring systems; and
  • findings generated during incident response.

The intake record should preserve the original report rather than immediately rewriting it into a conclusion. Useful fields include receipt time, source, reporter contact where appropriate, affected product claimed by the reporter, versions or components named, reproduction information, evidence attachments, confidentiality expectations and the person assigned to the initial assessment.

The CRA does not prescribe one ticket format. The control objective is that a finding cannot disappear between email, chat, a researcher portal and an engineering backlog.

Map the finding to an exact product and component context

A vulnerability decision is only useful if the team knows what is actually affected.

The first technical step should identify:

  • product family and variant;
  • affected release or version range;
  • relevant hardware or software component;
  • component version and provenance;
  • deployment or operating-environment assumptions;
  • whether the component is actually present and reachable in the affected configuration; and
  • whether supported releases differ in exposure.

The SBOM requirement in Annex I Part II supports this work, but an SBOM is not the vulnerability decision by itself. A component appearing in an SBOM may be unaffected because vulnerable functionality is not present, not reachable or not used in the product context. Conversely, a vulnerable component that is missing from inventory can cause a team to miss an affected release entirely.

Record the evidence behind applicability decisions. Later reviewers should be able to distinguish "component not present", "component present but vulnerable code not used", "affected and exploitable under specified conditions", and "insufficient evidence; investigation continues".

Triage risk without confusing severity with reportability

Triage should answer at least three different questions:

  1. Is the finding valid and relevant to this product?
  2. What cybersecurity risk does it pose and how urgently should it be remediated?
  3. Is there evidence that creates a separate CRA reporting obligation?

Those questions overlap, but they are not interchangeable. A high severity score does not automatically mean a vulnerability is actively exploited. A lower-scored issue may still require rapid treatment because of the product's exposure, safety context, attack path or user impact.

A practical assessment can consider technical severity, exploit prerequisites, affected security properties, exposed interfaces, deployment conditions, available mitigations, exploit evidence, affected user population and the consequences of compromise. The manufacturer's cybersecurity risk assessment should be updated where the new information materially changes the product risk picture.

Keep facts and judgement separate. For example, "public proof-of-concept code exists" is an observation; "this creates unacceptable risk for the supported internet-facing configuration" is a product-specific decision that should identify its reasoning and approver.

Coordinate vulnerabilities in third-party components

The CRA makes component vulnerabilities part of the manufacturer's product-security responsibility.

Article 13 requires manufacturers that identify a vulnerability in an integrated component, including an open-source component, to report it to the person or entity manufacturing or maintaining that component and to address and remediate the vulnerability in the product. Where the manufacturer has developed a software or hardware modification to address the component vulnerability, the relevant code or documentation must be shared with the component manufacturer or maintainer where appropriate, including in machine-readable form where appropriate.

This creates a supplier-coordination step that should not be left to informal developer outreach. The record should show:

  • which component and version are affected;
  • who maintains or supplies it;
  • when the maintainer was informed;
  • what information was shared;
  • whether an upstream fix exists;
  • whether the product uses the upstream fix, a backport, a mitigation or another change; and
  • which supported product releases receive the resulting remediation.

For open-source dependencies, identify the actual project or maintainer channel rather than assuming a package registry, distribution or repository mirror is the responsible contact.

Turn the remediation decision into a release decision

Annex I requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed to the product. That means the process should not stop at "fix accepted".

The remediation record should connect:

  • the vulnerability assessment;
  • the selected fix or mitigation;
  • affected and unaffected releases;
  • engineering change identifiers;
  • verification evidence;
  • release approval;
  • the security update or corrected version;
  • distribution status; and
  • user-facing advisory information.

Where technically feasible, new security updates should be provided separately from functionality updates. Product teams should therefore know whether a security-only release is possible, what qualification it requires and what operational constraints could justify another release form.

If an immediate full fix is not feasible, document any temporary mitigation, its limitations, the residual risk and the plan for permanent remediation. A mitigation is part of the decision history; it should not silently overwrite the original vulnerability assessment.

Verify the fix and keep regular testing separate

The CRA also requires effective and regular security testing and reviews. That is broader than verifying one patch.

For an individual vulnerability, verification should confirm that:

  • the identified attack path is no longer effective or is acceptably mitigated;
  • the change applies to every release claimed as fixed;
  • the fix does not create a new material security weakness;
  • update packaging and installation work in the supported environment; and
  • the evidence can be tied to the exact artefact or release that users receive.

Separately, the manufacturer needs a recurring testing and review capability that can discover new weaknesses before external reports arrive. Depending on the product, that may include code review, dependency analysis, static or dynamic testing, penetration testing, protocol testing, fuzzing, configuration review or targeted security regression testing.

The CRA does not prescribe one universal testing stack. The testing approach should be proportionate to the product and its cybersecurity risks.

Coordinate disclosure after remediation is available

Coordinated vulnerability disclosure is both a CRA requirement and an operating discipline.

ENISA describes coordinated vulnerability disclosure as a process in which vulnerability finders and relevant stakeholders cooperate so that vulnerabilities can be addressed before public disclosure. Under CRA Annex I Part II, manufacturers must put in place and enforce a coordinated vulnerability disclosure policy and facilitate vulnerability reporting.

Once a security update has been made available, the CRA requires manufacturers to share and publicly disclose information about the fixed vulnerability. That information should enable users to identify the affected product, understand the vulnerability's impact and severity, and take clear remediation action.

The Regulation also allows delayed public disclosure in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits. The delay is not a reason to omit the record. Document why disclosure was delayed, who approved the decision, when users received the opportunity to patch and when the information was ultimately released.

Secure distribution and user communication belong in the same workflow

A corrected binary or package is not the end of vulnerability handling.

The CRA requires mechanisms for secure update distribution and requires available security updates to be disseminated without delay. Advisory messages should provide relevant information, including actions users may need to take.

A release record should therefore identify:

  • the update package or corrected product version;
  • integrity or authenticity information used by the product's update mechanism;
  • distribution channel and release time;
  • affected and fixed versions;
  • installation prerequisites;
  • temporary mitigations where relevant;
  • user action required;
  • known rollout limitations; and
  • the published vulnerability advisory.

Do not assume that a successful build means the vulnerability has been handled. The fix must reach the supported product population through the actual update model.

Preserve a decision history that can be reconstructed later

Article 13 requires manufacturers to systematically document relevant cybersecurity aspects, including vulnerabilities they become aware of and relevant third-party information, proportionately to the product and its cybersecurity risks.

A useful retained evidence set for each vulnerability includes:

  • original intake evidence;
  • product, release and component scope;
  • reproduction or validation result;
  • risk and exploitability assessment;
  • reportability assessment where applicable;
  • component-maintainer or supplier communication;
  • remediation and mitigation decisions;
  • engineering change references;
  • verification and regression evidence;
  • approval and release records;
  • user advisory and disclosure history;
  • update distribution evidence;
  • Article 14 submissions where applicable; and
  • closure rationale and any follow-up action.

Preserve revisions rather than replacing old conclusions. Vulnerability understanding changes as new evidence arrives. A later reviewer should be able to see what the organisation knew at each important point and why the decision changed.

A practical end-to-end vulnerability workflow

A manufacturer can translate the requirements into a repeatable operating sequence:

  1. Receive and preserve the finding. Record the source, receipt time and original evidence.
  2. Validate the finding. Confirm that the report is technically credible or document why it is rejected.
  3. Identify affected product context. Map products, variants, releases, components and deployment assumptions.
  4. Assess cybersecurity risk. Record severity, exploit conditions, impact, mitigations and uncertainty.
  5. Evaluate reporting triggers. If evidence may indicate active exploitation or a severe incident, enter the Article 14 escalation path without stopping routine remediation.
  6. Coordinate third-party components. Notify maintainers or suppliers where required and record upstream or downstream actions.
  7. Decide remediation. Select a fix or mitigation, owners, target releases and release approach.
  8. Implement and verify. Retain change references, test results and evidence tied to the corrected release.
  9. Prepare secure distribution and disclosure. Release the security update, advisory and user instructions through the applicable channels.
  10. Monitor and close. Track material rollout issues, preserve the final state and update the product risk assessment where appropriate.

Each step needs an accountable owner and an escalation path. Security may own intake and triage, engineering may own remediation, release teams may own packaging and distribution, and legal or regulatory specialists may advise on reporting or disclosure decisions. The exact RACI can vary; the important point is that responsibility is explicit before a high-pressure vulnerability arrives.

Test the process with evidence, not only a procedure document

A written policy can look complete while the real workflow remains fragmented.

Run a tabletop or controlled exercise using one supported product and a realistic component vulnerability. Ask the team to produce, from the systems it actually uses:

  • the vulnerability intake record;
  • the affected product and release list;
  • the relevant SBOM component;
  • the risk and applicability decision;
  • the component-maintainer communication;
  • the remediation change;
  • verification evidence;
  • release approval;
  • the update distribution record;
  • the user advisory;
  • the disclosure decision; and
  • the Article 14 escalation assessment.

Then check whether the evidence forms one coherent timeline. If several teams have incompatible product names, version identifiers or timestamps, the process is not yet reliably traceable even if each team completed its own task.

Keep vulnerability work tied to the product lifecycle

The operational challenge is not only finding vulnerabilities; it is keeping each finding, decision, fix and piece of evidence tied to the correct product and release as the lifecycle changes. AA-sec is designed around traceability between vulnerability work, security evidence, release decisions and exact product or lifecycle context, while complementing existing engineering and delivery systems; the manufacturer remains responsible for engineering decisions and for determining its legal obligations.

The practical standard to aim for

A CRA vulnerability handling process should let a manufacturer answer five questions without reconstructing the story manually: what was reported, which product and component were affected, what risk and reporting decisions were made, what remediation reached users, and what evidence proves the sequence.

The strongest implementation is a controlled lifecycle process rather than a larger ticket template. Intake, assessment, remediation, testing, disclosure, update delivery, component coordination and regulatory escalation should remain connected to the same product context and decision history from the first report through closure.

Official sources