Cyber Resilience Act for machine builders: who it affects and what to do

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, was published in the Official Journal of the European Union on 20 November 2024. It is not a directive that needs transposition: it is a regulation, directly applicable in every Member State. Its subject matter is products with digital elements placed on the EU market, and its purpose is to ensure that these products are designed, developed and maintained with minimum cybersecurity requirements throughout their entire lifecycle.

For anyone building industrial machines, plants, automation cabinets or OT systems destined for the European market, the CRA introduces concrete obligations on top of those already imposed by the Machinery Directive (and the new Machinery Regulation 2023/1230). The difference is that this time the focus is not on mechanical or electrical safety, but on the cybersecurity of the product and its digital components.

What counts as a "product with digital elements"

The CRA defines a "product with digital elements" as any software or hardware product — together with related remote data processing solutions — that includes a direct or indirect data connection to a device or network. The definition is broad and intentionally technology-neutral.

For a machine builder, this means the following types of components fall within the regulation's scope, among others:

• PLCs and controllers with network interfaces (Ethernet, Profinet, EtherNet/IP, Modbus TCP, OPC UA)
• HMIs and operator panels with network connectivity or USB ports
• Industrial IoT gateways, edge controllers, data collection devices
• Connected sensors and actuators (IO-Link, sensors with Ethernet interfaces)
• Embedded software and firmware running on the components above
• Stand-alone software shipped with the machine: SCADA applications, configuration interfaces, diagnostic tools
• Network components built into the machine: industrial switches, access points, dedicated firewalls

Identical spare parts for products already placed on the market before the regulation applies are excluded, as are products already covered by sector-specific regulation (medical devices, aviation, motor vehicles), provided that regulation imposes equivalent cybersecurity requirements.

Product classification: default, Class I and Class II

The CRA provides three classification levels, each with a different conformity-assessment procedure:

The most common industrial products — general-purpose PLCs, standard HMIs, non-critical industrial switches — will usually fall into the default or Class I category. Products performing critical safety or infrastructure-control functions may qualify as Class II, but classification must be checked case by case against the regulation's annexes.

For machine builders, the practical point is that the conformity procedure depends on the classification of the integrated digital components. A general-purpose PLC, for instance, is not automatically a Class II product, but an industrial control system intended for critical infrastructure may well be.

Essential cybersecurity requirements

Annex I of the CRA lists the essential requirements that every product with digital elements must satisfy. These are security objectives, not point-by-point technical specifications. The manufacturer must achieve them through appropriate means. The main ones:

Product requirements (Annex I, Part I)

• Security by design: the product must be designed and developed with a level of security appropriate to the risk, including attack-surface reduction
• Secure default configuration: no factory-wide identical passwords, unnecessary services disabled, restrictive settings as the initial state
• Protection against unauthorised access: authentication mechanisms, access control, protection of stored and transmitted data
• Software integrity: the product must ensure the integrity of its own firmware and software, including updates
• Data minimisation: the product should only process data necessary for its operation
• Availability: the product must be designed to limit negative impact on the availability of services provided by other devices or networks
• Updatability: the product must be able to receive security updates, preferably automatically or through simple mechanisms for the user

Vulnerability-handling requirements (Annex I, Part II)

• Identification and documentation of vulnerabilities and product components, including a Software Bill of Materials (SBOM)
• Timely handling and remediation of known vulnerabilities, with distribution of security updates
• Regular security testing and code review
• Coordinated disclosure of information about remediated vulnerabilities
• Reporting mechanism enabling third parties to communicate vulnerabilities to the manufacturer

For machine builders, these requirements change the way the product lifecycle is managed. Delivering a working machine and closing the project is no longer enough: a process must be in place to handle vulnerabilities, distribute patches and maintain transparency about the product's software composition.

The SBOM: why it matters and what it entails

Among the most tangible CRA obligations is the preparation and maintenance of a Software Bill of Materials (SBOM) — a structured inventory of every software component in the product, including third-party libraries, open-source modules and indirect dependencies.

For a machine builder, this means having a clear map of all the software running on the machine and its digital components: from PLC firmware to HMI panel libraries, from gateway operating systems to diagnostic-tool packages.

In practice, producing an accurate SBOM is far from straightforward. Many builders have limited visibility into the embedded software of the components they source from third parties. A PLC from a global vendor contains a real-time operating system, communication stacks, cryptographic libraries and middleware whose details the machine builder often does not know. The same applies to HMIs running embedded Windows or Linux, gateways with complex software stacks, and sensors with proprietary firmware.

The CRA does not ask the machine builder to reverse-engineer the PLC firmware, but it does require documenting the known software components and having a process to collect relevant information from suppliers. This shifts the relationship with component vendors: SBOM data from suppliers becomes a procurement criterion, or at least structured statements about software composition become necessary.

Vulnerability-reporting obligations

The CRA introduces a mandatory requirement to report actively exploited vulnerabilities. The manufacturer must notify the designated CSIRT (and ENISA) within 24 hours of becoming aware of an actively exploited vulnerability affecting its product. A more detailed notification must follow within 72 hours.

This obligation has direct operational consequences for machine builders. It requires:

• a structured vulnerability-monitoring process across the product's components
• an internal (or contracted external) capability for vulnerability analysis and triage
• a pre-established communication channel with the national CSIRT
• a procedure to determine whether a vulnerability found in a third-party component (for example, in the firmware of a PLC integrated into the machine) is relevant and must be reported

For many SMEs in the machinery sector, these capabilities either do not exist today or are rudimentary. The CRA expects them to be in place before the reporting obligations take effect.

Application timeline

The regulation entered into force on 10 December 2024, twenty days after its publication in the Official Journal. However, the obligations apply in stages:

This means that for products placed on the EU market from 11 December 2027, the manufacturer must demonstrate compliance with CRA requirements. For products already on the market before that date, the regulation applies only if the product is substantially modified.

The window is not as wide as it looks. Adapting development processes, vulnerability management, documentation and supply-chain relationships takes time, especially for organisations starting from scratch.

Relationship with the Machinery Regulation 2023/1230

The new Machinery Regulation (EU) 2023/1230, replacing Directive 2006/42/EC, introduces explicit cybersecurity requirements for the first time for machines whose safety functions depend on software or connectivity. The CRA sits alongside the Machinery Regulation without replacing it.

In practical terms, for an industrial machine builder the situation is as follows:

• The Machinery Regulation deals with safety and, from 2027, includes protection against corruption of safety functions caused by cyberattacks
• The CRA deals with the cybersecurity of the digital product as a whole: secure design, vulnerability management, updates, SBOM, reporting

The two regulations have different scopes but overlap where the machine integrates digital components with safety functions. Machine builders will need to manage both regulatory tracks in a coordinated manner.

It is worth noting that Article 2(2) of the CRA explicitly excludes from its scope products already subject to sector-specific regulation that imposes at least equivalent cybersecurity requirements. However, the Machinery Regulation is not among those exclusions, because its cybersecurity requirements are limited to protecting safety functions and do not cover the full spectrum of the CRA. Consequently, digital products integrated into a machine remain subject to the CRA as well.

What a machine builder needs to do in practice

Translating the CRA into operational actions requires work on several fronts. Not everything needs to happen immediately, but it helps to have a clear picture of what is needed and where you stand today.

1. Map the digital components in the machine

The first step is knowing which components in the machine fall under the definition of "product with digital elements". For every connected component — PLC, HMI, gateway, switch, software — a record should document: function, network interfaces, software present, supplier, CRA classification (default, Class I, Class II).

This exercise should cover the entire range of machines in production, not just new models. If a model is substantially modified after 11 December 2027, it may come within the CRA's scope even if the original design predates the regulation.

2. Verify compliance of purchased components

Many machine builders do not manufacture the PLCs, HMIs or gateways themselves. They buy them from automation vendors and integrate them. The CRA requires that components intended for integration also be compliant. This means the builder will need to:

• verify that component vendors are working towards CRA compliance
• request conformity declarations, SBOM data and information about update policies
• assess vendor response times for security updates
• define contractual responsibilities for vulnerabilities in components

Not all vendors will be equally ready. Some major PLC and HMI manufacturers have already begun compliance programmes; others, especially around niche components or embedded firmware, may be behind. It pays to start asking the questions now.

3. Build cybersecurity into the development process

The CRA requires cybersecurity to be part of the product development lifecycle, not a bolt-on check at the end. For a machine builder, this translates into:

• cybersecurity risk assessment during design (threat modelling, even in simplified form)
• selecting components with security criteria in mind (updatability, default configuration, vendor support)
• configuring the machine securely before delivery: unique passwords, unnecessary services disabled, unused network ports closed
• documenting security decisions and default configurations

For many builders, particularly SMEs, this is the most demanding part. Machine design today focuses on mechanics, electrics, pneumatics, PLC logic and functionality. Cybersecurity, when addressed at all, is typically left to the integrator or end customer. Under the CRA, it becomes the manufacturer's responsibility.

4. Build a vulnerability-management process

After delivering the machine, the manufacturer must be able to:

• monitor known vulnerabilities in the product's software components
• produce and distribute security updates throughout the product's expected lifetime (or at least 5 years)
• handle vulnerability reports received from third parties
• notify the CSIRT of actively exploited vulnerabilities within 24 hours

In a sector where machines have lifecycles of 15 to 20 years and where software updates are often tied to a scheduled shutdown, these obligations require rethinking support and maintenance models. It does not mean the builder must push PLC firmware updates remotely every week, but it does mean having a process to identify when an update is needed, make it available and document how it is managed over time.

5. Prepare technical documentation and the declaration of conformity

The CRA requires technical documentation that includes at least:

• description of the product and its intended use
• cybersecurity risk assessment
• list of harmonised standards applied (where available)
• SBOM
• description of the security measures implemented
• security test results
• information about the vulnerability-management process

Technical documentation must be kept for at least 10 years after the product is placed on the market. The EU declaration of conformity must accompany the product, with explicit reference to Regulation (EU) 2024/2847.

Practical difficulties for SMEs in the machinery sector

A large share of Europe's machinery industry is made up of SMEs. The CRA acknowledges this to some extent, but the obligations remain substantial. Foreseeable difficulties include:

• Limited internal expertise: few mechanical or mechatronics companies have staff trained in product cybersecurity. Often, the distinction between corporate IT security and product security is itself unclear.
• Vendor dependency: a builder who integrates third-party PLCs and HMIs depends on the vendor's cooperation to obtain SBOM data, vulnerability information and updates. If the vendor does not cooperate, the builder has a compliance problem.
• Long lifecycles: an industrial machine stays in operation for decades. Providing security updates for at least 5 years is feasible; for 15 or 20 years it is an open challenge, particularly for embedded software components.
• No consolidated harmonised standards yet: at the time of writing, harmonised standards for the CRA are still under development. The IEC 62443 series covers many relevant aspects for industrial automation systems, but whether it can be used as a reference for CRA conformity will depend on future formal harmonisation.
• Cost of compliance: documentation, testing, SBOM, vulnerability management, possible notified-body involvement — all of this carries costs that can be significant for an SME.

None of these difficulties is insurmountable, but underestimating them would be a mistake. The sensible approach is to address them gradually, starting with the activities that take the longest: component mapping, vendor engagement and building a vulnerability-management process.

IEC 62443 and the CRA: a natural reference, not yet a formal one

The IEC 62443 series is the most established technical reference for cybersecurity of industrial automation and control systems (IACS). It covers areas such as the secure development lifecycle (IEC 62443-4-1), technical requirements for components (IEC 62443-4-2), risk management (IEC 62443-3-2) and system-integrator requirements (IEC 62443-2-4).

Many of the CRA's essential requirements map directly to IEC 62443 controls. Organisations that have already adopted the standard for their products or processes start with a tangible advantage.

However, as of today, IEC 62443 has not been formally harmonised with the CRA. The harmonisation process is under way, but until it is completed, applying IEC 62443 does not automatically create a presumption of conformity with the regulation. It is a solid technical reference, but not yet a regulatory passport.

Operational checklist to get started

Mistakes to avoid

• Waiting for harmonised standards before starting: the harmonisation process takes time, but the CRA's essential requirements are already defined. Waiting for published standards before taking action means starting late.
• Delegating everything to the PLC vendor: the CRA holds the manufacturer of the final product responsible. Even if the PLC or HMI is compliant, the machine builder must demonstrate conformity of the overall product, including configuration, integration and documentation.
• Confusing IT cybersecurity with product cybersecurity: protecting the corporate network is different from designing a secure product. The CRA is about the latter. Having a good office firewall does nothing for machine compliance.
• Overlooking stand-alone software: configuration applications, diagnostic tools and supervisory interfaces shipped with the machine are products with digital elements in their own right.
• Underestimating the update obligation: the CRA requires free security updates throughout the product's expected lifetime. This has implications for service costs and business-model sustainability.

Our take

The CRA is the first European regulation that brings cybersecurity into the CE marking of digital products. For the industrial machinery sector, the impact will be gradual but substantial. Anyone producing machines with PLCs, HMIs, gateways and connected software will need to add cybersecurity to the design-responsibility list, alongside mechanics, electrics and safety.

There is no need to start with a massive programme. The point is to start. Map the components, talk to the vendors, begin documenting, understand where you stand and where you need to be. The deadlines are not as distant as they may seem, especially for organisations that need to build capabilities and processes they do not yet have.

Official resources and references

• Regulation (EU) 2024/2847 — official EUR-Lex text
• Cyber Resilience Act — European Commission
• ENISA — Cyber Resilience Act
• Regulation (EU) 2023/1230 — Machinery Regulation
• IEC 62443 — Industrial communication networks, Network and system security