In short: Cybersecurity can affect whether a machine’s protective function remains effective. Assess access paths, configuration, software changes and shared dependencies alongside functional safety. PL and Security Level are different measures; neither determines the other. Machinery Regulation Annex III sets risk-appropriate outcomes, while IEC TS 63074 and IEC 62443 provide relevant engineering methods, not automatic certification mandates.
Illustrative architecture check: several PL e-labelled devices do not establish a PL e safety function. An unmanaged engineering workstation can also create security vulnerabilities outside the hardware reliability calculation. Review both the complete protective chain and who can alter it; this example is not a reported customer audit.
The legal and technical questions are related but distinct. Start with the machine-safety standards and legislation index, then identify which machinery, digital-product and operator obligations actually apply. Record the exact legal role, product scope, standards editions and evidence owner rather than treating all connected equipment as subject to an identical checklist.
For the product-market side of that review, use the CRA scope and supplier-support checklist to examine the exact sensor's digital interfaces, the supplier's role and the support evidence to request; keep that assessment separate from the machine's safety/security architecture.
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.
A hardwired protective circuit and a networked safety-control system expose different interfaces and dependencies. Neither should be described as universally attack-proof. Inventory communications, configuration, updates, physical access and shared engineering tools; ordinary safety communication error detection does not automatically authenticate an adversary.
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 defines system security requirements and capability Security Levels across seven foundational requirements. Use the actual requirements and enhancements applicable to the system; there is no useful universal controls-count shortcut.
- 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 defines technical security requirements for IACS components. Lifecycle evidence and certification prerequisites depend on the applicable conformity scheme; inspect its scope and conditions.
- IEC TS 63074:2023 identifies security threats and vulnerabilities relevant to maintaining machinery safety functions. It is a Technical Specification published 9 February 2023; its scope does not cover every IT issue or device-design requirement.
- 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. Applicability depends on sector, entity size, exceptions and national implementation. It can affect manufacturers or operators in scope; it does not automatically apply identically to every large factory.
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 |
|---|---|---|
| Purpose | Ability to perform the required protective function | Resistance to specified security violations |
| Target selection | Machine risk assessment and applicable function requirements | Security risk assessment of the system, zones and conduits |
| Evidence | Quantitative and qualitative design requirements, plus validation | Required capabilities, secure processes and verification |
| Boundary | Defined sensor–logic–final-element function | Defined system, interfaces, zones and connections |
| Comparison limit | PL a–e is not an SL scale | SL values are not PL conversion factors |
The table deliberately compares questions, not numerical tiers. Derive the security target for the defined system, zones and conduits from a security risk assessment; derive PLr for each safety function from the machine risk assessment and applicable requirements. Record how failures of security controls could affect safety, including recovery and update procedures.
The actual attack surface of a modern safety function
Start at every interface that can affect protection, not only the controller’s IP address. A hardwired sensor may have no network interface, but its exact configuration and firmware access still need checking. Include indirect access through diagnostic gateways, masters and engineering workstations in the system boundary.
- 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. Safety-layer error detection must not be confused with cryptographic authentication or complete cybersecurity. Check the applicable protocol, secure transport where provided, master, endpoints and configuration tools.
- Firmware update channel. Assess authenticity, authorization, rollback and safety validation of updates. Under CRA Article 13(8), support reflects expected use and is normally at least five years, with the stated shorter-use exception; longer-lived industrial products can require longer support.
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:
Define zones and controlled connections. Use the security risk assessment to select segmentation and access controls. A VLAN alone is not a complete security boundary, and safety communications do not universally require a physically isolated network. Validate permitted traffic, maintenance access and safe response to loss of communication.
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.
Control engineering access and retain evidence of changes. Use named accounts, appropriate authorization and traceable configuration/version records. Match the logging design to Annex III 1.1.9 and 1.2.1(f): the legal requirement concerns interventions and uploaded safety-software versions, not a generic claim that every device must log every user action.
Request secure-development and component evidence. IEC 62443-4-1 addresses development lifecycle processes; 4-2 addresses component technical capabilities. Verify certificate scope, product version, assumptions and the certification scheme where used. Neither a certificate nor the lack of one alone decides compliance with the Machinery Regulation.
What the Machinery Regulation actually demands in writing
Read the current Machinery Regulation Annex III. Section 1.1.9 addresses protection of relevant hardware, software and data against corruption and evidence of interventions. Section 1.2.1(a) addresses reasonably foreseeable malicious attempts that could cause hazards. Section 1.2.1(f) specifies tracing data and uploaded safety-software versions enabled for five years after upload; separate provisions address decision-process records for specified self-evolving systems.
Demonstrate how the design meets the applicable essential requirements. IEC TS 63074 and relevant IEC 62443 parts can support the argument, but the Regulation does not name them as a mandatory package or demand a particular universal Security Level. Explain the chosen measures, residual risks, verification and maintenance responsibilities.
A worked example — robotic cell with networked safety
For an illustrative robot cell, list separate functions for access detection, gate interlocking, restart prevention and safe stopping. Establish each required PLr or SIL from the actual risk assessment and machine-specific requirements. No universal Category 4/PL e target or successful commissioning result is assumed in this example.
Validate the whole function before considering security: compatible interfaces, subsystem reliability, architecture, response and stopping times, coverage and restart behavior. A Type 3 scanner rated PL d does not become PL e because its signal enters a PL e controller. Device labels cannot be added up as a shortcut to the required performance.
Then identify which credentials, software tools, network paths and updates could change those functions. Choose the security target from the documented threat assessment, restrict access, verify supported hardening settings, and test safe failure/recovery behavior under an approved plan. Remote support does not automatically mean SL 3; a corporate OT network does not automatically mean SL 2.
Where DAIDISIKE fits — honestly
DAIDISIKE supplies distinct sensor and relay families with different interfaces. Check exact DQA light-curtain, DX interlock and DA31 relay documents rather than describing them all as OSSD devices without software or access paths. ST27 is the user-confirmed safety scanner (Type 3, PL d, SIL 2); DLD, SDLD, DLDS and JPTG are non-safety industrial LiDAR and must not be used as the personnel-protective sensing channel.
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
Coordinate safety and security evidence throughout design, commissioning and controlled changes. Establish which legal dates and product roles apply, identify the relevant technical methods, and preserve a traceable explanation of the chosen measures. Neither a good PL calculation nor a cybersecurity certificate alone demonstrates the complete machine’s compliance.