CRA glossary: the vocabulary from SBOM to vulnerability management

The Cyber Resilience Act (Regulation (EU) 2024/2847, CRA) is the EU product regulation for cybersecurity. It obliges manufacturers of products with digital elements to deliver secure product properties and to manage vulnerabilities over the entire support period.

Key dates: reporting obligation from 11 Sep 2026, full application from 11 Dec 2027. For plant builders it applies in parallel with the Machinery Regulation – neither replaces the other. Details in our guide for integrators and plant builders.

See also: Machinery Regulation (MR), Product with digital elements, Essential cybersecurity requirements, Reporting obligation & ENISA

The Machinery Regulation (EU) 2023/1230 (MR) is the EU product regulation for machinery; from 20 January 2027 it replaces the Machinery Directive 2006/42/EC and introduces binding, safety-related cybersecurity requirements for the first time.

For plant builders it applies in parallel with the CRA: both lead to a CE marking but protect different things – the MR protects people, the CRA protects the product. Our guide gives the full comparison.

See also: Cyber Resilience Act (CRA), CE marking & declaration of conformity, Risk assessment, Machinery Directive 2006/42/EC, Putting into service

A product with digital elements is any software or hardware product, together with its remote data processing, whose intended use includes a data connection (CRA Art. 3). This definition opens the scope of the CRA.

In practice almost every modern installation: as soon as digital elements are built in and communicate, the overall product falls under the CRA.

See also: Cyber Resilience Act (CRA), Essential cybersecurity requirements, Product classes (important / critical)

NIS2 (Directive (EU) 2022/2555) is the EU directive on the cybersecurity of operators of essential and important entities. It obliges organisations (operators), whereas the CRA obliges products (manufacturers).

A frequent confusion: the CRA concerns what you place on the market; NIS2 concerns how you, as a company, secure your own infrastructure. Plant builders can be subject to both.

See also: Cyber Resilience Act (CRA), Vulnerability management

The Machinery Directive 2006/42/EC is the current EU rule for machinery. It is fully replaced by the Machinery Regulation (EU) 2023/1230 from 20 January 2027.

Key difference: the old directive had no binding cybersecurity requirements – the Machinery Regulation introduces them and thereby interlocks with the CRA.

See also: Machinery Regulation (MR), CE marking & declaration of conformity

Placing on the market is the first making available of a product on the EU market in the course of a commercial activity (CRA Art. 3). It triggers the manufacturer obligations.

The decisive term for integrators: whoever places a system on the market under their own name is the manufacturer of the overall product — and therefore affixes the CE marking, not the other way round. Exactly when you fall into this role is explained in our guide for integrators and plant builders.

See also: Product classes (important / critical), Substantial modification, Manufacturer & economic operators, Essential cybersecurity requirements

The CRA distributes obligations across four economic operators: manufacturer (full responsibility), authorised representative, importer and distributor. The manufacturer is whoever develops a product or places it on the market under their own name (Art. 3).

Decisive for integrators: by placing on the market under your own name you fall into the manufacturer role – the role with the most obligations.

See also: Placing on the market, Cyber Resilience Act (CRA), Essential cybersecurity requirements

A substantial modification is a change to a product already placed on the market that affects its conformity or alters the risk assessment (CRA Art. 22, with an analogous concept in the MR).

The trigger at which integrators and those refurbishing equipment become the manufacturer of the changed product – with full obligations. A pure bugfix generally does not count; a new function or increased attack surface does.

See also: Placing on the market, Manufacturer & economic operators, Assembly of machinery

An assembly of machinery is a combination of several machines that work together for a common purpose and are controlled as a unit – and then counts as a single machine within the meaning of the MR.

Exactly what integrators build: anyone who combines a line or system into a functional whole and delivers it under their own name is the manufacturer of the assembly – including all bought-in components.

See also: Placing on the market, Substantial modification, Partly completed machinery, Machinery Regulation (MR)

Partly completed machinery is an assembly that almost forms a machine but cannot on its own perform a specific application (e.g. a drive system). It is not CE-marked; instead it receives a declaration of incorporation and assembly instructions.

Important for integrators on both sides: whoever supplies sub-assemblies issues a declaration of incorporation; whoever assembles them into the finished machine assumes the manufacturer obligations for the overall product.

See also: Assembly of machinery, CE marking & declaration of conformity, Placing on the market

Putting into service is the first use of a product for its intended purpose in the EU. It is distinct from placing on the market and can trigger obligations even when a product is not sold in the classic sense (e.g. an in-house build for one's own operation).

Relevant at the outer edge of plant engineering: complete installations erected only on the customer's premises are delimited via placing on the market and putting into service.

See also: Placing on the market, Assembly of machinery

The support period is the time span during which a manufacturer must handle vulnerabilities and provide free security updates under the CRA – at least five years, based on the expected use period.

This period creates the recurring effort – and for plant builders a plannable service business: integration, validation and recommissioning of the updates.

See also: Vulnerability management, Essential cybersecurity requirements, Cyber Resilience Act (CRA)

The essential cybersecurity requirements are the obligations set out in CRA Annex I: secure product properties (Part I) and vulnerability handling (Part II).

Part I requires products that are “secure by design” and “secure by default”; Part II governs handling vulnerabilities over the entire support period (SBOM, reporting channels, free security updates). Part II creates the recurring effort — and with it the need for automation. Source: CRA Annex I.

See also: Vulnerability management, SBOM, Product classes (important / critical), Cyber Resilience Act (CRA)

Risk assessment is the systematic identification and evaluation of a product's hazards. The MR requires it for the essential health and safety requirements (Annex III), including safety-relevant cybersecurity (1.1.9 protection against corruption, 1.2.1 control systems).

For the cyber dimension, a STRIDE threat analysis per system type is the usual tool – a one-off task that Werkspilot takes on.

See also: STRIDE, Safety component, Machinery Regulation (MR), Essential cybersecurity requirements

STRIDE is a threat model with six categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) for systematic risk analysis.

For the cybersecurity risk assessment required under the CRA and the Machinery Regulation, STRIDE per system type is the usual tool — a one-off task, in contrast to ongoing monitoring. Werkspilot produces these STRIDE threat analyses as part of the risk assessment.

See also: SSVC, IEC 62443, Risk assessment, Essential cybersecurity requirements

A safety component is a component that performs a safety function and whose failure endangers people (e.g. guards, two-hand controls). MR Annex I lists certain machinery and safety components as high-risk categories with a stricter conformity assessment procedure.

Anyone building such products can less often rely on pure self-declaration and may need a notified body.

See also: Conformity assessment procedure, Risk assessment, Product classes (important / critical)

The CRA classifies products with digital elements into three risk tiers: standard (self-assessment), important (class I and II, Annex III) and critical (Annex IV). The class determines the conformity assessment procedure.

Most systems fall into the standard class and allow self-declaration. “Important” products (e.g. certain industrial or network components) require stricter procedures. The classification is a mandatory step at the point of placing on the market, not an optional one.

See also: Placing on the market, Conformity assessment procedure, Essential cybersecurity requirements

The conformity assessment procedure is the route by which a manufacturer demonstrates that the requirements are met – from internal self-assessment (Module A) to examination by a notified body. Which procedure applies depends on the product class.

Most systems allow self-declaration; important or critical CRA products and high-risk machinery (MR Annex I) require stricter procedures.

See also: Product classes (important / critical), Safety component, CE marking & declaration of conformity, Harmonised standard

The CE marking declares a product's conformity with all applicable EU rules; the EU declaration of conformity is the signed document behind it. For a system with digital elements, both the MR and the CRA must be covered in it.

It is not the CE marking that makes the manufacturer – it is the other way round: whoever places on the market under their own name is the manufacturer and therefore affixes the CE marking.

See also: Placing on the market, Conformity assessment procedure, Machinery Regulation (MR), Cyber Resilience Act (CRA)

A harmonised standard is a standard listed in the Official Journal of the EU whose application triggers the presumption of conformity for the corresponding requirements. For the CRA and the MR, many of these standards are not yet listed in mid-2026.

Consequence: anyone securing themselves today relies on recognised standards such as IEC 62443 and BSI TR-03183 as the state of the art until the harmonised CRA standards appear.

See also: IEC 62443, BSI TR-03183, Conformity assessment procedure

Vulnerability management is the continuous process of identifying, assessing, handling and reporting vulnerabilities — mandatory under CRA Annex I Part II over the entire support period.

The recurring core of the CRA: not a one-off at the point of placing on the market, but daily over years. It covers SBOM upkeep, feed monitoring (CSAF to email), triage (EPSS/KEV/SSVC) and the 24-hour and 72-hour report to ENISA. This pipeline is exactly what Werkspilot automates.

See also: SBOM, CSAF, VEX, CISA KEV, EPSS, SSVC, Reporting obligation & ENISA, Support period

The CRA obliges manufacturers to report actively exploited vulnerabilities and severe incidents via a central ENISA platform: early warning within 24 hours, vulnerability notification within 72 hours, final report later (Art. 14).

The reporting obligation begins on 11 Sep 2026 – more than a year before the CE obligation and retroactively for existing installations. It is therefore the first hard deadline.

See also: Vulnerability management, CISA KEV, Cyber Resilience Act (CRA)

A PSIRT (Product Security Incident Response Team) is a manufacturer's organisational function that receives product vulnerabilities, assesses them and coordinates their handling and reporting.

The CRA effectively presupposes PSIRT functions: an intake channel (CVD), triage and on-time reporting must be organised – at the plant builder too, not only at the software corporation.

See also: Coordinated Vulnerability Disclosure, Vulnerability management, Reporting obligation & ENISA

Coordinated Vulnerability Disclosure (CVD) is the coordinated process by which third parties report vulnerabilities to a manufacturer and both align on publication. The CRA requires a point of contact and a vulnerability disclosure policy.

In practice: a reachable reporting address (e.g. security.txt) plus a defined internal workflow through to remediation.

See also: PSIRT, Vulnerability management

The CISA KEV catalogue (Known Exploited Vulnerabilities) lists vulnerabilities that are demonstrably being actively exploited.

KEV is the hardest prioritisation signal: if a CVE is in the catalogue and affects one of your systems, it triggers the targeted spot check and, in the worst case, leads to the 24-hour report to ENISA. It complements the predictive EPSS with hard evidence of actual exploitation.

See also: EPSS, SSVC, Vulnerability management

EPSS (Exploit Prediction Scoring System) is a FIRST.org-maintained score between 0 and 1 that estimates the probability that a vulnerability will be exploited within the next 30 days.

Unlike CVSS (which measures severity), EPSS estimates the probability of exploitation — useful for prioritisation when thousands of CVEs accrue. It complements the CISA KEV catalogue (already exploited) with a predictive component.

See also: CISA KEV, SSVC, Vulnerability management

SSVC (Stakeholder-Specific Vulnerability Categorization) is a decision-tree model from CISA and the CMU SEI that classifies vulnerabilities by required action (e.g. Act, Attend, Track) rather than by score alone.

SSVC often fits CRA triage better than a pure CVSS score because it combines exploit status, exposure and impact in the specific system context. In our assessment logic we combine SSVC decisions with the STRIDE threat view per system type.

See also: EPSS, CISA KEV, STRIDE

CVSS (Common Vulnerability Scoring System) is a standardised score from 0 to 10 for the severity of a vulnerability.

CVSS says how bad a flaw is in theory – not whether it is being exploited or affects your system. Prioritisation therefore also needs EPSS (probability) and KEV (actual exploitation).

See also: EPSS, CISA KEV, SSVC, CVE

A CVE (Common Vulnerabilities and Exposures) is a unique, globally referenced identifier for a specific vulnerability (e.g. CVE-2025-12345).

The common language of vulnerability management: supplier advisories, feeds and your SBOM must meet via CVE IDs, otherwise no automatic matching is possible.

See also: CVSS, EPSS, CPE & PURL, SBOM

An SBOM (Software Bill of Materials) is a machine-readable inventory of all software components of a product, including versions and dependencies.

The CRA requires an SBOM in a machine-readable format so that vulnerabilities can be mapped via CVE-capable IDs (CPE/PURL and version). Important: a hardware bill of materials is not an SBOM — only the software view enables automatic matching against supplier feeds. Common formats are CycloneDX and SPDX; content and mandatory fields are specified by BSI TR-03183 Part 2.

See also: HBOM, CSAF, VEX, CycloneDX & SPDX, CPE & PURL, Vulnerability management

An HBOM (Hardware Bill of Materials) lists a product's hardware components. It is the practical starting point but not a substitute for the SBOM.

For plant builders the realistic first step: mapping the HW BOM to firmware versions. CVE matching then still needs the software view (SBOM), because vulnerabilities attach to software versions, not to parts.

See also: SBOM

VEX (Vulnerability Exploitability eXchange) is a machine-readable manufacturer statement on whether a product is actually affected by a known vulnerability (affected, not affected, fixed, under investigation).

VEX cuts false positives drastically because the manufacturer answers the “does it affect me?” step instead of leaving it to the user. Often carried as a profile of CSAF. For plant builders, the direct supplier's product-level VEX is the strongest lever to filter the few relevant CVEs out of thousands.

See also: CSAF, SBOM, EPSS, Vulnerability management

CSAF (Common Security Advisory Framework) is the OASIS standard for machine-readable security advisories in JSON; the VEX profile is part of it.

CSAF 2.0 replaces the PDF advisory and makes supplier notifications automatable; they are distributed via ROLIE feeds. The German BSI recommends CSAF. In the DACH supplier chain it is still rare in 2026, though — the long tail delivers PDF, RSS, newsletters or nothing. Collecting everything from CSAF to email and normalising it to a single view is exactly what we automate.

See also: VEX, SBOM, ROLIE, Vulnerability management

ROLIE (Resource-Oriented Lightweight Information Exchange, RFC 8322) is a feed standard via which manufacturers make security advisories – for example in CSAF format – available for machine-readable retrieval.

Effectively the feed for advisories: via ROLIE endpoints we pull in direct suppliers' CSAF advisories automatically and continuously.

See also: CSAF, VEX, Vulnerability management

CycloneDX (OWASP) and SPDX (Linux Foundation, ISO/IEC 5962) are the two established machine-readable SBOM formats.

Both are accepted by BSI TR-03183. CycloneDX additionally covers VEX and HBOM and is more widespread in the security space.

See also: SBOM, BSI TR-03183, VEX, CPE & PURL

CPE (Common Platform Enumeration) and PURL (Package URL) are standardised identifiers that uniquely name a product or a software package together with its version.

They are the link between SBOM and CVE: only a CVE-capable ID (CPE/PURL and version) turns a bill of materials into an automatically matchable record.

See also: SBOM, CVE, CycloneDX & SPDX

BSI TR-03183 is the German BSI's technical guideline on “Cyber Resilience Requirements for Manufacturers and Products”; Part 2 specifies the requirements for SBOMs.

Part 2 specifies the format and content of an SBOM (CycloneDX/SPDX, mandatory and optional fields) and is the practical reference point for CRA-conformant software bills of materials in the German-speaking region.

See also: SBOM, IEC 62443, Vulnerability management

IEC 62443 is the international series of standards for cybersecurity in industrial automation and control systems (IACS/OT).

The series provides recognised security requirements — such as 4-1 (Secure Development Lifecycle) and 4-2 (technical requirements for components) — that can serve as evidence for CRA requirements as long as no harmonised CRA standard is yet listed in the Official Journal of the EU.

See also: STRIDE, OT / IACS, Harmonised standard, BSI TR-03183

OT (Operational Technology) or IACS (Industrial Automation and Control Systems) denotes the control and automation technology in installations – as distinct from classic office IT.

OT has its own constraints (long life cycles, availability over confidentiality, rare patch windows), which is why CRA vulnerability management looks different here than in IT. The IEC 62443 series addresses exactly this area.

See also: IEC 62443, Vulnerability management