In short: From 20 January 2027 the EU Machinery Regulation (EU) 2023/1230 requires that safety-related control systems on machinery be designed against reasonably foreseeable cyber attacks. The bridge standard is IEC TS 63074:2023, which tells a safety engineer which parts of IEC 62443 to apply to the safety function. Performance Level (ISO 13849-1) and Security Level (IEC 62443-3-3) are different measures of different threats — both must be specified and verified. Pick components built under IEC 62443-4-1, segment the safety network, log every change to safety software, and document the Target Security Level the way you already document the required PL.
A controls engineer at a packaging OEM put the problem to us plainly last winter: “Our safety light curtains are PL e. Our safety relays are PL e. Our safety PLC is PL e. The engineering laptop the maintenance contractor plugs in once a month is on the same VLAN as the safety bus and has a five-year-old version of the configuration tool. Are we PL e?” The honest answer is that the functional-safety calculation says yes and the security reality says no — and until very recently, no one was sure which answer the auditor wanted to hear.
That ambiguity is closing. The EU Machinery Regulation (EU) 2023/1230, the Cyber Resilience Act (EU) 2024/2847, and the NIS2 Directive (EU) 2022/2555 between them have turned cybersecurity-of-safety from a good-practice topic into a conformity-assessment topic with hard dates attached. The technical bridge is IEC TS 63074:2023, sitting between the functional-safety standards machine builders already know (ISO 13849-1, IEC 62061) and the industrial security standards they often do not (the IEC 62443 series). This article is the conversation we have with engineers who suddenly realise the security and safety teams have to be the same conversation.
Why safety and security used to be separate — and why that ended
Functional safety has always been about random hardware failure and systematic design errors. ISO 13849-1 and IEC 62061 work in probabilities: a Performance Level expresses an average probability of a dangerous failure per hour, derived from MTTFd, diagnostic coverage, common-cause failure resistance, and architectural category. The implicit threat model is a component that breaks, a designer who got something wrong, or an operator who tries to defeat a guard. None of those threats involves an intelligent adversary on a network.
Cybersecurity is exactly the opposite. The threat model is an intelligent adversary who studies the system, picks the weakest link, and adapts when blocked. The probability of attack is not a random variable derived from a failure-rate database — it is a function of motivation, capability, and the value of the target. Probabilistic reliability mathematics genuinely does not apply.
For a long time the two disciplines could live in separate documents because the safety function was electrically and physically isolated from anything that looked like a network. A hardwired emergency stop, a relay-based safety circuit, a Type 4 light curtain wired directly to a safety contactor — none of those have an attack surface a network adversary can reach. That world is gone. Modern safety functions use networked safety PLCs, IO-Link Safety, safety over PROFINET (PROFIsafe), safety over EtherCAT (FSoE), OPC UA Safety, and increasingly OPC UA over TSN. Every one of those buses is a potential message-injection or denial-of-service surface. The hardwired isolation that used to make the safety/security separation tenable does not exist on a modern machine.
The standards that now matter — and what each one actually says
There is a small library of standards in play. They are not redundant; each one answers a different question. Treating them as a single “cyber blob” is the fastest way to make a mess of the compliance file.
- IEC 62443-2-1 — security program requirements for the asset owner. The factory, not the machine builder, owns this. It defines how the operating organisation runs its security program.
- IEC 62443-3-3 — system security requirements and Security Levels SL 1 to SL 4 for an Industrial Automation and Control System (IACS). This is where the SL numbers come from. Roughly 100 controls at SL 2, 130 at SL 3, and 150 at SL 4.
- IEC 62443-4-1 — secure product development lifecycle requirements for the component vendor. This is what the safety PLC manufacturer must comply with, covering security requirements definition, secure design, secure coding, verification, defect handling, patch management, and product end-of-life.
- IEC 62443-4-2 — technical security requirements for IACS components. A component cannot be certified under 4-2 unless it was developed under 4-1.
- IEC TS 63074:2023 — the bridge. Identifies which 62443 aspects apply to the safety-related control system and adds a new Clause 6 on cybersecurity and functional safety of machinery. Published as a Technical Specification in February 2023; supersedes the 2019 Technical Report (IEC TR 63074:2019).
- ISO 13849-1 / IEC 62061 — functional safety of safety-related control systems. Performance Level and SIL still mean exactly what they meant before; they just no longer cover the whole risk picture.
- Regulation (EU) 2023/1230 — the Machinery Regulation. Mandatory 20 January 2027. The legal instrument that pulls cybersecurity into CE marking. See our EU Machinery Regulation 2027 briefing for the broader picture.
- Regulation (EU) 2024/2847 — the Cyber Resilience Act. Applies to products with digital elements. Main obligations from 11 December 2027; vulnerability reporting to ENISA from 11 September 2026.
- Directive (EU) 2022/2555 — NIS2. Cybersecurity obligations on essential and important entities — large manufacturers fall in scope. Affects the operator more than the machine builder, but the operator will push requirements upstream.
Security Level vs Performance Level — at a glance
This is the comparison every engineer asks for and every standards committee declines to put in print, because the two measures are not directly equivalent. They are not. The table below is what we use in conversations to keep the discussion honest — it is a translation aid, not a mapping.
| What it measures | ISO 13849-1 Performance Level | IEC 62443-3-3 Security Level |
|---|---|---|
| Threat model | Random hardware fault, systematic error | Intelligent adversary |
| Lowest tier | PL a — minor injury, reversible | SL 1 — casual/coincidental |
| Mid tier (typical industrial) | PL c / PL d | SL 2 — low-resource generic attacker |
| High tier (point-of-operation, robotic cells) | PL e | SL 3 — sophisticated, ICS-aware |
| Highest tier | PL e with redundancy + diagnostics | SL 4 — nation-state, ICS-specialist teams |
| Math | Probability of dangerous failure per hour | Attacker capability vs control strength |
| Typical machinery target | PL d or PL e per safety function | SL 2 baseline, SL 3 where safety is networked |
The rows in the middle are deliberately rough. There is no official statement that “PL e implies SL 3” or anything similar — IEC TS 63074:2023 explicitly avoids that mapping. What it does say is that the security risk assessment and the functional safety risk assessment have to be performed together, and the Target Security Level for the safety function has to be derived from the security risk assessment in the same way the required PL is derived from the safety risk assessment. Different inputs, different methods, but the discipline is the same: declare the target, design to meet it, verify.
The actual attack surface of a modern safety function
Where does a network attack on a safety function actually land? Not on the protective device. A Type 4 light curtain's OSSD outputs are hardwired, dual-channel, pulse-tested, and have no IP address. You cannot phish a light curtain. The attack surfaces are everywhere else in the safety system:
- The safety PLC. A safety controller running PROFIsafe or FSoE has a black-channel principle that protects the safety message itself from a corrupted standard bus. That does not protect the controller from someone with valid engineering credentials reprogramming it, or from a denial-of-service attack on its non-safety interface that drives it into a fault state.
- The engineering workstation. The laptop with the safety configuration tool is usually the weakest cybersecurity link in the whole machine. Stale OS, stale tool version, plugged in occasionally by an outside contractor. If an attacker can change the muting window or the safety distance on the workstation, the curtain itself is irrelevant.
- Remote access. Vendor remote-support VPNs, cellular routers for OEE telemetry, and cloud-connected HMIs all create paths from outside the factory to the safety network. NIS2 has tightened the operator's obligations here, which will flow downstream to machine builders.
- IO-Link Safety and OPC UA Safety. Both wrap a safety message in a cryptographic or CRC-protected envelope so the underlying transport does not have to be trusted. Useful, but the master device and the configuration tool are still attack surfaces.
- Firmware update channel. Any signed-or-not firmware update path on the safety controller, the I/O modules, or the protective devices. The CRA puts a hard 5-year minimum on the manufacturer's obligation to support patches.
Defense in depth, applied to a safety function
Defense in depth is the organising principle that IEC 62443 inherits from broader cybersecurity practice. For a safety function, it means no single security control is allowed to be the only thing between an attacker and the ability to defeat the safety. In a machine context that translates into a small number of concrete rules:
Segment the safety network. A dedicated VLAN or, better, a physically separate safety network. No general OT or IT traffic on it. The safety bus speaks PROFIsafe or FSoE to safety I/O and nothing else routes over it.
Choke remote access. No always-on VPN terminating inside the safety zone. Remote support sessions gated by a jump host, time-limited, logged, and ideally requiring an operator on the floor to enable the session.
Reduce the attack surface of every component.Disable unused ports, services and protocols on PLCs, HMIs and safety controllers. The web server on the safety PLC that no one uses is a free attack surface; turn it off. This is a direct IEC 62443-3-3 control and the easiest hardening win available.
Authenticate the engineering workstation.Strong, unique credentials per engineer. No shared “maintenance” account. The safety controller must log who connected, when, and what they changed — Annex III Section 1.2.1 of the Machinery Regulation requires the log; your auditor will check that the log exists and is retrievable.
Pick components built under IEC 62443-4-1.The component vendor's development process matters because a safety PLC built without a secure development lifecycle will have vulnerabilities the vendor itself does not know about. Ask for the 4-1 certificate from the vendor. A 4-2 component certificate cannot exist without it.
What the Machinery Regulation actually demands in writing
Two sections of Annex III do most of the cyber work. Section 1.1.9, Protection against corruption, requires that connecting another device or allowing remote communication does not create a dangerous situation, and that the software and data the machine relies on to operate safely are protected against accidental and intentional tampering. Section 1.2.1, Safety and reliability of control systems, requires that safety-related control systems are designed so they cannot be defeated by reasonably foreseeable cyber attacks, and that the control system records every conscious or unconscious intervention in the safety software, with logs retained for at least five years after a software change.
Those two clauses look short. In practice they pull the entire IEC 62443 / IEC TS 63074 stack into the Declaration of Conformity. You cannot write “complies with Annex III 1.1.9” on a CE file unless you can show how — and the how is a security risk assessment, a documented Target Security Level, evidence that the components meet at least part of IEC 62443-4-2, a network design that demonstrates segmentation, and a tamper-evident log mechanism. That is a large amount of work to bolt onto a CE file that has not previously contained it.
A worked example — robotic cell with networked safety
Take a robotic module-assembly cell with a perimeter light curtain at the access door, a safety door lock on the maintenance gate, an area scanner inside the cell, and a safety PLC evaluating all three over PROFIsafe. The safety function is “stop robot motion before a person can reach a hazard.” The required Performance Level is PL e, the architecture is Category 4.
What changes under the new rules? The functional safety calculation is unchanged. The light curtain is still Type 4, PL e. The door lock is still PL e. The scanner is still PL d or PL e depending on family. The safety PLC is still PL e on its safety channel. Performance-Level-wise, you are done.
The security assessment is new work. You declare a Target Security Level — typically SL 2 for a cell on a corporate OT network, SL 3 if the cell is on a network that touches the internet or accepts remote support. You confirm the safety PLC vendor holds IEC 62443-4-1 certification. You confirm relevant IEC 62443-4-2 component capabilities — unique identifiers, session lock, role-based access on the engineering port. You design the cell's network so that the PROFIsafe bus is segmented from the OEE telemetry network. You disable the unused MQTT broker on the safety PLC. You set the safety configuration tool to require named user accounts and you turn on its audit log. You document a procedure for safety-software updates that meets the 5-year log retention. None of this changes the PL of the safety function. All of it is now required.
Where DAIDISIKE fits — honestly
A direct answer, since you are reading this on our site. DAIDISIKE makes the protective devices at one end of this stack: the DQA, DQC and DQT4 Type 4 light curtain families, the DLD-series safety laser scanners, the DX safety door locks and the DA31 safety relay. Those devices are hardwired, dual-channel, OSSD-output products. They have no IP stack and no network attack surface of their own — that is a security property worth stating clearly, because it means the security work for a machine using DAIDISIKE devices concentrates entirely on the controller, the network and the engineering tools around our products, which is exactly where IEC TS 63074 says the work belongs.
What we will not pretend is that a hardwired protective device on its own makes a machine cyber-secure. A safety system is a whole chain — sensor, logic, actuator, network, and the human processes around them. We supply one link in that chain and we will say so plainly. The bigger compliance job sits with the machine builder, and we would rather help you scope it correctly than tell you that buying our hardware is the whole answer.
The bottom line
Safety and security used to be different conversations because the safety function was electrically isolated from anything an attacker could reach. That isolation is gone on a networked machine. The EU Machinery Regulation closes the gap legally from January 2027; the Cyber Resilience Act closes it on the product-security side from December 2027; IEC TS 63074:2023 closes it technically by telling a safety engineer which parts of IEC 62443 to apply. The Performance Level you have always calculated is still required and still right. It is no longer sufficient. Specify a Target Security Level alongside the required PL, pick components from vendors who can show IEC 62443-4-1 certification, segment the safety network, lock down the engineering workstation, and log the changes. The machine builders who treat this as one integrated risk assessment in 2026 will sail through 2027; the ones who leave it to a separate cyber project will not.