Use the machine-safety standards and regulatory framework to keep CRA scope, machinery conformity and functional-safety evidence separate. The official CRA text, Articles 2, 3, 69 and 71 governs this assessment; the Commission summary provides implementation context.
For twenty years, the cybersecurity of an industrial safety device was somebody else’s problem — the network team’s, the IT department’s, the system integrator’s. The EU Cyber Resilience Act changes that. It puts security obligations onto the product itself, and it enforces them through the same CE marking that already carries functional safety. If you place machines or safety components on the EU market, the CRA is now part of your conformity picture.
A smaller interface set may reduce the attack surface, but that is a security-design judgement, not an exemption. Record the hardware, software, maintenance tools and direct or indirect data paths for each exact model before deciding scope.
The dates that matter
The Cyber Resilience Act is Regulation (EU) 2024/2847. It entered into force in 2024 and, like most EU product regulations, it does not switch on all at once. The obligations arrive in phases. The reporting obligations — the duty to report actively exploited vulnerabilities and severe security incidents to the authorities — start to apply from 11 September 2026. The main body of obligations, including the essential cybersecurity requirements and the CE marking that covers cybersecurity, applies from 11 December 2027.
Chapter IV applies from 11 June 2026. Article 69 also matters for existing products: devices placed on the market before 11 December 2027 generally enter the main requirements if substantially modified from that date, while Article 14 reporting also applies to earlier in-scope products. Record the placing-on-market event and any later modification, rather than assuming every installed machine has the same transition.
What “products with digital elements” means
The CRA does not list products by name. It defines a class: products with digital elements. The shorthand is a hardware or software product whose intended use includes a direct or indirect logical or physical data connection to a device or network. That definition is deliberately broad, and it is the hinge on which scope turns for safety sensors.
Read it carefully and two things follow. First, the trigger is the data connection and the digital content — firmware, configurable parameters, a communication interface — not the safety function as such. Second, scope is a property of the specific model, not of the category “light curtain” or “laser scanner”. Neither a sealed housing nor absence of an Ethernet port settles scope: physical and indirect data connections also matter.
Where common safety devices are likely to fall
With that definition in hand, you can sort a typical safety bill of materials into rough tiers. This is engineering judgement to guide a formal assessment — it is not a legal classification, and the official text governs.
- Hardwired devices: assess, do not exempt by label. List any digital processing and physical or indirect data connections. A low attack surface is not a statutory product exclusion, and a relay model name does not establish CRA status.
- Middle ground: configurable and IO-Link devices. A light curtain or safety switch with a parameterisation interface, a muting or blanking configuration tool, or IO-Link / IO-Link Safety communication has digital elements and a data connection. These are the devices most likely to need a CRA assessment.
- Most likely in scope: networked smart sensors. A configurable or networked scanner should have its firmware, configuration tools and communication paths assessed. DLD is a non-safety industrial LiDAR family, not a certified protective scanner; do not infer its interfaces or CRA classification from the family name.
- The controller, not the sensor, often carries the network. Assess the exact controller and sensor separately, including indirect connections between them. An external controller does not make an ordinary sensor safety-certified or remove that sensor from a CRA scope assessment.
The essential cybersecurity requirements, in plain terms
Where a device is in scope, the CRA expects it to be secure by design. The detailed requirements live in the regulation’s annexes, and you should build a conformity file from that official text rather than a summary — but at concept level the expectations are recognisable to anyone who has done industrial security work:
- placed on the market with no known exploitable vulnerabilities;
- a secure-by-default configuration, with the option to reset to that default state;
- protection of the confidentiality and integrity of stored and transmitted data and commands — for a safety device, the integrity of configuration and of the safety command path is the part that matters most;
- a reduced attack surface and protection against unauthorised access;
- the ability to deliver security updates, where the product is designed to receive them.
None of this conflicts with functional safety; it runs in parallel with it. The integrity requirement, in particular, is the natural meeting point — a corrupted configuration that silently weakens a protective function is both a security failure and a safety failure.
Vulnerability handling and coordinated disclosure
A large part of the CRA is not about the product as shipped but about what the manufacturer does afterwards. Across the support period, the manufacturer is expected to identify and document vulnerabilities, provide updates that address them, and run a coordinated vulnerability disclosure process so that a researcher who finds a flaw has a defined way to report it. The separate reporting obligations — notifying authorities of actively exploited vulnerabilities and severe incidents — sit on top of that, and are the part that begins from September 2026.
For procurement, obtain evidence of the security contact, vulnerability process, update delivery and a declared support period, not just assurance that a process exists. Under CRA Article 13(8), the support period reflects expected use and is at least five years unless the expected use is shorter. Supplier answers do not by themselves prove conformity; assess the exact product and retain the applicable documentation.
CRA, IEC 62443 and the Machinery Regulation: three layers
It is easy to blur these three together because they all touch security and safety. They sit at different levels, and seeing the distinction makes compliance simpler, not harder.
- The Cyber Resilience Act is the law for the product. It sets mandatory market-access requirements for products with digital elements and enforces them through CE marking. You cannot opt out of it for an in-scope product sold into the EU.
- IEC 62443 is the engineering toolkit. It is a voluntary international standard series for the security of industrial automation and control systems — security levels, zones and conduits, secure development practices. It is not the law, but it is the method you can lean on to demonstrate that you have met a legal goal.
- The Machinery Regulation owns the safety function. Regulation (EU) 2023/1230 governs machine safety and addresses cybersecurity to the extent that an attack could defeat a safety function. Its concern is the machine and its protective functions; the CRA’s concern is the digital product’s own security.
In a real project the three stack rather than collide: the Machinery Regulation asks whether the safety function can be defeated, the CRA asks whether the digital product can be compromised, and IEC 62443 gives you the vocabulary and methods to answer both. For deeper coverage of that overlap, see our companion piece on IEC 62443 meeting ISO 13849.
A buyer’s checklist for sourcing safety components
If you are an OEM or integrator putting machines on the EU market, the CRA mostly reaches you through the components you buy. For each smart or networked safety device, put these questions to the supplier:
- Is this specific model assessed as a product with digital elements under the CRA?
- Will it carry CE marking that covers cybersecurity by the time I place my machine on the market?
- How are security updates delivered, and for how long — what is the support period?
- Is there a coordinated vulnerability disclosure process and a security contact?
- Can unnecessary interfaces be removed without weakening the required safety function, and has CRA scope still been assessed for the resulting design?
Reducing unnecessary connectivity can simplify threat modelling, but it does not prove an exemption. Procurement should obtain the model-specific scope rationale, support commitment and conformity documentation instead of relying on a generic hardwired-versus-networked rule.