This guide shows the requirements, the process and the role of CSAF. The reporting duty under Art. 14 CRA has its own guide.
The eight requirements at a glance
| No. | What Annex I Part II requires | What it looks like in practice |
|---|---|---|
| 1 | Identify and document vulnerabilities and components, with a software bill of materials | SBOM per version in a commonly used, machine-readable format |
| 2 | Address and remediate vulnerabilities without delay, with security updates separate from functionality updates where technically feasible | Prioritization and a separate update path |
| 3 | Test the security regularly and effectively | Planned tests, results kept |
| 4 | After an update, publish information on fixed vulnerabilities | Security advisory with product, impact, severity and remedy |
| 5 | Put in place and enforce a policy on coordinated disclosure | Published policy |
| 6 | Facilitate sharing information on vulnerabilities, with a contact address | Security contact, for example through security.txt |
| 7 | Provide mechanisms to distribute updates securely | Signed updates, automatic where suitable |
| 8 | Disseminate security updates without delay and free of charge, with advisory messages for users | Update and advisory go out together |
For no. 8, manufacturers and business users can agree otherwise for a tailor-made product. For no. 4, publication may wait in justified cases until users have had the chance to apply the patch.
What else belongs to it
- Support period: It reflects the expected use and is at least five years, or shorter if the expected time in use is shorter (Art. 13(8) CRA).
- Availability of updates: Security updates provided stay available for at least ten years or for the rest of the support period, whichever is longer (Art. 13(9) CRA).
- Third-party components: If you find a vulnerability in an integrated component, report it to the entity that makes or maintains it. This also applies to open source (Art. 13(6) CRA).
- Single point of contact: Users must be able to find you easily and choose their means of communication (Art. 13(17) CRA).
Art. 13 and Annex I apply from 11 December 2027, the reporting duties under Art. 14 since 11 September 2026 (Art. 71(2) CRA). The process helps earlier than that, because reporting assumes that you can spot and classify vulnerabilities.
The process in seven steps
- Open the intake. Set up a security contact and publish your policy on coordinated disclosure.
- Acknowledge receipt. Reply to the reporter and record the time.
- Investigate. Clarify which products and versions are affected. The SBOM shows where a component sits.
- Assess. Classify the severity and check whether the vulnerability is actively exploited. If so, Art. 14 CRA applies.
- Fix. Develop and test the correction. Keep security and functionality updates separate where you can.
- Distribute and inform. Provide the update securely and free of charge and publish the security advisory.
- Learn. Record the cause and update the risk assessment and the documentation (Art. 13(7) CRA).
The history later proves that the process works. The procedures belong in the technical documentation (Annex VII no. 2(b) CRA).
What the disclosure policy contains
The CRA requires a policy but prescribes no structure. Five details have proven useful:
- Contact: Where do reports go, and how can people write confidentially?
- Scope: Which products and versions are covered?
- Procedure: What happens after receipt?
- Timeframe: What times do you aim for on acknowledgment, assessment and publication?
- Credit: Do you name reporters if they wish?
The law sets no fixed days for these steps. The times are your own commitment. Promise only what you can keep.
CSAF: what it is and what it is not
CSAF stands for Common Security Advisory Framework. This OASIS format describes security advisories in machine-readable form, and the widely used version is CSAF 2.0. The BSI has published Technical Guideline TR-03191 on it.
- What the CRA says: It does not name CSAF. Art. 14(8) requires informing users, where appropriate, in a structured, machine-readable format that is easy to process automatically.
- What CSAF offers: It fits this description, but it is not the only conceivable solution.
- What your customers gain: Operators match advisories with their inventory automatically instead of reading PDF files.
- VEX: A CSAF profile states whether a product is affected by a vulnerability or not. That saves questions.
Example from machine building
The example is invented. A maker of controllers receives a report on a flaw in the firmware's web server.
- Day 1: Receipt is acknowledged and the investigation starts.
- Day 3: The SBOM shows that two of five versions contain the component. No exploitation is known.
- Day 20: Firmware 2.4.1 is tested and released.
- Day 21: Update and security advisory go out, as a web page and as a CSAF document.
The times are sample values, not a target.
Checklist
- A security contact is published and monitored.
- A policy on coordinated disclosure is published.
- There is a current SBOM for every product version.
- The support period is set and justified.
- Assessment and ownership are settled, including for the reporting duty.
- Security updates can be distributed separately and free of charge.
- Security advisories have a fixed structure, machine-readable where possible.
- Vulnerabilities in third-party components go to their maker or maintainer.
- The history of every report is documented.
The process in Complass
No more guessing where a report stands. In Complass report, product and advisory come together:
- Vulnerability reports: Every report runs from receipt through investigation to publication, with a full history.
- security.txt and policy: Complass generates both. You check the values and publish them on your website.
- Public report form: If you wish, you accept reports through a form.
- Product version: Reports, findings and advisories appear on the version, with SBOM and end of support.
- Security advisories: You write an advisory, release it as CSAF 2.0 and publish it with a feed.
- Dispatch: Advisories go to recipient lists per product, with a dispatch proof.
- CRA report: In case of active exploitation you create the incident from the report. Deadlines run from when you became aware.
Frequently asked questions
Do we have to use CSAF?
The CRA does not prescribe CSAF. For informing users, Art. 14(8) requires a structured, machine-readable format where appropriate. Several large industrial automation vendors already publish their advisories as CSAF.
How quickly do we have to fix a vulnerability?
Annex I Part II says "without delay" in relation to the risks and gives no number of days. Record how you prioritize and why.
Does this also apply to older products?
Products placed on the market before 11 December 2027 fall under the requirements only if they undergo a substantial modification after that date. Art. 14 however applies to all products in scope (Art. 69(2) and (3) CRA).
What is the difference from the reporting duty?
The process under Annex I Part II applies to all vulnerabilities. Reporting under Art. 14 concerns actively exploited vulnerabilities and severe incidents.
Who should run the process?
The CRA names no particular role. Many manufacturers place the task in a small team from development, product management and support. A fixed owner and a deputy are what matters.
In a demo we use an example to show you how a report becomes a released security advisory.
Request a demo Calculate CRA reporting deadlines
Read more
- Guide "CRA reporting for manufacturers under Art. 14"
- Guide "SBOM under the CRA"
- Whitepaper on the CRA for manufacturers
- Vulnerability management: vulnerabilities, vendor advisories and priorities
- The CRA in Complass
Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The wording of Regulation (EU) 2024/2847 in the Official Journal is authoritative. As of November 2026.