Annex I Part II: Which eight vulnerability-handling requirements apply?
Eight duties from 11 December 2027; points 5 and 6 are needed now because of the reporting obligation since 11 September 2026.
- Point 1: identify and document vulnerabilities and components – including a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies
- Point 2: address vulnerabilities without delay, including through security updates
- Point 3: regular tests and reviews of product security
- Point 4: publish information on fixed vulnerabilities
- Point 5: a policy on coordinated vulnerability disclosure
- Point 6: a contact address for vulnerability reports
- Point 7: secure mechanisms for distributing updates
- Point 8: distribute security updates without delay and free of charge
These requirements apply from 11 December 2027 to new products and to legacy products after a substantial modification. In practice a manufacturer needs points 5 and 6 today, because otherwise it cannot meet the reporting obligation that has applied since 11 September 2026 – the deadline does not change, the order of work does.
What must the software bill of materials (SBOM) contain?
Components with names, versions and dependencies, at least the top level, in a machine-readable format such as SPDX or CycloneDX, kept for ten years.
| Question | Answer under the CRA and the guidance |
|---|---|
| What must it contain? | Components with name and version, precise enough to match against vulnerability databases; origin (commercial/open source); dependency relationships. The SBOM must be updated when vulnerabilities are fixed. |
| Which format? | A “commonly used and machine-readable format”. SPDX (ISO/IEC 5962) and CycloneDX (ECMA-424) are the established options; the CRA prescribes neither. BSI TR-03183 Part 2 specifies formal requirements. |
| How deep? | At least the top-level dependencies. Transitive dependencies are advisable: a vulnerability in an undocumented transitive component remains a vulnerability of the product. |
| Who receives it? | No publication obligation. The market surveillance authority may request it on reasoned request (Art. 13(25)); for Class I and II the notified body reviews it. |
| How long to retain? | Technical documentation including the SBOM and the EU declaration of conformity for at least ten years after placing on the market or for the support period, whichever is longer (Art. 13(13)). |
Which duties apply to third-party components?
Art. 13(5) requires due diligence when integrating third-party components, including open-source software: they must not compromise the security of the product. Art. 13(6) is regularly overlooked because it is not a channel to the authority but to the supplier: if the manufacturer identifies a vulnerability in a component, it reports it to the person or entity maintaining the component – and fixes it itself where it can.
1. Which legal entity, which product and which version does your statement cover? 2. How do you justify your CRA role and the product boundary considered? 3. In which format and at what rhythm do we receive the SBOM for the shipped version? 4. How do you inform us about actively exploited vulnerabilities – fast enough for our 24-hour early warning? 5. Which support commitments and advance notices for discontinuations exist? 6. Who delivers which reliable information in an incident via which contact route? For DORA, the institution's own provider assessment remains; a certificate is a source of information, not a substitute.
Open source: When does the CRA apply?
Where there is commercial activity. Art. 24 and 25 CRA contain a light-touch regime for open-source software. Its addressee is the open-source software steward: a legal person supporting the development of open-source software intended for commercial activities without being a manufacturer itself. It owes a documented cybersecurity policy, vulnerability handling and cooperation with authorities; under Art. 64(10)(b) it is fully exempt from fines. The dividing line does not run between open source and proprietary but between commercial activity and its absence: sharing source code in a public repository is normally not placing on the market; whoever makes the same software available in the course of a commercial activity is a manufacturer. For an institution that publishes internally maintained libraries, this is where it checks whether it becomes a steward itself.
Why does ISO 27001 save work but no obligation?
The sentence “we are certified to ISO/IEC 27001, so the CRA is largely covered” conflates two levels: the level at which a framework saves work, and the level at which it triggers a legal consequence. A legal consequence – the presumption of conformity under Art. 27 – is triggered only by a harmonised standard whose reference is cited in the Official Journal, or by a certification scheme designated by delegated act. Both are missing as of this page's status date. ISO/IEC 27001, IEC 62443, ISO/IEC 29147 and 30111 carry no legal consequence but evidential value: they deliver the processes and records that Annex VII point 5 requires.
Where no harmonised standard is applied, the technical documentation must describe the other solutions adopted to meet each requirement of Annex I. The obligation thus moves from the standard to individual proof. Whoever could apply a standard refers to it; whoever cannot sets out evidence per requirement and per product. Market surveillance asks for the evidence for the Annex I requirement, not for the certificate for the management system (Art. 13(22)). A product file linking product version, component status, risk assessment, tests and releases is therefore worth more today than any claim of standard conformity.
How is the SBOM used in practice?
A bank checks a library warning against its SBOM; an insurer requests a component list with build reference from its supplier.
A warning names several library versions. The SBOM for the shipped app version shows which version is included; the vendor's statement evidences whether exploitation is known. Only from that follows the decision: remediation under Annex I Part II point 2, feedback to the component vendor under Art. 13(6) – and only in case of active exploitation the early warning under Art. 14.
The claims-app vendor delivers a component list without a build reference. It does not meet Annex I Part II point 1 because it does not match the shipped version. Result: a demand with format, identifiers and update rhythm – as a contractual obligation, not a request.
Frequently asked questions
Is SPDX or CycloneDX legally mandatory?
No. The CRA requires a commonly used, machine-readable format; SPDX and CycloneDX meet that. The Commission may prescribe formats by delegated act; it has not done so.
Must the SBOM be published?
No. It is part of the technical documentation and must be provided to the market surveillance authority on reasoned request. Contractual disclosure to customers is a separate matter.
Is an ISO 27001 or IEC 62443 certificate sufficient as CRA evidence?
It saves work but triggers no presumption of conformity. The presumption requires a harmonised standard cited in the Official Journal or a designated European certification scheme – neither exists as of this page's status date.
Is an SBOM the same as the AI inventory?
No. The SBOM describes the components of a product, the AI inventory the AI systems used by the institution. The two should be linked but not merged.
Ing. Mag. Patrick Eiler
Patrick Eiler advises banks and insurers in Vienna on regulatory reporting, data architecture and AI compliance. More than twenty years in banking, insurance and financial services; speaker at the Hypo-Verband (expert session of 23 September 2026).