Vulnerability handling and the SBOM under the CRA

Scope: one product portfolio · Who: the product security lead · Prerequisites: a product list, a contact point, an inventoriable build · First result: one quarter

1. Why this exists (the failure mode it prevents)#

Part I of Annex I to the Cyber Resilience Act says what a product has to be. Part II says what its manufacturer must keep doing, as eight standing duties rather than product properties ¹.

The pattern is recognisable. A bill of materials is generated once, at release, and never regenerated when a dependency moves. Disclosure is handled by whoever reads the shared mailbox. Updates ship inside feature releases, so no record says which versions got which fix.

Each of those is a Part II point going unmet. Points (1) and (2) cover the bill of materials and remediation without delay. Points (3) and (4) cover regular tests and public disclosure once an update exists. Points (5) to (8) cover the policy, the contact address, secure distribution and free dissemination with an advisory ². Two surfaces expose the gap. The Article 14 clocks start at awareness and apply from 11 September 2026, ahead of the rest of the Regulation. As part of a Union-wide dependency assessment, market surveillance authorities may also ask for the bills of materials themselves ³.

The three disciplines meet here as one loop. Governance decides the disclosure policy, the support period, and who may authorise an advisory ⁴. Risk decides severity, exploitability, affected versions and fix order; the Regulation ties the whole Part II set back to a documented cybersecurity risk assessment ⁵. Compliance keeps the records and the notifications, so what was decided can be shown to have happened. Remove one and the other two stop working.

2. Definitions (only the ones that cause disputes)#

The Regulation's defined terms are used as published. Where it uses a term it does not define, the row says so and marks the definition as ours.

Term	Working definition	Source
Vulnerability	A weakness, susceptibility or flaw of a product with digital elements that a cyber threat can exploit.	Art. 3(40)
Exploitable vulnerability	One that could be effectively used by an adversary under practical operational conditions.	Art. 3(41)
Actively exploited vulnerability	One with reliable evidence that a malicious actor has exploited it without the owner's permission.	Art. 3(42)
Severe incident	Severe on either test: harm to the product's protection of sensitive or important data or functions, or malicious code introduced or executed.	Art. 14(5)
Software bill of materials	A formal record of the details and supply chain relationships of the components in a product's software elements.	Art. 3(39)
Support period	The period in which vulnerabilities must be handled under Part II; at least five years, or the shorter expected use time.	Art. 3(20); Art. 13(8)
Open-source software steward	A legal person, not a manufacturer, that systematically supports free and open-source products intended for commercial activities.	Art. 3(14)
Coordinated vulnerability disclosure	Not defined in Article 3. Ours: how reporter and manufacturer handle a report through to publication.	Part II point (5)
Security update	Not defined in Article 3, although points (2), (7) and (8) turn on it. Ours: a change released to fix or mitigate vulnerabilities.	Part II (2), (8)
Component due diligence	Ours, from Art. 13(5): settle what the product needs from a component, then verify it delivers that.	Art. 13(5)

Every Regulation row was read in the Publications Office text ⁶. Two further terms are ours. Severity is how bad the outcome is; exploitability is how reachable the flaw is here. Some are exploitable only in laboratory conditions ⁷. A critical score against an unreachable code path is not a fix-first case.

3. The method — ten steps, each with input, activity, output and owner#

Order matters: a triage decision taken without a component inventory is a guess about which versions are affected.

3.1 Inventory the products, then the components inside them#

Point (1) asks two things at once: vulnerabilities and components identified and documented, and a bill of materials drawn up. That record is in a commonly used, machine-readable format, covering at the very least the top-level dependencies ⁸. Top-level is the floor, not the target.

Three decisions settle the shape. Depth: top-level only, or transitive as far as the build resolves. Format: a commonly used machine-readable one. SPDX and CycloneDX are the formats teams reach for; the Regulation names neither, and the Commission may specify format and elements by implementing act ⁹. Its guidance of 27 July 2026 does not discuss the bill of materials. Where it lives: one record per product version, from the release pipeline. The record is not public by default. Annex II item 9 asks only that users be told where to find it, where it is offered ¹⁰.

• Input: the product and version list, the build manifests, the release pipeline.
• Activity: generate a bill of materials on every release build; record depth, format and date; diff against the previous version.
• Output: one SBOM record per product version, and a component inventory queryable across products.
• Owner: the engineering lead per product line; the product security lead owns depth and format.

3.2 Do component due diligence, and answer the open-source question#

Article 13(5) requires due diligence when integrating third-party components, so they do not compromise the product's cybersecurity, and says so expressly for free and open-source components not made available commercially. Article 13(6) adds the upstream duty. On identifying a vulnerability in a component, report it to whoever manufactures or maintains that component, and remediate under Part II. Any code or documentation produced to fix it is shared upstream too ¹¹.

The Commission narrows this usefully. Report upstream only for the version integrated, through the maintainer's own channels; skip the report where the maintainer is demonstrably already aware; report flaws in the component itself, not flaws created by the integration. Where a component has no maintainer left the duty falls away, and a shared fix need not be accepted upstream to discharge it ¹². An open-source software steward carries its own duty, a documented and verifiable cybersecurity policy covering how vulnerabilities are documented, addressed and remediated ¹³.

None of that answers the question that decides risk: whether anyone is paid to fix the next defect, the point of the insight on open-source risk. Record it beside the security question, in the gate that already checks the licence, as third-party risk across the lifecycle does for suppliers.

• Input: the component inventory, the product's security requirements, the licence intake.
• Activity: state what the product needs from each significant component; verify from supplier documentation or by test; record maintainer status and the decision.
• Output: a due diligence record per significant component, and an upstream-report log.
• Owner: the component owner verifies; the product security lead accepts or replaces.

IEC 62443-4-1:2018 expects the same of externally provided components: identify and manage their security risks, including how patches reach you and whether the component is still supported ¹⁴.

3.3 Build intake: the contact point, the policy, what a reporter is promised#

Point (6) asks the manufacturer to make it easy to share information about potential vulnerabilities in its product and in third-party components inside it, including by providing a contact address. Article 13(17) is stricter than a mailbox. The single point of contact must let users communicate directly and rapidly, and be easily identifiable. It must let them choose their means of communication, and not be limited to automated tools. Annex II item 2 puts that contact, and the policy's location, into the product information ¹⁵.

The policy is point (5), and it has to be enforced, not merely published ¹⁶. Four commitments make it enforceable: an acknowledgement interval, a triage interval, what the reporter is told, and the conditions for publishing.

• Input: the published contact details, the product documentation, the legal position for reporters.
• Activity: publish the contact point and the policy; route every report into one queue with an identifier; acknowledge inside the stated interval; record its source.
• Output: a disclosure policy, a monitored contact point, and a disclosure log.
• Owner: the product security lead, with the general counsel approving the policy text.

Control 8.8 asks the organisation to publish a contact point for reporters, inside a topic-specific policy covering how vulnerabilities are disclosed ¹⁷. IEC 62443-4-1:2018 requirement DM-1 names the minimum sources intake must accept from: testers, component suppliers, developers and product users ¹⁸.

3.4 Triage: severity, exploitability, affected versions, fix order#

Triage produces four answers. Is the report real and applicable here? How severe is the outcome? Is it reachable under practical operational conditions? Which other products and versions carry the same component? The fourth gets skipped, and the inventory from 3.1 makes it cheap. IEC 62443-4-1:2018 requirement DM-3 asks for that whole set: impact in the product's security context, severity from a scoring system, other affected versions, and root cause ¹⁹.

The Commission is direct about what a report is not. Being reported does not make a flaw exploitable in practice or applicable to the product; the manufacturer investigates and confirms. A flaw counts as known once listed in a relevant publicly accessible vulnerability database, such as the European vulnerability database. It also counts as known when it arrives through coordinated disclosure, internal testing or prominent reporting ²⁰.

One outcome deserves its own field. Where a third-party component carries a flaw that cannot be exploited in this product, or has not been, it is not an actively exploited vulnerability contained in the product, so mandatory notification does not attach. Voluntary notification stays open under Article 15, and the Part II duties and the upstream report still apply ²¹.

• Input: the report, the component inventory, the product's risk assessment, the severity scale.
• Activity: confirm applicability; score severity; assess reachability; enumerate affected versions; set fix order and target date; record the reasoning.
• Output: a triage decision carrying severity, exploitability, affected versions and an owner.
• Owner: the product security lead decides; the engineering owner supplies the reachability analysis.

Where the decision is to accept rather than fix, it belongs in the risk record. IEC 62443-4-1:2018 requirement DM-4 expects an established acceptable level of residual risk to be applied, with deferral and non-repair as recorded options ²².

3.5 Remediate, and treat the security update as an artefact with a record#

Point (2) requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed, including by providing security updates. Where technically feasible, those updates are separate from functionality updates. Point (7) requires mechanisms to distribute updates securely and in a timely manner. Point (8) requires available updates to be disseminated free of charge, with advisory messages telling users what to do ²³. Only a business user's agreement on a tailor-made product changes the charge.

Three duties reach past the release. Each update made available during the support period stays available for at least ten years after issue, or the rest of that period, whichever is longer. Where public archives of old versions are kept, users are told about the risks of unsupported software ²⁴. Article 13(10) lets a software manufacturer meet point (2) for the last version only, where earlier users can upgrade free of charge. They must not pay to adjust their environment ²⁵. Every substantially modified version still needs its own declared support period ²⁶.

• Input: the triage decision, the affected version list, the release calendar.
• Activity: build and qualify the fix; separate it from functionality changes where feasible; sign and distribute it; write the advisory message.
• Output: an update record per release, naming the product, superseded versions, the reports it closes, the mechanism and the notification date.
• Owner: the engineering lead for the product line; the release manager for distribution.

Four requirements in IEC 62443-4-1:2018 surround the same artefact: security update qualification at SUM-1, security update documentation at SUM-2, security update delivery at SUM-4, and timely delivery of security patches at SUM-5. They ask that an update be shown to fix what it claims without regressions, and that its versions and installation steps be documented. They also ask that users can check an update is authentic, and that a policy fix the timeframes ²⁷.

3.6 Disclose: what is published, when, and in what form#

Point (4) sets both trigger and content. Once a security update has been made available, the manufacturer shares and publicly discloses information about the fixed vulnerability. That means a description, information letting users identify the affected product, the impacts, the severity, and clear guidance on remediating. In duly justified cases, where the risks of publishing outweigh the benefits, publication may wait until users can apply the patch ²⁸.

That trigger is why the advisory template belongs to the release process, not to communications. Around Article 14(8) the Commission adds proportionality. Informing users does not mean publishing indiscriminately; detail may be limited to affected users where wider publication would raise risk ²⁹.

• Input: the released update, the triage record, the affected version list.
• Activity: draft the advisory to a fixed template; decide scope and timing against the delay test; publish; record the decision where publication was delayed.
• Output: a published advisory per fixed vulnerability, and a delay record where one applies.
• Owner: the product security lead publishes; the named governance authority approves any delay.

IEC 62443-4-1:2018 requirement DM-5 asks a disclosure for the same fields: description, a vulnerability score, affected versions and the resolution ³⁰.

3.7 Reporting: the Article 14 path, and the record that survives it#

The clocks are set out in the radar entry on CRA manufacturer reporting; the enterprise-side machinery is in incident governance. In short: an actively exploited vulnerability and a severe incident each go to the CSIRT designated as coordinator and to ENISA at once, through the single reporting platform. An early warning is due within 24 hours, a fuller notification within 72. The final report is due 14 days after a corrective or mitigating measure is available. For a severe incident it is due one month after the 72-hour notification ³¹. ENISA states the platform serves mandatory reporting from 11 September 2026, and voluntary reporting by anyone ³².

The seam with the incident playbook is the awareness timestamp. The Commission places awareness after an initial assessment. It is the point of reasonable certainty that the vulnerability is actively exploited, or that a severe incident compromised product security ³³. Someone records that decision, with the assessment behind it.

Three properties are easy to get wrong. Reporting continues after a product stops being supported, while the Part II duties run only for the support period. There is no retroactive reporting of exploitation known before 11 September 2026. A vulnerability known earlier becomes reportable if exploitation begins after that date ³⁴. And inside a coordinated disclosure procedure, the coordinating CSIRT may delay dissemination through the platform until the parties consent ³⁵.

• Input: the triage decision, the awareness timestamp and its evidence, the affected Member State list.
• Activity: decide whether the duty attaches; submit early warning, notification and final report; inform impacted users in parallel; keep each submission reference.
• Output: a reporting clock row per event, with three due dates, three sent dates and the reference.
• Owner: the accountable reporting role named in the incident policy, with the product security lead supplying technical content.

Article 14(8) runs beside the notifications, not after them: impacted users are told about the vulnerability or incident and the mitigating measures they can apply ³⁶.

3.8 Test and monitor on a schedule you can defend#

Point (3) requires effective and regular tests and reviews of the product's security ³⁷. The Commission's reading is the useful part. Regular does not mean repeating an unchanged campaign at fixed intervals. It means regularly reviewing whether new input, such as newly identified threats or newly discovered vulnerabilities, requires the tests to change, then running what the review calls for. Depth and content stay proportionate to the risk profile, and where the review finds no new input, no new tests need be devised ³⁸. The review is itself the evidence.

• Input: the threat picture for the product, the change log since the last review, the test set.
• Activity: review whether new input changes the test set; update and run tests accordingly; record the review even when nothing changes.
• Output: a dated test-and-review record per product, naming the input considered and the tests run.
• Owner: the engineering lead for the product line, reviewed by the product security lead.

IEC 62443-4-1:2018 supplies the test types. Security requirements testing sits at SVV-1 and threat mitigation testing at SVV-2. Vulnerability testing is SVV-3, penetration testing SVV-4, and independence of testers SVV-5 ³⁹. ISO/IEC 27002:2022 control 5.7 asks for threat information to be collected and analysed into threat intelligence. Control 8.28 extends secure coding governance to third-party and open-source components ⁴⁰.

3.9 Keep one record, not five#

Article 13(7) requires the manufacturer to document relevant cybersecurity aspects systematically, including vulnerabilities it becomes aware of, and to update the risk assessment where applicable ⁴¹. Nothing says that has to be one file. Practice says it should be: the component, the decision, the update and the notification are joined by identifiers, and identifiers resolve only inside one record. The vulnerability handling record is that file. It is where the loop closes: governance's disclosure policy, risk's triage decision and compliance's notification sit in adjacent columns, so an assessor reads one row rather than three systems.

• Input: the outputs of 3.1 to 3.8.
• Activity: hold one record; make disclosure identifiers the join key; keep clock rows even where the duty did not attach, with the reason.
• Output: the vulnerability handling record, versioned and retained.
• Owner: the product security lead.

Retention has a floor. Technical documentation stays available to market surveillance authorities for at least ten years, or the support period if longer ⁴².

3.10 Measure four things, and review the practice itself#

Time to triage, receipt to recorded decision, tests intake. Time to fix by severity tests the remediation policy against what it promised. SBOM freshness, newest record against newest shipped version, tests whether 3.1 runs. Disclosure interval, update released to advisory published, tests point (4). Targets are organisational choices.

• Input: the record from 3.9.
• Activity: compute the four measures quarterly; review open items and the process; take exceptions to the governance forum.
• Output: a quarterly metrics view and a review minute.
• Owner: the product security lead reports; the governance forum decides.

IEC 62443-4-1:2018 requirement DM-6 asks for review of the issue-management practice at least annually ⁴³. The management-system frame is product CSMS as a management system; the testing discipline is control testing and ITGC.

4. Deliverables#

Five artefacts; cadences and retention are organisational choices.

Deliverable	Produced by	Template
SBOM per product version	Step 3.1	/templates/vulnerability-handling-record, SBOM index sheet
Disclosure policy	Step 3.3	template pending
Disclosure log	Steps 3.3, 3.4, 3.6	same file, Disclosure log sheet
Update record	Step 3.5	same file, Update log sheet
Reporting clock record	Step 3.7	same file, Reporting clock sheet

The advisory is a column set rather than a sixth file: identifier, affected versions, description, impact, severity, remediation instruction, update reference and publication date.

5. What the authority and the customer will ask#

A customer's supplier assessment asks a shorter version, a year earlier.

6. Failure modes and how they surface#

All three share a root: the process is treated as a response capability rather than one that produces records, so nothing survives the moment.

7. Mapping to the standards#

Requirement wording from the licensed standard is paraphrased; identifiers and printed titles are as printed ⁴⁴. Framework identifiers and names come from Appendix A. ID.RA-01 is vulnerabilities in assets are identified, validated, and recorded. ID.RA-08 is processes for receiving, analyzing, and responding to vulnerability disclosures are established. PR.PS-02 is software is maintained, replaced, and removed commensurate with risk ⁴⁵.

Step	CRA	IEC 62443-4-1:2018	ISO/IEC 27002:2022	CSF 2.0	Evidence
3.1 Inventory	Part II (1); Art. 13(24)	SM-9: Security requirements for externally provided components	8.8 Management of technical vulnerabilities	ID.AM-02	SBOM index rows
3.2 Due diligence	Art. 13(5), 13(6), 24	SM-10: Custom developed components from third-party suppliers	8.28 Secure coding	ID.RA-09	Due diligence record
3.3 Intake	Part II (5), (6); Art. 13(17)	DM-1: Receiving notifications of security-related issues	8.8	ID.RA-08	Policy; contact point
3.4 Triage	Part II (2); Art. 13(3)	DM-3: Assessing security-related issues, and DM-4: Addressing security-related issues	8.8	ID.RA-01	Triage decision
3.5 Update	Part II (2), (7), (8); Art. 13(9) to 13(11)	SUM-1, SUM-2, SUM-4, SUM-5	8.8	PR.PS-02	Update log rows
3.6 Disclosure	Part II (4)	DM-5: Disclosing security-related issues	8.8	ID.RA-08	Advisory; delay record
3.7 Reporting	Art. 14; Art. 15; Art. 16(6)	—	5.7 Threat intelligence	RS.MA-02	Clock rows; references
3.8 Testing	Part II (3)	SVV-1 to SVV-5	8.28 Secure coding	PR.PS-06	Test-and-review record
3.9 The record	Art. 13(7), 13(13)	—	8.8	ID.RA-01	The handling record
3.10 Metrics	Art. 13(7)	DM-6: Periodic review of security defect management practice	5.7 Threat intelligence	ID.IM-01	Metrics view; minute

SM-10, SM-11 and the SVV set were read in the same licensed copy ⁴⁶. A conformity assessment tests the manufacturer's processes against Part II, alongside the product against Part I ⁴⁷.

8. Checklist#

Each item is observable. A dated row or a stored file counts; "in place" does not.

• Every shipping product version has a bill of materials, with format and depth recorded.
• The bill of materials is generated by the release pipeline, not by hand.
• A diff against the previous version exists for the most recent release of each product.
• The contact point for vulnerability reports is published, monitored and named in the user information.
• Every report carries an identifier, a source, a severity, a reachability finding and affected versions.
• Every released update has a row naming the versions it supersedes and the reports it closes.
• Every fixed vulnerability has a published advisory, or an approved reason for delay.
• Each notifiable event has an awareness timestamp with the initial assessment attached.
• The three Article 14 due dates and the three sent dates are present for every notified event.
• A dated test-and-review record exists for each product for the current period.

References#

Primary sources only. Identifiers and printed titles from the licensed standards are as printed; requirements paraphrased.

1. European Parliament and Council. Regulation (EU) 2024/2847 (Cyber Resilience Act). OJ L, 2024/2847, 20.11.2024. Annex I Part II, Annex II and Articles 3, 13, 14, 15, 16, 24, 25 and 71 read at https://publications.europa.eu/resource/celex/32024R2847 ⁴⁸
2. European Commission. Commission guidance on the application of Regulation (EU) 2024/2847, annex to C(2026) 5252, 27 July 2026. Sections 5, 7.3, 9.1 and 9.2 read at https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation ⁴⁹
3. ENISA. Single Reporting Platform. https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp ³²
4. IEC. IEC 62443-4-1:2018 — Security for industrial automation and control systems - Part 4-1: Secure product development lifecycle requirements. Clauses 5.11 to 5.13, 9.2 to 9.6, 10.2 to 10.7 and 11.2 to 11.6 read in a licensed copy; https://webstore.iec.ch/en/publication/33615 ⁵⁰
5. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. Controls 5.7, 8.8 and 8.28 read in a licensed copy; https://www.iso.org/standard/75652.html ⁵¹
6. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. Appendix A read at https://doi.org/10.6028/NIST.CSWP.29 ⁵²

Related: CRA obligations by product class for scope and the conformity route, and the radar entries on reporting and on the guidance.

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.