CRA tool selection for plant builders: four questions and one test for the demo

Vulnerability-management tools are predominantly built for software vendors that write their own code. A plant builder's risk sits almost entirely in third-party firmware across a long tail of suppliers. Werkspilot is built for this second case; the four selection questions below are kept neutral and work to probe any vendor, us included.

Software vendors and plant builders solve two different tasks

From 11 September 2026 the reporting obligation under Article 14 of the Cyber Resilience Act takes effect; deadlines and obligations are covered in a separate article. Before selecting a tool, it is worth clarifying which of two tasks "CRA vulnerability management" refers to.

A software vendor builds its product itself; its vulnerabilities sit in open-source libraries pulled into its own build. For that there is a mature toolbox: SCA, SBOM generation from the build, matching against CVE databases, VEX for status statements. Many plant builders already have this part under control for their own software development, for example with Dependency-Track.

A plant builder builds its product largely from purchased parts: PLCs, HMIs, drives, industrial PCs and sensors from Siemens, Beckhoff, B&R, SICK, Pilz, Phoenix Contact, Schneider, Rockwell and dozens of smaller suppliers. Its own safety-critical code is the smaller part, and the purchased firmware has to be monitored across 15 to 20 years in the field. Its core question therefore reads: How do you learn of a vulnerability in a purchased component, and which of your delivered systems are actually affected?

Dependency-Track covers your own build, not the purchased parts

Dependency-Track stands in here for the whole tool class: accept an SBOM from your own build, match its packages against CVE databases. With purchased parts, the preconditions for that are missing.

• No PURL, no reliable CPE. Matching against CVE databases runs on package identifiers: PURL for ecosystem packages, CPE for the NVD. Purchased firmware has neither. There is no package ecosystem that would give it a PURL, and CPE coverage is patchiest for the smaller manufacturers where the risk sits; on top of that, a noticeable share of new CVEs has received no CPE at all since early 2024. No identifier, no match.
• No SBOM, no build. For a purchased PLC or a safety laser scanner there is no build of your own, and the component manufacturer rarely ships an SBOM. What you have is a part number and a firmware level. Hand-building a device SBOM from that (CycloneDX can express it) only moves the problem to the matching.
• No installed base. Delivered systems with differing firmware levels, retrofits and 15 to 20 years in the field have no place in a model of software projects and their dependencies.

If you use Dependency-Track for your own software development, keep it. It just does not answer the purchased-parts question.

A single supplier: 821 advisories, over 5,000 CVEs, no CPE

The public Siemens CSAF feed contains 821 advisories with over 5,000 distinct CVEs as of July 2026. That is one supplier, and one doing it exemplarily: machine-readable, signed, automatically ingestible. Nobody reads that volume on the side.

At the same time, this feed contains no CPEs and no PURLs at all. An affected product is listed as "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (6ES7518-4AX00-1AB0)", identified by its article number, with version ranges in Siemens' own notation. So a purely CPE-based tool cannot use even the industry's most exemplary advisory feed: it fails on the identifier, not on the format.

A typical system also contains components from dozens of further manufacturers, and few of them do it like Siemens. Machine-readable feeds in the CSAF 2.0 format are the top of the portfolio: the many smaller component suppliers send advisories by PDF, by email to a distribution list, or publish them scattered across their own website. Aggregators such as CERT@VDE fill part of the gap. With these suppliers, a tool's coverage is hardest to judge and matters most.

Matching runs on manufacturer, article number and firmware level

A binary analysis is strong when you want to look deep inside a single firmware and uncover its components without manufacturer data; its justification lies with Linux-based devices with their own build. An advisory-centric approach of manufacturer advisories, aggregators and active capture of the smaller manufacturers carries when the risk is spread across many purchased suppliers. Components are then linked through the manufacturer's own product identification: part numbers and product trees as they appear in CSAF advisories, with version ranges in the manufacturer's own logic.

That is not a stopgap until the catalogues get better. Which OpenSSL sits inside the firmware of an S7-1500 is something only Siemens knows; the plant builder cannot know it and does not have to. The component manufacturer knows its internal bill of materials, does the assessment itself and reports the result at product level, say "CPU firmware before V3.1.5 affected". Manufacturer, article number and firmware level are therefore the only level at which you can have data of your own. Better CPE matching would not change that.

Four questions for the tool selection

The order reflects the priority in series and special-purpose machine building. None of the four questions can be answered from a data sheet.

1. Data gets in and back out without retyping

The most expensive wrong purchase is a tool that stands beside the existing systems and has to be maintained by hand. The usual counter-question about an off-the-shelf PLM/ERP connector rarely gets you far: for your specific system landscape it almost never exists, and what sales promises often turns into custom work in the project. Two simpler checks are more reliable. In: do system and bill-of-materials data get into the tool without retyping, and does an Excel or CSV export from the ERP suffice? Out: is there a documented API or export through which results and status flow into the ticketing system (Jira, ServiceNow) and your own reporting? If both ways are open, the tool will not become a silo, even without a connector catalogue.

2. Installed base: as-delivered state plus service history, not a live inventory

This is where most projects fail; the firmware matching in question 3 is technically the easier end. Which firmware levels are running in the delivered systems today, after 15 years in the field, after retrofits and after on-site updates by the operator, the plant builder does not know. After delivery the machine is in the operator's hands, often without remote access. A permanently current field inventory across 200 systems and 15 years is a fiction; a tool promise suggesting otherwise should make you sceptical.

What is reliable is the as-delivered state: a network scan at acceptance (FAT) or commissioning records which components with which firmware level actually left with the machine. After that, the machine changes from your perspective only at your own touchpoints: service call, retrofit, spare-part delivery. Three things to check in the selection meeting:

• How does the existing base get into the tool initially: from ERP, PLM, Excel or the hardware export of the engineering project (in the TIA Portal, the CAx export)? Which tools cover this capture is shown in the article on SBOM tools for plant builders.
• Are service call, retrofit and component swap tracked as events, so the data gets better with every customer contact?
• Is a product series maintained as a single model and installed at many customers, or does each system have to be updated individually?

3. Firmware matching: which systems are affected, not just whether

A tool can answer an advisory on two levels. The first: "there is an advisory for product X." Even that presupposes it maps the advisory to one of your products at all, which is precisely where CPE-based tools fail on supplier firmware (see above). The second level saves the actual work: which of your systems run the affected version.

An example. Your supplier reports on a safety laser scanner: affected up to and including firmware 2.4.7, fixed from 2.5.0. The device has been installed across several series over eight years and delivered to around 200 operators, some on 2.3.x, some on 2.4.x, a portion long since updated to 2.6.x.

• Answer on the first level: affected. What follows is the manual work of finding the systems with an affected firmware among the 200.
• Answer on the second level: 140 systems affected (firmware 2.3.x–2.4.7), 60 not affected (already ≥ 2.5.0), broken down by series and operator. Only that is a work list for the service organisation.

The test in the demo: feed in an advisory for a really installed component at a specific version level and look at what the tool flags: exactly the affected systems and series, or just the product name. The test takes five minutes and can be repeated with every vendor.

4. Impact assessment with exportable justification and VEX

AI-assisted triage speeds up the work, but the CRA requires documentation: for every hit it must remain traceable on what basis (component, version, source) the decision was made, and the justification has to be exportable for the audit. For many plant builders the more important output is the reasoned "not affected" anyway, as a machine-readable VEX statement that can be passed on to end customers from automotive and aerospace and their own NIS2 obligation. A human has to be able to override the AI assessment, audit-proof with user and timestamp, and the AI processing should run in an EU region.

Reporting and operation

Less often the sticking point, but part of the selection:

• Reporting support. Deadline tracking across 24 h / 72 h / 14 days with escalation and preparation for the ENISA reporting platform, cleanly separated between authority notification and customer information.
• Operation and economics. EU data residency, an operating model that fits your own IT policy, and a pricing logic that fits the size of your installed base.

A pilot with two or three systems instead of a data-sheet comparison

The most robust path is a short pilot with two or three real systems from your own inventory. On your own data it shows whether the integration holds, whether the installed base can be represented cleanly and whether the firmware matching delivers what the demo promises.

The fastest way in: bring the bill of materials of a single system, we scan it for open vulnerabilities. An Excel export from the ERP is enough, no SBOM and no particular format required. In the call you see which of your components have open advisories and where the firmware level decides whether you are affected, that is the matching from question 3 on real data. Bring a bill of materials to the call.

Werkspilot monitors supplier advisories automatically and matches them against the installed base of plant builders and integrators. This article reflects Werkspilot's assessment and does not constitute legal advice.