Does a requirements management tool cover CRA vulnerability handling?
No. A requirements management tool can document the CRA Annex I Part II vulnerability handling requirements and trace each requirement to design and test. Disclosure intake, security updates and Article 14 reporting need an operational vulnerability handling process.
Key takeaways
- Annex I Part II of the Cyber Resilience Act lists eight vulnerability handling requirements, and Article 13(8) requires vulnerabilities to be handled effectively for the whole support period.
- A requirements management tool holds requirements, traces them to design and test, and supports the technical documentation that Annex VII asks for.
- Receiving reports, publishing advisories, watching SBOM components and filing Article 14 notifications are activities with dates and owners, so they need an operational process.
- Article 14 requires an early warning within 24 hours and a notification within 72 hours of becoming aware of an actively exploited vulnerability, submitted through the single reporting platform.
- A workable setup keeps requirements and traceability in the requirements tool, runs vulnerability handling in an operational system, and links the two by requirement ID.
What does a requirements management tool do for the CRA?
A requirements management tool records each CRA requirement, traces it to design and test, and keeps that record under change control for every product version. Tools such as Jama Connect, Siemens Polarion, IBM DOORS Next and PTC Codebeamer are built for this work.
That trace is useful evidence. Annex VII asks the technical documentation for a description of the design and development of the product, and for the cybersecurity risk assessment, including how the Part I requirements of Annex I apply. A traced, baselined set of requirements answers much of that.
Requirements tools are built to trace requirements, not to operate a disclosure process. A vulnerability report from an outside researcher, a 24-hour deadline and a published advisory are events in time. A requirement is a statement that holds until somebody changes it.
Why is CRA vulnerability handling more than a requirement?
The regulation describes vulnerability handling as work that continues after the product ships. Article 13(8) requires a manufacturer to ensure that vulnerabilities, including those in components, are handled effectively and in accordance with Annex I Part II for the support period.
The verbs in Annex I Part II make the same point. A manufacturer must identify, address, test, disclose, enforce a policy, provide a contact address, distribute updates and disseminate advisories. Each verb needs a record of who did what, and when.
The conformity assessment looks at the process as well. Under Annex VIII Part I point 3, the manufacturer must take all measures necessary so that its vulnerability handling processes and their monitoring ensure compliance with Annex I. Annex VII point 2(b) asks the technical documentation for the specifications of those processes, including the SBOM, the coordinated vulnerability disclosure policy, evidence of a reporting contact address and the secure update solution.
What does each CRA vulnerability handling duty need?
Each of the eight Annex I Part II points and both Article 14 notification duties needs a documented requirement and an operational activity. The table shows which part a requirements tool records and which part needs a running process.
| Provision | What the CRA requires | What a requirements tool records | What needs an operational process |
|---|---|---|---|
| Annex I Part II (1) | Identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products. | The requirement, its acceptance criteria, and a trace to the build step that produces the SBOM. | An SBOM for each release, and a watch on every listed component for newly published vulnerabilities. |
| Annex I Part II (2) | In relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates. | The remediation procedure as a documented requirement. | A case record for each vulnerability, with severity, owner, affected versions, fix version and dates. |
| Annex I Part II (3) | Apply effective and regular tests and reviews of the security of the product with digital elements. | Test cases, test runs and their trace to each requirement. Many requirements tools include test management. | Findings from those tests enter the same case records as reports from outside the company. |
| Annex I Part II (4) | Once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch. | The disclosure procedure and an advisory template. | A published advisory for each fixed vulnerability, for example a CSAF document, or a recorded justification where publication waits until users can apply the patch. |
| Annex I Part II (5) | Put in place and enforce a policy on coordinated vulnerability disclosure. | The policy text, its owner and its approval history. | A published policy, and intake that follows it, with acknowledgement, triage and agreed disclosure dates. |
| Annex I Part II (6) | Take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements. | The requirement that a reporting contact exists. | A reporting channel that a researcher outside the company can reach, and a record of every report received. |
| Annex I Part II (7) | Provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner. | Design requirements for the update mechanism, traced to architecture and tests. | The update infrastructure of the product itself. Neither a requirements tool nor a disclosure system delivers the update. |
| Annex I Part II (8) | Ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken. | The requirement and the release procedure. | A release record and an advisory message for each security update. |
| Article 14(1) and (2) | Notify an actively exploited vulnerability through the single reporting platform, with an early warning within 24 hours, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. | The reporting procedure and the roles in it. | A case with the time of awareness, running deadlines, and notification content ready for submission. |
| Article 14(3) and (4) | Notify a severe incident having an impact on the security of the product, with an early warning within 24 hours, a notification within 72 hours, and a final report within one month of the incident notification. | The incident reporting procedure and the roles in it. | An incident record with the same deadline tracking and notification content. |
What does Article 14 add?
Article 14 adds fixed reporting deadlines that start when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident. Each notification goes simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform that ENISA establishes under Article 16.
- An early warning within 24 hours of becoming aware (Article 14(2)(a) and 14(4)(a)).
- A vulnerability or incident notification within 72 hours of becoming aware (Article 14(2)(b) and 14(4)(b)).
- A final report no later than 14 days after a corrective or mitigating measure is available for a vulnerability, or within one month of the incident notification for a severe incident (Article 14(2)(c) and 14(4)(c)).
Article 14 has applied since 11 September 2026 under Article 71(2). Annex I Part II and the rest of the regulation apply from 11 December 2027. Article 69(3) extends Article 14 to every product in scope that was placed on the market before 11 December 2027. See CRA reporting obligations and the ENISA single reporting platform guide.
How do a requirements tool and a vulnerability handling system work together?
The requirements tool owns the requirement and its trace. The vulnerability handling system owns the cases, deadlines and publications. A shared requirement ID links the two.
- Hold the Annex I requirements in the requirements tool, with a baseline for each product version.
- Run report intake, triage, advisories, SBOM monitoring and Article 14 notifications in the vulnerability handling system.
- Tag each case and each piece of evidence with the Annex I requirement ID it supports.
- Bring that evidence into the technical documentation, so Annex VII point 2(b) describes a process that ran, not a process on paper.
CVD Portal exports the Annex I requirements as a ReqIF file, so a requirements tool can import them and trace them to design and test. Intake, advisories, SBOM monitoring and Article 14 case records stay in the CRA compliance platform, and the coordinated vulnerability disclosure guide covers the policy and the intake side.
What should a manufacturer ask a requirements tool vendor about the CRA?
Five questions show whether a tool runs vulnerability handling or documents it. A tool that answers no to the first four can still be the right place for the requirements.
- Can a security researcher outside the company submit a report into the tool, without an account?
- Does the tool record the time the company became aware of an actively exploited vulnerability, and count 24 hours and 72 hours from that time?
- Can the tool publish a security advisory, for example as a CSAF document?
- Can the tool import an SBOM for each release and flag components with newly published vulnerabilities?
- Can the tool import and export requirements as ReqIF, so the Annex I requirements and their status move between systems?
Frequently asked questions
Can the CRA Annex I requirements live in a requirements management tool?
Yes. Annex I of Regulation (EU) 2024/2847 is a list of essential cybersecurity requirements, and a requirements management tool can hold each point with an ID, trace it to design and test, and keep a baseline for each product version. Annex VII point 2(b) then asks the technical documentation to describe the vulnerability handling processes the manufacturer put in place.
Is a traceability matrix enough evidence for CRA Annex I Part II?
No. A traceability matrix shows that each requirement is covered by design and test. Annex VII point 2(b) asks for the specifications of the vulnerability handling processes put in place, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for reports, and a description of the technical solutions for secure update distribution.
When do the CRA vulnerability handling obligations apply?
Article 14 reporting has applied since 11 September 2026, and Annex I Part II applies from 11 December 2027, both under Article 71(2). Article 69(3) extends Article 14 to every product in scope that was placed on the market before 11 December 2027.
What is ReqIF?
ReqIF, the Requirements Interchange Format, is a specification of the Object Management Group for exchanging requirements as XML between organisations and between different requirements management tools. A ReqIF file carries requirement IDs, text and attributes, so the receiving tool can trace each requirement to its own design and test records.
Sources
- Regulation (EU) 2024/2847, the Cyber Resilience Act, EUR-Lex CELEX:32024R2847. Article 13(8), Article 14, Article 16, Article 69(3), Article 71(2), Annex I Part II, Annex VII and Annex VIII.
- Requirements Interchange Format (ReqIF), Object Management Group
Published by Porta Regulus B.V. under the editorial policy. This page summarises the text of Regulation (EU) 2024/2847. It is not legal advice.
Last updated on 2026-10-20.
Run vulnerability handling next to your requirements tool
CVD Portal keeps disclosure intake, advisories, SBOM monitoring and Article 14 case records in one place, and exports the Annex I requirements as ReqIF for your requirements tool.