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.
The good news is that the simplest safety hardware is barely touched. The complication is in the middle ground — the smart sensors, configurable scanners and IO-Link devices that the industry has spent a decade adding intelligence to. This is a guide to working out where a given device sits, written for the engineer who has to make the call, not the lawyer who signs it off.
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.
Treat December 2027 as the hard deadline for product compliance, and use the runway before it the way you would for any CE transition: assess scope, talk to your suppliers, and build the processes you will be audited against. The reporting machinery comes a little earlier, which is worth knowing if you are the manufacturer of the component rather than only an integrator of it.
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”. Two devices that do the same protective job can land on opposite sides of the line if one is a sealed hardwired unit and the other carries updatable firmware and an Ethernet port.
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.
- Lower-risk edge: simple hardwired OSSD devices. A Type 2 or Type 4 light curtain that only switches dual OSSD safety outputs, with no network interface and no externally exposed, updatable firmware, has little of the digital surface the CRA is aimed at. A basic proximity sensor or a hardwired safety relay such as the DAIDISIKE DA31, wired into a safety circuit, is in the same bracket.
- 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 safety laser scanner / LiDAR such as a DAIDISIKE DLD-series unit with field-set configuration, embedded firmware that can be updated, and a communication interface carries the most digital surface, and is the category to assess first.
- The controller, not the sensor, often carries the network. On our devices, fieldbus or protocol integration is handled by an external safety controller rather than native protocol stacks inside the sensor. That matters for scope: the controller is frequently the product with the richer digital elements, and it deserves its own assessment alongside the sensors it reads.
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 a buyer, this turns into a procurement question rather than a design one. You are not auditing the supplier’s source code; you are asking whether the process exists: is there a security contact, a defined support period, an update mechanism, and a disclosure policy? A supplier who can answer those cleanly is a supplier whose components will not become your compliance gap in 2027.
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?
- Could a simple hardwired OSSD device do this job instead, keeping the connectivity — and the cybersecurity scope — out of the design where it adds no value?
That last point is the quiet design lesson of the CRA. Connectivity is not free any more; it carries a compliance cost. Where a safety function genuinely benefits from configuration or networking, that cost is worth paying. Where it does not, a plain hardwired OSSD device keeps both your safety case and your cybersecurity case smaller and easier to defend.