Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What does the CRA require for vulnerability handling?
Last verifiedAnnex I Part II of Regulation (EU) 2024/2847 sets manufacturer vulnerability-handling duties: document components including an SBOM, remediate without delay, test, a coordinated-disclosure policy, and a contact address. This page is not legal advice and does not start a clock.
CRA vulnerability-handling guide, last verified 9 September 2026 against Regulation (EU) 2024/2847 Articles 3(39), 6, 13, 14, 27, 31 and 71, Annex I Part II, Annex VII, Recital 77 (a recital, not an operative article), the European Commission's CRA pages and implementation FAQs (Commission materials — guidance, not the regulation), and ENISA product-security materials (agency guidance, not the regulation). It is not legal advice, not a filing, not a conformity assessment, not CE marking, not a determination that the CRA applies, and not a substitute for counsel.
This is vulnerability handling, not Article 14 reporting
Audience: an engineering leader, product owner, or security lead asking what Annex I Part II requires of a manufacturer's vulnerability-handling process. This page is not legal advice. It does not start a clock. Reading it does not start a clock. Mapping a row is not a determination that the CRA applies, that you are a manufacturer, that a product with digital elements has been made available on the Union market, that YOUR process meets Part II, or that an Article 14 filing is due.
The CRA is Regulation (EU) 2024/2847 of 23 October 2024, OJ L 2024/2847, 20.11.2024. ELI: http://data.europa.eu/eli/reg/2024/2847/2024-11-20. Article 6(b): products with digital elements shall be made available on the market only where the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Part II of Annex I. Article 13(8): manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with Part II of Annex I. Those are legal requirements only if they apply. This page does not apply them to YOU. Last verified 9 September 2026. Not legal advice.
- Handling versus reporting: Annex I Part II and Article 13 are vulnerability-handling and remediation duties. Article 14 is a separate reporting ladder — 24-hour early warning, 72-hour notification, 14-day final report on the actively-exploited track. Those clocks are not this page. The statute-clock Article 14 guide on this site is the ladder under breach reporting. The CRA-cluster Article 14 overview on this site is how Article 14 sits in the cluster.
- Statute versus guidance versus best practice: Annex I Part II, Articles 6, 13, 27 and 31 are legal requirements only if they apply. Commission CRA pages and implementation FAQs are Commission materials — guidance, not the regulation. ENISA product-security pages, the Secure by Design playbook, and the SBOM adoption survey are agency guidance, not the regulation. ISO/IEC 29147 and 30111 are best-practice context, not the essential requirement. This page quotes which kind of text it is relying on.
- The CRA overview on this site is the pillar page. The who-is-covered guide on this site is the economic-operator roles page. The SaaS-scope guide on this site is the remote-processing versus service page. The where-to-submit guide on this site is the Article 14 channel page.
- The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page. The readiness-checklist guide on this site is the end-to-end CRA readiness page. A dedicated security-updates, actively-exploited, products-in-scope, and evidence-retention guide is not on this site yet. Naming them is not a link.
Annex I Part II checklist — essential requirements, not YOUR file
The table quotes Part II as the regulation states it. It is a checklist mapped to the eight points. It is not a finding that YOUR process meets any of them, and it is not a conformity-assessment file. Last verified 9 September 2026. Not legal advice.
| Point | What Part II says | Kind of text | Last verified |
|---|---|---|---|
| Part II, point (1) — identify, document, SBOM | Manufacturers of products with digital elements shall 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. | Legal requirement — Annex I Part II, point (1). Only if the CRA applies. This page does not find that YOUR SBOM meets that point. | 9 September 2026 |
| Part II, point (2) — remediate without delay | 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. | Legal requirement — Annex I Part II, point (2). 'Without delay' is not the Article 14 24-hour reporting mark. A dedicated security-updates guide is not on this site yet. Naming it is not a link. | 9 September 2026 |
| Part II, point (3) — tests and reviews | Apply effective and regular tests and reviews of the security of the product with digital elements. | Legal requirement — Annex I Part II, point (3). This page does not score YOUR tests. | 9 September 2026 |
| Part II, point (4) — disclose fixed vulnerabilities | 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. | Legal requirement — Annex I Part II, point (4). Distinct from Article 14 CSIRT/ENISA filings. | 9 September 2026 |
| Part II, point (5) — coordinated vulnerability disclosure policy | Put in place and enforce a policy on coordinated vulnerability disclosure. | Legal requirement — Annex I Part II, point (5). The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page. ISO/IEC 29147 and 30111 are best-practice context, not this point. | 9 September 2026 |
| Part II, point (6) — sharing and contact address | 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. | Legal requirement — Annex I Part II, point (6). This page does not publish YOUR contact address. | 9 September 2026 |
| Part II, point (7) — secure distribution of updates | 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. | Legal requirement — Annex I Part II, point (7). Update-delivery detail is a dedicated security-updates guide not on this site yet. Naming it is not a link. | 9 September 2026 |
| Part II, point (8) — disseminate updates without delay | 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, at no charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken. | Legal requirement — Annex I Part II, point (8). Authentic wording is on EUR-Lex. This page restates the limb. A dedicated security-updates guide is not on this site yet. Naming it is not a link. | 9 September 2026 |
SBOM — statutory minimum, not a public catalogue
Article 3(39): software bill of materials means a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements. Part II, point (1) is the essential requirement: a commonly used and machine-readable format covering at the very least the top-level dependencies of the products. That 'at the very least' is a statutory floor, not a finding that a transitive graph is required, and not a finding that YOUR format is enough. Last verified 9 September 2026. Not legal advice.
Recital 77 (a recital, not an operative article) states that manufacturers should not be obliged to make the SBOM public. Annex II point 9: if the manufacturer decides to make available the software bill of materials to the user, information on where the software bill of materials can be accessed. Annex VII requires the technical documentation to include, among other things, the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address, and a description of the technical solutions chosen for the secure distribution of updates. Market surveillance authorities may request the SBOM further to a reasoned request where necessary to check compliance with Annex I.
Article 13(24): the Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials referred to in Part II, point (1), of Annex I. As of last verification on 9 September 2026 this page has not found such an implementing act in force. Naming CycloneDX or SPDX as commonly used formats is practice, not that implementing act, and not a determination that YOUR file meets point (1).
- Do not treat a KEV listing, a scanner alert, or an SBOM row as becoming aware under Article 14. Counsel maps YOUR facts.
- ENISA's SBOM Adoption State of Play (2026) is agency guidance on adoption practice, not Annex I Part II.
- BSI TR-03183 and similar national technical guidelines are not the regulation. This page does not apply them to YOU.
Handling and remediation are not Article 14 clocks
Two different duties can fire on the same vulnerability. Mixing them is the usual error. Last verified 9 September 2026. Not legal advice. This table does not start a clock.
- A KEV match, EPSS score, or CVSS rating may be how you learn a fact. None of those signals is, by itself, the legal finding that you have become aware under Article 14, and none of them is Annex I Part II conformity. The statute-clock Article 14 guide on this site is the ladder.
- Remediate without delay (Part II, point (2)) is not 'file within 24 hours' (Article 14(2)(a)). Do not paste one onto the other.
- A dedicated actively-exploited guide is not on this site yet. Naming it is not a link.
| Duty | What the cited text says | When it applies | Kind of text |
|---|---|---|---|
| Vulnerability handling — Annex I Part II and Article 13(8) | Identify and document components, remediate without delay including by security updates, test, CVD policy, contact address, secure distribution. Article 13(6): upon identifying a vulnerability in a component, including in an open-source component, report it to the person or entity manufacturing or maintaining the component, and address and remediate it in accordance with Part II. | Article 71(2): the rest of the Regulation, including essential cybersecurity requirements and manufacturer Chapter II duties that are not Article 14, applies from 11 December 2027. | Legal requirement — Articles 13 and 71(2), Annex I Part II. Only if the CRA applies. |
| Article 14 reporting — actively exploited vulnerability or severe incident | 24-hour early warning and 72-hour notification from the manufacturer becoming aware, to the CSIRT designated as coordinator and ENISA via the single reporting platform. Actively-exploited final report: 14 days after a corrective or mitigating measure is available. Severe-incident final report: one month after the 72-hour notification. Those marks are not one number. | Article 71(2): Article 14 applies from 11 September 2026. Article 69(3) applies those Article 14 duties to in-scope products placed on the market before 11 December 2027. | Legal requirement — Articles 14, 69(3) and 71(2). This page does not start that clock. |
| Informing users — Article 14(8) and Part II, point (4) | Article 14(8) is informing impacted users after becoming aware of an actively exploited vulnerability or a severe incident. Part II, point (4) is public disclosure of information about fixed vulnerabilities once a security update has been made available. Those are not the same stream, and neither is the CSIRT/ENISA filing. | Article 14(8) follows Article 14's application date. Part II, point (4) follows the essential-requirements application date unless the article you quote says otherwise. | Legal requirement. This page does not convert either into a 24-hour count. |
Essential requirement versus harmonised standard versus best practice
Part II is the essential requirement. Harmonised standards, Commission FAQs, ENISA playbooks, and ISO/IEC CVD standards are not substitutes for it. Last verified 9 September 2026. Not legal advice.
| Text | What it is | What this page does not do |
|---|---|---|
| Regulation (EU) 2024/2847 Annex I Part II; Articles 3(39), 6, 13, 14, 27, 31 and 71; Annex VII | Legal requirement — the regulation, only if it applies. | Does not apply those articles to YOU. Does not treat a checklist row as YOUR conformity file. |
| Article 27 presumption of conformity | Article 27(1): products with digital elements and processes put in place by the manufacturer which are in conformity with harmonised standards or parts thereof the references of which have been published in the Official Journal of the European Union shall be presumed to be in conformity with the essential cybersecurity requirements set out in Annex I in so far as those standards or parts thereof cover those requirements. | Does not find that a CRA harmonised-standard reference has been published in the Official Journal as of last verification. A draft is not a cited standard. Readiness in this product is not that presumption, and not CE marking. |
| Commission standardisation request M/606 and CRA implementation FAQ 6.10 | Commission materials. Guidance, not the regulation. FAQ 6.10 describes a horizontal standard on vulnerability handling for products with digital elements, to be adopted by the ESOs (CEN, CENELEC, ETSI) by 30 August 2026 under that request. Adoption by an ESO is not Official Journal citation under Article 27(6). | Does not treat FAQ 6.10 as rewriting Annex I Part II, and does not treat an ESO draft as a cited harmonised standard. |
| Commission guidance of 27 July 2026 (C(2026) 5252) and Commission CRA pages | Commission materials. Guidance, not the regulation. The Commission page itself calls that 27 July 2026 guidance non-binding. | Does not treat that guidance as the essential requirement. |
| ENISA product-security pages, Secure by Design and Default Playbook (30 July 2026), SBOM Adoption State of Play (2026) | Agency guidance, not the regulation. | Does not treat an ENISA playbook as Annex I Part II. |
| ISO/IEC 29147 and ISO/IEC 30111 | International best-practice standards on vulnerability disclosure and vulnerability handling. Not Union harmonisation legislation, and not Annex I Part II. | Does not treat applying those ISO/IEC standards as CRA conformity. The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page. |
When those handling duties apply — Article 71, not YOUR dates
Last verified 9 September 2026 against Article 71 on EUR-Lex. Article 71(2): this Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026. Annex I Part II essential requirements and Article 13 manufacturer vulnerability-handling duties that are not Article 14 follow 11 December 2027 unless the article you quote says otherwise.
Article 14 reporting of an actively exploited vulnerability can apply from 11 September 2026 even though the Part II handling process is not yet the full-application essential requirement. Those two dates are not one number. This page does not start a clock.
| Date in the regulation | What applies | Kind of text | Last verified |
|---|---|---|---|
| 11 September 2026 | Article 14 reporting obligations of manufacturers. This page does not start that clock. The statute-clock Article 14 guide on this site is the ladder. | Article 71(2), second subparagraph. Legal requirement. | 9 September 2026 |
| 11 December 2027 | The rest of the Regulation, including Annex I Part II essential cybersecurity requirements, Article 13 manufacturer vulnerability-handling duties, technical documentation, the EU declaration of conformity, and CE marking. | Article 71(2), first subparagraph. Legal requirement. | 9 September 2026 |
What to do now
The list below is operational preparation. It is not a determination that the CRA applies to YOU, that you are a manufacturer, that YOUR process meets Part II, or that a reporting clock has started. Walk it with counsel.
- Ask counsel whether YOU are a manufacturer of a product with digital elements made available on the Union market. This page does not run that test. Marking CRA in an obligation map is not that determination.
- Ask counsel how Annex I Part II maps onto YOUR SDLC: SBOM at least top-level dependencies, remediation without delay, tests and reviews, a coordinated-disclosure policy, and a contact address. This page does not build YOUR process.
- Do not treat Part II handling as Article 14 reporting. If counsel says Article 14 may apply, open the statute-clock Article 14 guide on this site for the 24-hour / 72-hour / 14-day ladder. This page does not start that clock.
- Do not treat a draft harmonised standard, an ENISA playbook, or ISO/IEC 29147/30111 as the essential requirement. Do not treat this product's CRA control-set as a conformity-assessment file. Readiness in this product is not CE marking.
- The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page. The readiness-checklist guide on this site is the end-to-end CRA readiness page. A dedicated security-updates, actively-exploited, products-in-scope, and evidence-retention guide is not on this site yet. Naming them is not a link.
Checklist
This is a question list mapped to Annex I Part II, not a filing, and not YOUR conformity file. Walk it with counsel. The CRA overview on this site is the pillar page. The statute-clock Article 14 guide on this site is the ladder.
- Does the CRA apply? Manufacturer of a product with digital elements made available on the Union market — Articles 2, 3 and 6. This page does not run that test.
- Part II, point (1): identify and document vulnerabilities and components, including an SBOM in a commonly used and machine-readable format covering at the very least the top-level dependencies. This page does not find that YOUR SBOM meets that point.
- Part II, point (2): address and remediate without delay, including security updates separated from functionality updates where technically feasible. Not the Article 14 24-hour mark.
- Part II, point (3): effective and regular tests and reviews.
- Part II, point (5): put in place and enforce a coordinated vulnerability disclosure policy. Point (6): a contact address. The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page.
- Part II, points (4), (7) and (8): disclose fixed vulnerabilities, distribute updates securely, disseminate without delay. A dedicated security-updates guide is not on this site yet. Naming it is not a link.
- Article 14 from 11 September 2026 if it applies: 24-hour early warning, 72-hour notification, 14-day final report on the actively-exploited track. This page does not start that clock.
- Full essential-requirements application from 11 December 2027. Readiness in this product is not CE marking.
- Document the assessment, including a not-in-scope decision. This page does not keep YOUR file.
Where this shows up in ShipReady Metrics
The bundled framework key cra is customer-visible. Its version label is Regulation (EU) 2024/2847 (starter subset). It is not in INTERNAL_TESTER_ONLY_FRAMEWORKS. The control-set is a starter subset, illustrative readiness mapping, to be tailored by a compliance owner; not legal advice; not full conformity-assessment detail. It includes Annex I-II(1) component inventory (SBOM), Annex I-II(2) vulnerabilities handled and remediated without delay, and Annex I-II(5) coordinated vulnerability disclosure policy. Tracking those rows is not Annex I Part II conformity, not CE marking, and not a market-surveillance determination. This product does not perform a CRA conformity assessment, does not draw up an EU declaration of conformity, and does not affix a CE mark.
If you already have a session: signed-in app → Security holds vulnerability-management views that rank findings with KEV, EPSS and CVSS, ingest dependency / Dependabot / code-scanning / secret-scanning alerts, deduplicate across sources, compute blast radius, and include first-party SAST and DAST. Those views are not an Annex I Part II file, not an SBOM determination, and not an Article 14 file. A KEV match timestamp is disclosure, not becoming-aware, and does not start an Article 14 clock. If you already have a session: signed-in app → Compliance → CRA reporting tracks the Article 14 24-hour / 72-hour / 14-day ladder from recorded awareness for findings the organisation classified as CRA-in-scope actively exploited vulnerabilities. That tracker does not start an Article 14 clock, does not decide that the CRA applies, does not decide that YOUR handling process meets Part II, and does not file with a CSIRT or ENISA. A named human still submits.
The obligation map lists frameworks the organisation has marked in-scope, including cra if that mark is set. Marking cra in-scope is not a determination that you are a manufacturer and not a finding that Part II applies. The cyber risk register lives under Security. It is not an Article 14 file and not a Part II conformity file.
This page does not document a public demo URL. There is no public CRA demo path.
Primary sources (last verified 9 September 2026)
Every regulatory or guidance claim on this page is taken from one of these. If a later revision of a source changes the rule, the date above is how you can see we have not re-checked yet.
Regulation (EU) 2024/2847 of 23 October 2024 (Cyber Resilience Act), Articles 3(39), 6, 13, 14, 27, 31 and 71, Annex I Part II, and Annex VII, is a legal requirement only if it applies. Recital 77 is a recital, not an operative article. Article 14 applies from 11 September 2026; the rest, including Annex I Part II essential requirements, from 11 December 2027 (Article 71(2)). The European Commission's CRA policy page, CRA implementation FAQs (including FAQ 6.10 on harmonised standards / M/606), and 27 July 2026 guidance (C(2026) 5252) are Commission materials, not the regulation. ENISA's product-security pages, Secure by Design and Default Playbook (30 July 2026), and SBOM Adoption State of Play (2026) are agency guidance, not the regulation. ISO/IEC 29147 and 30111 are best-practice context, not the regulation. As of 9 September 2026 this page has not found an Official Journal citation of a CRA harmonised standard conferring Article 27 presumption of conformity. These are not a complete world list. Not legal advice.
The CRA overview on this site is the pillar page. The who-is-covered guide on this site is the economic-operator roles page. The SaaS-scope guide on this site is the remote-processing versus service page. The CRA-cluster Article 14 overview on this site is how Article 14 sits in the cluster. The statute-clock Article 14 guide on this site is the live ladder. The where-to-submit guide on this site is the Article 14 channel page. The CSIRT guide on this site is the coordinator-interaction page. The vulnerability-disclosure guide on this site is the coordinated-disclosure policy page. The readiness-checklist guide on this site is the end-to-end CRA readiness page. A dedicated security-updates, actively-exploited, products-in-scope, and evidence-retention guide is not on this site yet. Naming them is not a link.