CRA vulnerability handling requirements: what Annex I Part II asks of manufacturers
Under the Cyber Resilience Act, vulnerability handling is a continuing manufacturer obligation, not a product feature: Annex I Part II requires an SBOM, remediation of vulnerabilities without delay, regular security testing, public advisories for fixed vulnerabilities, a coordinated vulnerability disclosure policy, a contact point, secure and timely distribution of updates and, where possible, free security updates for the support period. Article 14 adds the reporting duty for actively exploited vulnerabilities.
By the Vellaci teamPublished Updated 5 min readOperational guidance, not legal advice
Key facts
- Where
- Annex I Part II (1)–(8); Article 13(6)–(8); Article 14 for reporting
- Since when
- Reporting since 11 September 2026; the essential requirements apply from 11 December 2027 (products already on the market only if substantially modified)
- Duration
- For the support period of each product — at least five years unless the expected use is shorter
- Evidence
- SBOM per version, triage decisions with reasons, test reports, advisories, disclosure policy, update logs
The problem this solves
Most manufacturers already receive vulnerability information — scanner alerts, researcher e-mails, upstream advisories — but rarely as a process with owners, deadlines and evidence. The CRA turns that informal flow into an obligation with two hard edges: vulnerabilities in shipped products must be handled and remediated without delay, and actively exploited ones must be reported within 24 hours of awareness. A team that cannot answer 'which products on the market contain this component, who decided what, and when' cannot meet either.
What Annex I Part II requires
| Requirement | What it means operationally | Evidence to keep |
|---|---|---|
| (1) Identify and document vulnerabilities and components, including an SBOM | An SBOM in a machine-readable format covering at least the top-level dependencies, per product version | SBOM files with checksums, bound to versions |
| (2) Address and remediate vulnerabilities without delay, including security updates | Triage with an owner and a decision; fixed releases; workarounds where fixes are not yet available | Decision history per finding, release notes, fixed-version links |
| (3) Apply effective and regular tests and reviews | Security testing per release and periodic reviews of the product's security | Test reports with scope, date and findings |
| (4) Publicly disclose fixed vulnerabilities | Advisories once a security update is available, describing the vulnerability, the affected versions and the fix | Advisory archive with dates |
| (5) Put in place and enforce a coordinated vulnerability disclosure policy | A published policy with a contact, scope, handling commitments and safe-harbour language | Policy versions; security.txt |
| (6) Facilitate sharing of information, including a contact address | A working intake channel that acknowledges and handles reports | Intake log with response times |
| (7) Distribute updates securely and in a timely manner | Signed update mechanisms; distribution that reaches the installed base | Update mechanism description, signing procedures, rollout records |
| (8) Provide security updates without delay and free of charge, with advisories | Separate security updates from feature updates where possible; no charge during the support period | Release policy, update logs |
One operational workflow
The eight requirements are easier to run as one chain than as eight controls. The chain starts at the release pipeline and ends at an evidence record:
- Generate an SBOM for every supported version in the build that produces the artefact; store it with its checksum against the version.
- Match every component continuously against advisory sources (OSV, GitHub advisories) and enrich with exploitation evidence (CISA KEV, EPSS) so the queue is ranked by exploitation, not alphabet.
- Triage each finding with a named reviewer, an explicit state (affected, not affected, fixed, workaround, risk accepted) and a written reason; assign remediation with a due date derived from severity and exploitation.
- Ask the Article 14 question explicitly on every affected finding: not reviewed, potentially reportable, confirmed reportable, not reportable — with the awareness time recorded when exploitation is confirmed.
- Ship the fix as a security update; link the fixed release to the finding; publish the advisory; issue a VEX statement for components that were not exploitable.
- Keep the disclosure policy, security.txt and intake mailbox operating, with acknowledgement and handling commitments met and logged.
- File the evidence as it is produced — SBOMs, decisions, test reports, advisories, update logs — against the product and the requirement it satisfies.
Common mistakes
- Treating scanner output as the process: alerts without owners, reasons and deadlines do not evidence 'without delay'.
- SBOMs generated on request rather than per release, so exposure cannot be answered for the versions customers run.
- No written awareness rule, so nobody can say when the 24-hour clock started.
- Advisories published only for headline CVEs, leaving the archive incomplete.
- A disclosure policy on the website with no one reading the mailbox.
What Vellaci does — and what it leaves to you
Vellaci is the system of record for this chain: SBOM ingestion per version from CI, the API or the GitHub App; continuous matching against OSV, GitHub advisories, KEV and EPSS with source provenance; a triage workflow with mandatory reasons, remediation ownership and an explicit CRA review; VEX statements; fixed-release links; a disclosure policy and security.txt workspace; and an evidence vault with an append-only audit log. It keeps your scanner, tracker and pipeline; it does not replace them. Reachability, risk acceptance and reportability remain decisions made by named people in your organisation — Vellaci records who decided, why and when.
Where to start
The free assessment on this site asks how vulnerabilities in third-party components are handled today, whether an SBOM exists per release, how disclosure reports arrive and whether the reporting workflow has been rehearsed, and returns a banded gap map with the evidence each gap would need. Most teams start with the SBOM pipeline and the triage workflow, because everything else — reporting, advisories, updates — depends on knowing what is in the product.
Frequently asked questions
- Does every vulnerability in an SBOM have to be fixed?
- No. The obligation is to handle and remediate vulnerabilities that affect the product without delay. A component that is present but not exploitable in your product can be documented as not affected — ideally as a VEX statement with the reason — and that decision is itself evidence of handling.
- Do we have to publish an SBOM?
- The CRA requires the SBOM to be documented and available to market surveillance authorities on request; it does not require publication. Customers increasingly ask for it in procurement, and sharing per version is good practice.
- What counts as 'without delay'?
- The regulation does not fix a number of days. A defensible practice is a written SLA by severity and exploitation status, evidence that it is met, and documented reasons when it is not. Actively exploited vulnerabilities have the separate 24-hour reporting duty under Article 14.
- How is this different from Article 14 reporting?
- Annex I Part II is the continuous handling process for all vulnerabilities in the product; Article 14 is the notification duty to ENISA for the subset that is actively exploited (and for severe incidents). A good handling process is what makes the reporting duty meetable.