CRA, CE, and asset discovery for machinery

What applies to machine builders from 2027?

The main obligations under the Cyber Resilience Act apply from 11 December 2027. Reporting duties for actively exploited vulnerabilities and severe security incidents start on 11 September 2026. A machine builder first needs to determine which machine, component, or software product qualifies as a product with digital elements within the scope of the CRA.

The CRA generally covers hardware and software products made available on the EU market where the intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. A machine builder is a manufacturer under the CRA when it places such a product on the market under its own name or trademark. Product scope, supply-chain role, and possible sector exclusions therefore need to be recorded for each product family.

Is an automated component inventory a prerequisite for CE marking?

No. Neither the CRA nor the Machinery Regulation states that a complete automated inventory of every device on the machine network is a standalone CE prerequisite. Before a product is placed on the market, the CRA requires a cybersecurity risk assessment, technical documentation, the applicable conformity assessment procedure, an EU declaration of conformity, and then the CE marking.

The BSI also treats these tasks separately: Part 2 of TR-03183 describes formal and technical requirements for SBOMs, while product risk assessment and general manufacturer obligations are covered in a separate part. A current OT asset inventory is therefore supporting technical evidence. It does not replace the SBOM, risk assessment, testing, or declaration of conformity.

Which evidence do machine builders need to establish?

Machine builders need a traceable chain from the defined product and cybersecurity risk assessment to technical controls, test results, and vulnerability processes. This documentation needs to exist before the product is placed on the market and remain current throughout the support period.

• Product scope and risk assessment: document intended use, interfaces, network connections, data flows, threats, and justified protective measures.
• Components and supply chain: exercise due diligence for third-party components and maintain software dependencies in an SBOM.
• Technical documentation: connect architecture, design, development, production controls, applied requirements, testing, and vulnerability-handling processes.
• Conformity and CE: complete the applicable assessment procedure, draw up the EU declaration of conformity, and only then affix the CE marking.
• Support and vulnerabilities: define the support period, provide security updates, process reports, and assess whether individual product versions are affected.

The EU Machinery Regulation applies separately from 20 January 2027. It includes its own cyber-safety requirements for compliance-relevant software and data and for the safety and reliability of control systems. Relevant legitimate or illegitimate interventions in hardware, software, or configuration need to be made traceable. These requirements need to be distinguished from CRA conformity and deliberately brought together within the CE project.

Why is an SBOM not enough for a machine network?

An SBOM describes which software components belong to a defined product or software version. It does not automatically show which controllers, HMIs, industrial PCs, drives, or network devices are actually installed and communicating in a specific machine, or whether they are running a different version.

• SBOM: the machine-readable composition of software and its dependencies. It does not automatically state whether a vulnerability exists or is exploitable.
• OT asset inventory: the observed estate, including manufacturer, model, role, physical location, IP and MAC address, protocols, ports, firmware or software version, and serial number where available.
• Vulnerability information: dynamic CVEs and manufacturer advisories that need to be matched to product, software, and firmware versions.
• Conformity evidence: the documented assessment of why a specific version meets the applicable requirements and how identified risks are treated.

Where do visibility gaps emerge below the PLC?

A PLC is not a legally defined visibility boundary. In practice, however, conventional IT scans can stop at routing boundaries, industrial gateways, segmented cells, or non-IP field connections. A higher-level system may then see only imported records or directly reachable network participants, not necessarily every component in the machine.

CISA therefore recommends combining physical inspection and logical survey with detailed digital and network-based information, while also including documented assets and infrastructure dependencies. No single collection method automatically produces a complete view for every machine architecture.

• Passive network visibility only identifies devices and relationships that actually communicate in the observed segment.
• Active queries only reach approved targets and return only the attributes that the device and protocol expose read-only.
• Non-IP components or devices encapsulated behind gateways require additional engineering, gateway, or manufacturer data.
• Firmware version, hardware revision, and serial number therefore need a recorded source and collection time. They are not universally guaranteed scan results.

How does secnostic sensor support the evidence chain?

secnostic sensor supplies controlled observations from endpoints and networks and reconciles the documented estate with technical reality. It is a data source for risk, change, and vulnerability processes, not a tool that creates CRA conformity or CE marking on its own.

1. Observe the machine segment passively

   Mirrored network traffic exposes active devices, services, and communication relationships without sending packets to the devices. New or previously unknown network participants become reviewable changes.

2. Collect approved OT facts read-only

   For explicitly permitted targets, controlled read-only protocol queries, for example via OPC UA or Siemens S7, can add identity and version hints. Collection is limited to what the particular device and protocol actually expose.

3. Combine evidence with provenance

   Each finding retains its source and confidence. Passive observation, approved querying, engineering records, and existing inventory data can therefore be distinguished and validated deliberately.

4. Reconcile intended and observed state

   Product structure, approved components, SBOM, and recorded firmware versions are compared with the observed machine inventory. Deviations become concrete review or change tasks within the accountable process.

Where should machine builders start now?

The useful starting point is not a broad scan but a bounded product and a clear evidence chain. This makes asset discovery part of development and change control instead of an isolated inventory list.

1. Define products and roles

   Record the digital elements, network connections, remote services, and third-party components belonging to each product family, together with who carries the manufacturer obligations.

2. Map CRA and Machinery Regulation separately

   Connect applicable requirements, risk assessments, tests, and evidence in one CE file without treating the two legal regimes as identical.

3. Generate an SBOM for each software version

   Capture software dependencies from the build process in a machine-readable format and link them to the product version, release, and vulnerability process.

4. Build an OT inventory for each reference architecture

   Define manufacturer, model, role, interfaces, protocols, firmware or software version, serial number, and source as target attributes, then verify what each device type can expose.

5. Make change traceable

   Check new devices, divergent versions, and new communication paths against approved baselines and record the decision, accountable person, and time.

6. Test the evidence chain on one machine type

   Start with a representative machine and verify that the product file, SBOM, observed estate, vulnerability assessment, and change history form a consistent evidence chain.