CRA vulnerability handling and SBOM checklist

The Cyber Resilience Act asks manufacturers to handle vulnerabilities through a defined process, including a software bill of materials (SBOM) and a coordinated vulnerability disclosure policy. Most of these duties apply from 11 December 2027, but reporting under Article 14 already applies, and it depends on the same groundwork. This checklist helps you build both.

Why start now

The vulnerability handling requirements are set out in Annex I, Part II of the regulation [1][2]. They apply from 11 December 2027 [1][5]. The reporting obligations of Article 14 apply from 11 September 2026 [1][4]. In practice you cannot report an exploited vulnerability within 24 hours if you do not know which components are in your product or who receives security reports. The groundwork serves both deadlines.

What Annex I, Part II covers

Annex I, Part II lists eight vulnerability handling requirements [2]. In plain terms, they cover:

Identifying and documenting vulnerabilities and components, including drawing up an SBOM covering at least the top-level dependencies [2].
Addressing and fixing vulnerabilities without delay, including through security updates [2].
Regular testing and review of the product's security [2].
Sharing and publicly disclosing information about fixed vulnerabilities [2].
Putting in place and enforcing a coordinated vulnerability disclosure policy [2].
Making it easy to report vulnerabilities, with a contact address [2].
Distributing updates securely [2].
Making security updates available to users with advisory messages [2].

Read the exact wording in the regulation itself before you design your process [1].

The checklist

1. Know what is in your product

Produce an SBOM for each product version you ship, covering at least the top-level dependencies [2].
Use a common machine-readable format (SPDX or CycloneDX are widely used) so tools can read it.
Regenerate it in your build pipeline, not by hand, so it stays current.
Keep SBOMs for older versions still in use. Those products are also covered by reporting [4].

2. Make it easy to tell you about problems

Publish a security contact, for example security@yourdomain and a security.txt file on your website.
Write a short coordinated vulnerability disclosure policy: how to report, what you will do, how fast you respond.
Make sure the mailbox is read every day by a named person, with a backup.

3. Triage and fix

Log every report with a date and time of receipt.
Decide severity with one consistent method, for example CVSS.
Ask one question first for each report: is there reliable evidence it is being exploited? If yes, the Article 14 clock is running [1][3].
Track each fix to release.

4. Ship updates

Sign updates and deliver them over a secure channel.
Publish an advisory with each security update: what is fixed, who is affected, what to do.

5. Be ready to report

Know who can submit through the single reporting platform, and test that access [1][4].
Have templates for the early warning, the 72-hour notification, the final report and the user notice.
Keep a list of Member States where each product is made available; the early warning asks for it where applicable [3].
Cover nights and weekends: the 24 hours do not pause [3].

Worked example: one vulnerability through the process

A maker of network cameras receives an email at security@ from a researcher about a command injection in the web interface.

Log: received Monday 10:20, case V-031.
SBOM check: the flaw is in a third-party web server component. The SBOM shows which of three camera models ship that component and in which versions. Two are affected.
Exploitation check: no evidence of use in the wild. No Article 14 report yet. Normal fix process.
Thursday: a customer reports compromised cameras with the same pattern. Now there is reliable evidence of exploitation. Awareness is Thursday 14:00, and the early warning is due by Friday 14:00 [3].
Fix: updated firmware ships the following week with an advisory. The final report is due 14 days after the fix is available [3].

Without the SBOM step, the team would have spent the first day finding out which models were affected.

Copyable disclosure policy starter

Security vulnerability disclosure policy, [Company]

How to report: email security@[domain]. Include the product, version,
steps to reproduce and your contact details. Encrypted mail: [key link].

What we do:
- We confirm receipt within [two] working days.
- We assess the report and tell you our view within [ten] working days.
- We keep you updated until the issue is fixed.
- We publish an advisory when a fix is available and credit you if you wish.

We ask you to give us reasonable time to fix the issue before public
disclosure and not to access data that is not yours.

Last updated: [date]

Adapt the response times to what you can really deliver.

Self-check scores

Question	Yes / No
Do we have a current SBOM for every product version in use?
Is our security contact published and read daily?
Do we have a written disclosure policy?
Can two people submit a report, including at weekends?
Do we know where each product is sold in the EU?
Do we have report and user notice templates?

Next, read what to do in the first 24 hours and the full reporting obligations, or compare spreadsheet vs tool vs consultant.

Related guides

Sources

This guide explains the rules in plain language. It is not legal advice. Check your own country's law and, when in doubt, ask a qualified adviser.