In brief · As of September 2026
No supplier is obliged to send you machine-readable security advisories. The Cyber Resilience Act prescribes a format only for the SBOM (Annex I Part II(1)), not for advisories; the draft harmonised standard prEN 40000-1-3 makes human-readable publication the base requirement and CSAF a risk-based enhancement. The duty to detect and assess vulnerabilities in bought-in components, and to report them within 24 hours — in force since 11 September 2026 — still rests with the plant builder (Art. 13, Art. 14). In practice: stop waiting for CSAF, record the actual channel for each supplier, and normalise every advisory onto one common grid.
Almost every conversation about supplier monitoring arrives at the same point: the large suppliers have CSAF, the rest will follow. The first half is true. The second is a hope, and it has no basis either in the regulation or in the current draft standard.
The BSI's public CSAF list holds 15 entries, eight of them industrial
There is a public reference for this. Germany's BSI maintains a CSAF list at wid.cert-bund.de in which manufacturers can register as providers. A retrieval on 10 September 2026 returns 15 entries. Two of them are coordinators – the BSI itself and the US agency CISA. That leaves 13 manufacturers, and of those the ones relevant to machine and plant engineering at all are: Siemens, Schneider Electric, ABB, SICK, Hitachi Energy, KUNBUS, Nozomi Networks and IDS Innomic. Eight.
That list is not the whole world: a manufacturer can publish CSAF without being registered there, and industry CERTs bundle advisories from further manufacturers. It does not change the order of magnitude. Set it against a typical plant bill of materials – controllers, drives, sensors, industrial PCs, network and safety equipment – with components from dozens of suppliers per installation. The supplier publishing machine-readable advisories is not the rule with a few laggards. It is the exception.
The CRA prescribes no format for advisories
This is not negligence on the manufacturers' part; it is the legal position. Annex I Part II(4) CRA obliges manufacturers, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities, including a description, information allowing users to identify the affected product, the impact and the severity. About the form, it says nothing.
A format requirement appears in the CRA in exactly two places, and neither targets your supplier's advisory:
- Annex I Part II(1) requires the software bill of materials in a "commonly used and machine-readable format" – that concerns the SBOM, not the advisory.
- Art. 13(6) requires a manufacturer that has developed a fix for a third-party component to share the code or documentation with that component's manufacturer, "where appropriate in a machine-readable format". That duty runs from you towards the supplier, not the other way round.
The draft standard does not make CSAF mandatory either
The usual objection: what the CRA leaves open, the harmonised standard will settle. The draft in question is prEN 40000-1-3 (CEN/CENELEC JTC 13) on vulnerability handling under Annex I Part II. It separates two levels:
- Base requirement: information regarding fixed vulnerabilities shall be made available in a human-readable format.
- Requirement enhancement: made available in a widely recognised machine-readable format – with an explicit reference to CSAF 2.0 (ISO/IEC 20153:2025).
The draft deliberately makes these enhancements risk-based: whether they apply is determined by the risks of the individual product. A proximity switch is therefore held to a different standard than a firewall. The draft is also not yet final – but its direction is unambiguous, and it does not point towards making CSAF universally binding. Planning your process on the assumption that every supplier will deliver CSAF within two years means planning against the text of the standard.
The obligation nevertheless remains entirely yours
The absence of a format requirement brings no relief; quite the opposite. Anyone placing a system on the market under their own name, and thereby becoming the manufacturer, carries responsibility for the overall product. Four provisions interlock:
- Art. 13(5) – exercise due diligence when integrating components sourced from third parties.
- Art. 13(6) – report a vulnerability found in an integrated component to its manufacturer and handle it in line with Annex I Part II.
- Art. 13(7) – document all relevant cybersecurity aspects systematically, "including vulnerabilities of which they become aware and any relevant information provided by third parties".
- Annex I Part II(2) – address and remediate vulnerabilities without delay.
Art. 13(7) is the underrated one. "Any relevant information provided by third parties" is precisely the supplier advisory – including the one attached as a PDF. Such a PDF in a service engineer's personal mailbox is not systematic documentation. The channel is therefore not only a technical problem but an evidence problem.
Then there is the clock. From 11 September 2026 (Art. 71(2)) Art. 14 applies: 24 hours for the early warning to the coordinating CSIRT and ENISA, 72 hours for the vulnerability notification itself, and a final report no later than 14 days after a corrective or mitigating measure is available. The deadline runs from your own awareness. A supplier that informs you late does not shorten your deadline – but it does shorten the time you have to assess.
The channel decides the degree of automation, not the format
Rather than sorting suppliers into "has CSAF" and "has no CSAF", the useful classification is by channel, because the channel decides how much can be automated:
- CSAF over a retrievable feed – via ROLIE or a directory structure: machine-readable, fully retrievable, changes detectable. The ideal case – and the rare one.
- RSS/Atom or an advisory index page with stable structure: retrieval can be automated, the content stays prose. Product mapping only happens during processing.
- Mailing list or security newsletter: technically simple, but effective only if someone actually subscribed – and if the subscription does not sit with a person who may leave the company.
- PDF to a single address, or a customer portal behind a login: no external retrieval possible. Here it is organisation that decides: who receives it, who records it, what happens during holidays.
The most expensive channel is none of these four – it is the fifth: the supplier whose channel nobody knows. As long as it is not documented per supplier where its advisories appear, "we have no open vulnerabilities" is not a finding but an assumption.
The draft standard supplies the grid every advisory is normalised onto
The draft standard incidentally supplies the answer to the format problem. prEN 40000-1-3 requires any publication – human-readable or machine-readable – to contain at least:
- description of the vulnerability
- vulnerability identifier (usually a CVE number)
- information allowing identification of the affected product
- potential impact
- severity
- detailed remediation information
- release date and update date
These seven fields are the lowest common denominator of every advisory, whatever the transport. Build your vulnerability management on exactly this grid and a CSAF file and a manually transcribed PDF can be handled in one workflow and reported in one document. Your own exploitability statement belongs alongside it – VEX is the format for that, and that statement is yours to make, not the supplier's.
The real bottleneck is the identifier, not the format
A warning here, because tool demos routinely gloss over it: even a perfectly machine-readable advisory is useless if the affected product cannot be mapped onto the component you actually installed. Industrial advisories identify products by article number and vendor-specific version notation, not by CPE or PURL. Matching therefore runs on manufacturer, order number and firmware level – covered with figures in the article on tool selection. So if you want to get something out of a supplier, do not ask for CSAF first – ask for unambiguous order numbers and version ranges in the advisory.
Four requests to suppliers are worth making, a format change is not one of them
Four things are worth asking for, in this order:
- The feed or index page URL – asked once, usable indefinitely. The cheapest win available.
- Distribution to a functional mailbox rather than to an individual.
- Order number and affected version ranges spelled out in the advisory.
- The seven mandatory fields above as minimum content, written into the framework agreement.
With a supplier accounting for a low single-digit percentage of your purchasing volume, however, a contract clause carries little leverage. Hence: the channel you control yourself is worth more than the commitment you cannot enforce.
Three steps make the monitoring hold up
- Derive the supplier list from the SBOM, not from purchasing. Purchasing knows contracting parties; the bill of materials knows installed components – including the manufacturer behind a distributor.
- Establish and document the channel once per supplier. Feed URL, mailing list, portal or "nothing found" – that last one is a result too and belongs on file.
- Normalise what arrives, map it to installations, document the assessment. Only this step turns incoming advisories into the systematic documentation Art. 13(7) requires.
Waiting for CSAF is therefore not a strategy, because neither the regulation nor the draft standard requires it across the board. What makes monitoring dependable is duller – a complete supplier list, a documented channel per supplier, and one common grid in which PDF and CSAF can sit side by side.
See supplier monitoring in a demo →
Werkspilot captures supplier advisories from CSAF to email, matches them against the installed base and documents the assessment in an auditable form. This article reflects the state of the regulation at the time of publication and is not legal advice. The regulatory texts themselves are authoritative; prEN 40000-1-3 is a draft standard and not yet in force.
