The EU Machinery Regulation 2023/1230: From Machine Safety to Cyber-Physical Safety

A technical analysis of Regulation (EU) 2023/1230 and its transition from traditional machinery safety toward cyber-physical safety, with a focus on software integrity, malicious interference, connected control systems, substantial modification, IEC 62443, remote access, AI, the Cyber Resilience Act, NIS2, procurement, and FAT/SAT.

The Machinery Regulation changes the boundary of machine safety

Regulation (EU) 2023/1230 is not simply a recast of Directive 2006/42/EC. It preserves the classical machinery-safety model—risk assessment, inherently safe design, safeguards, safety-related control systems and information for use—but extends that model to the digital mechanisms through which machine behaviour can now be changed. The Commission itself describes the Regulation as integrating provisions for cyber-safety concerning compliance-relevant software, data and safety control systems. The decisive legal provisions are Annex III §1.1.9, Protection against corruption, and §1.2.1, Safety and reliability of control systems. They require protection against intentional as well as accidental corruption and explicitly require control systems, where relevant to the circumstances and risks, to withstand reasonably foreseeable malicious attempts by third parties that could produce a hazardous situation. ¹

That supports the central thesis of this research, but with an important boundary condition:

The Machinery Regulation does move machine safety toward cyber-physical safety, but it does not create a general-purpose OT cybersecurity regime. Cybersecurity becomes a machinery-safety requirement when compromise of a digital asset, communication path, software state, configuration or control authority can contribute to a hazardous physical state.

Consequently, a vulnerability that exposes confidential production data may be important under the Cyber Resilience Act, NIS2 or company policy without necessarily violating a machinery essential health and safety requirement (EHSR)². The same vulnerability becomes directly relevant to Regulation 2023/1230 if it enables an attacker to alter a safety parameter, inhibit a stop, trigger motion, defeat a protective function, corrupt safety-related data or otherwise cause a hazardous situation. That distinction follows from the safety-conditioned language of Annex III rather than from a generic requirement that every machine attain some undefined level of cybersecurity. ³

The Directive becomes a Regulation: the legal baseline and the 2027 cut-over

Regulation (EU) 2023/1230 was adopted on 14 June 2023 and replaces Directive 2006/42/EC. Following a corrigendum concerning its dates of application, its main product requirements become mandatory on 20 January 2027. Machinery first placed on the EU market before that date remains subject to Directive 2006/42/EC; the Commission expressly states that all machinery placed on the market before 20 January 2027 must comply with the Directive, although manufacturers may additionally state conformity with the Regulation where applicable. The Regulation is already in force as EU law, while different provisions on institutional machinery, delegated powers, notified bodies and penalties have phased in at different dates under Article 54. ⁴

The choice of a Regulation rather than another Directive is substantive in institutional terms. A Regulation applies directly and does not require each Member State to transpose its product rules into national legislation. The Commission identifies increased legal certainty through uniform application as one of the reasons and also notes alignment with the EU New Legislative Framework. ⁵

The basic product-safety architecture nevertheless remains familiar. The Regulation sets mandatory EHSRs; harmonised standards remain voluntary technical means for obtaining presumption of conformity where their references are published in the Official Journal. It also aligns machinery law more closely with the New Legislative Framework by formalising obligations across manufacturers, authorised representatives, importers and distributors and by integrating modern market-surveillance concepts. ⁶

Scope and definitions

Scope. Article 2 covers machinery and what the Regulation calls related products: interchangeable equipment, safety components, lifting accessories, chains, ropes and webbing, and removable mechanical transmission devices; it separately regulates partly completed machinery. Important exclusions remain for, among other things, certain nuclear applications, weapons, specially designed military or police machinery, certain research equipment, mine winding gear, seagoing vessels and mobile offshore units, categories covered by vehicle legislation, and specified electrical/electronic equipment governed through other Union product regimes. The legal perimeter therefore still has to be determined product by product rather than by assuming that every automated industrial asset is machinery. ⁷

There are, however, several digital changes in the definitions themselves. The machinery definition expressly accommodates assemblies that are complete except for the upload of software intended for the manufacturer’s specific application. More importantly, Article 3 makes a safety component capable of being a physical or digital component, including software, when it is independently placed on the market to fulfil a safety function and its failure or malfunction would endanger persons. Software can therefore be a regulated safety product rather than merely documentation accompanying hardware. ⁸

Partly completed machinery remains an assembly that is almost machinery but cannot itself perform the specific application and is intended for incorporation into or assembly with other machinery or equipment. Its manufacturer does not issue the same final machinery EU declaration of conformity; the relevant regime includes technical documentation, assembly instructions and an EU declaration of incorporation. ⁹

Defining the product perimeter, however, only establishes which regulatory regime applies. The next question is what conformity with that regime actually means. For machinery and related products, the substantive core is Annex III: the structured set of EHSRs against which the manufacturer’s risk assessment, design measures, protective systems and technical evidence ultimately have to be justified. Understanding that structure is particularly important for the digital provisions, because the Regulation does not place cybersecurity in a separate compliance silo; it embeds protection against digital corruption and malicious interference inside the machinery-safety requirements themselves.

The EHSR architecture: how Annex III is organised

The EHSRs are the substantive safety requirements that machinery and related products must satisfy where they are applicable to the product and its hazards. Article 8 connects market access directly to them: machinery or a related product may be placed on the market or put into service only if it complies with the applicable EHSRs in Annex III when properly installed and maintained and used for its intended purpose or under reasonably foreseeable conditions.¹⁰

Annex III is therefore not merely guidance and it is not itself a technical standard. It establishes the legally required safety outcomes. Harmonised standards can provide technical specifications and, where their references have been published for the Regulation and they cover the relevant requirement, a presumption of conformity; they do not replace the EHSR itself.

The structure is hierarchical. Annex III begins with definitions and general principles, then separates the requirements into a general set applicable across machinery and additional sets addressing particular categories or hazard classes.

Annex III structure	Subject	Function in the conformity framework
Part A — Definitions	Terms used specifically for interpreting Annex III	Establishes the vocabulary through which the EHSRs are applied.
Part B — General principles	Risk assessment, applicability of requirements, state of the art and the relationship among the numbered sections	Establishes how the manufacturer determines which EHSRs apply and how risk reduction is to be approached.
1 — Essential health and safety requirements	General requirements for machinery and related products	Forms the principal horizontal safety framework. It includes safety integration, control systems, mechanical risks, guards, other hazards, maintenance and information.
2 — Supplementary EHSRs for certain categories of machinery and related products	Requirements for specific product categories, including food machinery, portable machinery and machinery for pesticide application	Supplements Section 1 where the machinery belongs to one of the specified categories.
3 — Supplementary EHSRs to offset risks due to the mobility of machinery	Mobile machinery, including control, movement, stability and autonomous mobile machinery	Adds requirements where mobility creates additional hazards.
4 — Supplementary EHSRs to offset risks due to lifting operations	Lifting machinery and lifting-related hazards	Adds requirements concerning stability, mechanical strength, load control and related safety issues.
5 — Supplementary EHSRs for machinery intended for underground work	Machinery intended for underground operation	Addresses the particular hazards of underground machinery.
6 — Supplementary EHSRs for machinery presenting particular hazards due to the lifting of persons	Machinery that lifts people	Adds requirements concerning carriers, controls, access and protection of lifted persons.

Table 1: High-level structure of the essential health and safety requirements in Annex III of Regulation (EU) 2023/1230.

The Regulation consequently does not require every individual provision in Annex III to be applied indiscriminately to every machine. The manufacturer’s risk assessment determines which requirements are applicable in light of the hazards presented by the machinery. The general principles also make clear that the requirements in the specialised Sections 2 to 6 supplement the general requirements of Section 1 rather than replacing them. Certain horizontal provisions—notably the principles of safety integration and specified marking and instruction requirements—apply irrespective of the conclusions of the individual hazard analysis.¹¹

For the cyber-physical analysis in this article, Section 1 is the critical layer. Its internal structure shows why the new digital requirements cannot sensibly be treated as an isolated cybersecurity appendix.

Annex III provision	Subject	Relevance to cyber-physical safety
1.1	General remarks	Contains the general machinery-safety concepts on which the subsequent requirements depend.
1.1.2	Principles of safety integration	Establishes the risk-reduction hierarchy and the requirement to design machinery so that it can perform its functions without putting persons at risk under intended use and reasonably foreseeable misuse.
1.1.9	Protection against corruption	Introduces explicit requirements concerning connected devices, intentional or accidental corruption of hardware, software and data, identification of safety-relevant software, and evidence of intervention or modification.
1.2	Control systems	Establishes requirements governing the safety and behaviour of machine control systems.
1.2.1	Safety and reliability of control systems	Requires control systems, where appropriate to the circumstances and risks, to withstand relevant external influences, including reasonably foreseeable malicious attempts by third parties that could lead to a hazardous situation; it also contains requirements relevant to safety-function limits, software changes and self-evolving behaviour.
1.2.2–1.2.5	Control devices, starting, stopping and operating/control modes	Defines legitimate machine-control behaviour and authority—the behaviour that a successful cyber compromise may subvert.
1.2.6	Failure of power supply or communication network connection	Requires interruption, restoration or fluctuation of power or a communication-network connection not to lead to hazardous situations.
1.3	Protection against mechanical risks	Contains many of the physical hazard classes that corrupted software or control authority can ultimately activate.
1.4	Required characteristics of guards and protective devices	Relevant where digital manipulation can defeat, bypass or alter assumptions underlying protective systems.
1.5	Risks due to other causes	Covers additional hazard sources, including electricity, temperature, fire, radiation and other physical risks.
1.6	Maintenance	Governs safety considerations associated with adjustment, maintenance and intervention—the operational context in which privileged engineering access frequently occurs.
1.7	Information	Covers information and warnings on machinery, marking and instructions, including the Regulation’s modernised treatment of digital documentation.

Table 2: Section 1 of Annex III and the provisions most relevant to the transition from conventional machinery safety to cyber-physical safety.

This structure is central to interpreting the Regulation correctly. Protection against corruption in §1.1.9 and resistance to malicious influence in §1.2.1 are themselves EHSRs. They do not sit outside the machinery-safety framework as a separate information-security obligation. A manufacturer assessing the safety of a connected control architecture therefore cannot first complete the real machinery-safety analysis and then treat cybersecurity as an independent IT exercise. Where manipulation of a digital dependency can lead to a hazardous state, the digital dependency is part of the causal path addressed by Annex III.

At the same time, the structure prevents the opposite overinterpretation. Annex III does not transform every information-security weakness into a machinery non-conformity. The legal question remains tied to the relevant EHSR and ultimately to machinery health and safety. A confidentiality flaw in a production database, for example, is not transformed into a machinery-safety defect merely because the database is associated with the machine. If the same weakness allows an attacker to alter a safety configuration, issue an unsafe movement command or corrupt data on which a protective function relies, the connection to Annex III becomes materially different.

This distinction also explains the role of standards throughout the rest of the article. An EHSR expresses the legally required outcome; a harmonised standard may provide a recognised technical route to demonstrating conformity with part of that outcome; and engineering frameworks such as IEC 62443 may provide additional methods and controls for satisfying or evidencing security-dependent aspects of the safety case. These three layers should not be collapsed:

1. EHSR → legally required safety outcome,
2. harmonised standard → technical specification that may confer presumption of conformity within its cited scope,
3. engineering control or framework → implementation mechanism whose relevance must be justified against the hazard and requirement.

That hierarchy becomes especially important for §§1.1.9 and 1.2.1. Saying that a machine uses IEC 62443 does not itself demonstrate that the applicable EHSRs have been satisfied; conversely, the absence of an IEC 62443 certification does not by itself establish non-conformity. What matters is whether the manufacturer can connect the applicable Annex III requirement to the identified cyber-physical hazard, the chosen risk-reduction measure and the evidence that the resulting machine remains safe.

Directive 2006/42/EC versus Regulation 2023/1230

With the EHSR architecture established, the comparison with Directive 2006/42/EC becomes more precise. Some changes concern the institutional and conformity-assessment framework; others alter the substantive safety requirements themselves. In particular, the explicit treatment of software, digital modification, intentional corruption, malicious interference and communication-network failure represents more than a reorganisation of Directive-era provisions.

The transition from the Directive can be summarised as follows.

Topic	Directive 2006/42/EC	Regulation 2023/1230	Assessment
Legal instrument	Directive requiring national transposition. 12	Directly applicable Regulation; main application 20 January 2027. 13	Structural change
Economic operators	Manufacturer-centred model, with authorised representative and supply-chain duties distributed through EU product law.	Explicit NLF-style manufacturer, importer and distributor responsibilities, traceability and corrective-action duties. 14	Clarification/modernisation with practical consequences
Safety components	Predominantly understood through physical machinery components.	Definition explicitly includes digital components, including software. 15	Substantive digital change
Substantial modification	The Commission’s Directive guidance treated sufficiently modified machinery as effectively new machinery, but the Directive lacked the Regulation’s explicit horizontal definition. 16	Article 3(16) expressly covers modification by physical or digital means; Article 18 can make the modifier the manufacturer. 17	Substantive legal clarification
Cybersecurity	No equivalent horizontal requirement explicitly addressing intentional corruption or malicious third-party attacks. 18	Annex III §§1.1.9 and 1.2.1 explicitly address intentional corruption and reasonably foreseeable malicious attempts. 19	Major substantive change
Communication networks	Traditional electrical/control-system failure requirements.	Annex III §1.2.6 explicitly extends failure analysis to the communication network connection. 20	Substantive digital extension
Software traceability	Software faults were already relevant to control-system safety.	Explicit safe-software identification, intervention evidence and safety-software version tracing. 21	Substantive change
AI/adaptive behaviour	No dedicated self-evolving machinery framework.	Requirements for fully/partially self-evolving behaviour, ML-based safety functions and safety-decision records. 22	Substantive change
Remote/autonomous machinery	Remote-controlled mobile machinery was not wholly new as a concept.	Autonomous behaviour is addressed more systematically and now sits beneath horizontal digital-integrity/cyber-safety EHSRs. 23	Mixed: continuity plus expansion
Instructions	Predominantly paper-era model.	Digital instructions and declarations are expressly accommodated subject to conditions and availability safeguards. 24	Modernisation
Technical documentation	Conventional design/risk/test documentation.	Digital evidence becomes more important; Annex IV can require safety-related source code or programming logic to demonstrate conformity upon a reasoned authority request where other documentation is insufficient. 25	Substantive compliance change
Conformity assessment	Annex IV high-risk categories under Directive procedures.	Annex I Part A/Part B structure; Part A mandates third-party routes and includes ML-based safety-function categories. 26	Substantive reorganisation
Market surveillance	Established machinery market-surveillance structure.	NLF-aligned duties, explicit economic-operator responsibilities and modern EU market-surveillance framework. 27	Modernisation/strengthening

Table 3: Directive 2006/42/EC and Regulation (EU) 2023/1230: principal structural and substantive differences.

Conformity assessment and harmonised standards

The conformity-assessment distinction in Annex I is particularly important. Part A contains categories of machinery and related products for which a notified-body route is mandatory; it includes safety components with fully or partially self-evolving behaviour using machine-learning approaches that ensure safety functions, and machinery embedding such systems where the systems have not been independently placed on the market. Part B contains additional machinery categories for which internal production control remains available only under the Regulation’s conditions concerning harmonised standards or common specifications; otherwise a notified-body route is required. Article 25 establishes the applicable procedures. ²⁸

The Regulation does not abolish the harmonised-standard model. Article 20 provides the machinery presumption-of-conformity mechanism, supplemented by common specifications in defined circumstances. There is also a specific bridge to EU cybersecurity certification: where a cybersecurity certification scheme adopted under the Cybersecurity Act is appropriately referenced and covers the relevant requirements, it can support presumption of conformity for the protection-against-corruption/control-system requirements within the limits specified by the Regulation. That is very different from saying that any commercial IEC 62443 certificate automatically proves Machinery Regulation compliance. ²⁹

A significant current-status point is easily missed. As of 3 October 2026, the Commission has still not published the first list of harmonised standards under Regulation (EU) 2023/1230. The Commission states that the corresponding Implementing Decision is being prepared and is expected before the end of 2026. It is intended to carry over the vast majority of standards currently cited under Directive 2006/42/EC, while introducing limitations where existing standards do not fully address new or revised EHSRs of the Machinery Regulation. Meanwhile, the Directive-era list remains in force and was most recently amended by Commission Implementing Decision (EU) 2026/2015, adopted on 4 September and published in the Official Journal on 7 September 2026. That decision also provides for the repeal of Implementing Decision (EU) 2023/1586 from 20 January 2027, when Regulation (EU) 2023/1230 becomes applicable.³⁰

EN 50742: the machinery-specific standard for protection against corruption

The new cyber-physical requirements of the Machinery Regulation are also generating a dedicated European standardisation response. EN 50742, Safety of machinery — Protection against corruption, is being developed specifically to address the risks created when accidental or intentional corruption of hardware, software, data or communications can result in hazardous machinery behaviour. It is therefore much closer to the legal logic of Annex III than a generic industrial cybersecurity standard.³¹

The work is being developed within CENELEC, by CLC/TC 44X — Safety of machinery: electrotechnical aspects, with the detailed work assigned to WG 2 — Protection against corruption (including safety-related cybersecurity aspects). This institutional placement is significant: the project sits within machinery electrotechnical safety standardisation rather than within a general information-security framework.³²

Its intended relationship with Regulation (EU) 2023/1230 is explicit. The draft identifies Annex III §1.1.9, Protection against corruption, together with associated requirements in §1.2.1(a) and §1.2.1(f), as the Machinery Regulation requirements it is intended to address. Its scope includes hardware components and interfaces—including interfaces to remote devices and control systems—as well as software and data where their corruption could influence machinery safety.³³

This makes EN 50742 the natural intermediate layer between the Regulation and the more general industrial cybersecurity methods discussed later in this article. The Regulation defines the required safety outcome; EN 50742 is intended to translate the protection-against-corruption EHSRs into machinery-specific technical requirements and recommendations; IEC 62443 can then provide established cybersecurity concepts and controls—such as system integrity, identification and authentication, use control, restricted data flow and secure development—that may support implementation. The relationship should therefore not be read as Machinery Regulation = IEC 62443, but rather as a layered chain:

Machinery Regulation EHSR → EN 50742 machinery-specific interpretation → appropriate cybersecurity engineering controls

The standard is being developed under the European Commission’s M/605 standardisation request, issued to CEN and CENELEC in support of Regulation 2023/1230. This places the project within the formal process through which European standards can eventually become harmonised standards supporting the Regulation.³⁴

As of 3 October 2026, however, EN 50742 has not yet been published as a final European Standard and has not been cited in the Official Journal under Regulation (EU) 2023/1230. The project has progressed beyond the earlier public-enquiry draft and is now circulating as FprEN 50742:2026 in the formal-approval phase. Even publication of the final EN will not, by itself, create a presumption of conformity: that legal effect arises only if and when its reference is published in the Official Journal under the Machinery Regulation.³⁵

The machine is now partly software

The most consequential provisions are not hidden in a recital about cybersecurity. They are requirements in Annex III, meaning they become part of the safety case against which machinery conformity is assessed.

Explicit digital requirements

The following table separates what the law actually says from the engineering response that may be reasonable.

Legal provision	Regulatory requirement	Engineering meaning	Cybersecurity status
Article 3 — safety component	A safety component can be physical or digital, including software, where the statutory conditions are met. 36	Safety software can itself fall inside the machinery product-compliance perimeter.	Explicit
Article 3(16) — substantial modification	Modification may be made by physical or digital means after market placement/putting into service. The remaining statutory safety/risk conditions must also be satisfied. 37	PLC logic, firmware, software configuration or remote-function changes cannot be dismissed merely because nothing mechanical changed.	Explicit
Annex III §1.1.9 — connection	Connection of another device, including through a remote device communicating with the machinery, must not lead to a hazardous situation. 38	Every control-capable communication path needs a safety consequence analysis.	Explicit cyber-physical requirement
Annex III §1.1.9 — hardware	Hardware transmitting signals/data relevant to access to compliance-critical software must be adequately protected against accidental or intentional corruption, with evidence of intervention collected where relevant. 39	Controller interfaces, engineering ports, gateways and update paths become part of the safety trust boundary.	Explicit
Annex III §1.1.9 — software/data	Software and data critical to EHSR compliance must be identified and adequately protected against accidental or intentional corruption. 40	Safety logic, configuration, safe-speed values, interlock mappings and integrity-critical datasets need protection.	Explicit
Annex III §1.1.9 — software identity	The machine must identify software installed on it that is necessary for safe operation and make that information accessible. 41	Software/firmware version inventory ceases to be merely an IT asset-management convenience.	Explicit
Annex III §1.1.9 — intervention evidence	Machinery must collect evidence of legitimate or illegitimate software intervention or modification of installed software/configuration. 42	Auditability/tamper evidence is required; a particular SIEM technology is not.	Explicit logging/evidence obligation
Annex III §1.2.1(a)	Control systems must, where appropriate to circumstances and risks, withstand intended/unintended external influences including reasonably foreseeable malicious attempts from third parties leading to a hazardous situation. 43	Threat modelling becomes relevant to the machinery safety case whenever an attacker can influence hazard controls.	Explicit cybersecurity requirement
Annex III §1.2.1(d)	Limits of safety functions are established through risk assessment; changes to settings/rules, including during learning, must not create hazardous situations. 44	Adaptive algorithms cannot be allowed to learn their way outside the validated safety envelope.	Explicit; cyber controls may be one implementation
Annex III §1.2.1(f)	Traceability of interventions and uploaded safety-software versions is to be enabled and retained for the prescribed period, including a five-year traceability requirement tied to safety-software uploads. 45	Version provenance and change history need to survive commissioning and service.	Explicit
Annex III §1.2.1 — self-evolving systems	Systems with fully or partially self-evolving behaviour/logic and varying autonomy must remain within defined task/movement boundaries and retain prescribed safety-decision information. 46	Runtime adaptation requires bounded authority and retrospective evidence.	Explicit AI/autonomy requirement
Annex III §1.2.6	Interruption, restoration or fluctuation of the power supply or communication network connection must not produce hazardous situations. 47	Loss-of-network, packet loss, reconnection and stale/replayed command conditions require safe-state analysis.	Explicit digital-safety requirement
Annex IV technical documentation	Safety-related source code or programming logic may have to be provided to a competent authority following a reasoned request where normal documentation is insufficient to demonstrate conformity. 48	The PLC code is proprietary is not an absolute answer to a conformity investigation.	Explicit compliance-evidence rule
Article 10 — instructions	Manufacturers may use digital instructions subject to accessibility, availability and paper-safety-information conditions, particularly for non-professional users. 49	Documentation lifecycle and digital availability become product-compliance design questions.	Digital modernisation, not cybersecurity per se

Table 4: Digital and cyber-relevant provisions of Regulation (EU) 2023/1230 and their engineering significance.

A particularly important distinction emerges from §1.1.9. The Regulation does not prescribe a particular authentication protocol, firewall brand, cryptographic algorithm, secure-boot technology, MFA system, SBOM format or network topology. It states the safety objective: compliance-critical hardware, software and data must be protected against accidental and intentional corruption; connections must not create hazards; and interventions must leave evidence. Controls such as cryptographic firmware signing, role-based access, authenticated engineering sessions and configuration integrity checking are therefore possible engineering means of satisfying the requirement, not the literal requirement itself. ⁵⁰

That distinction matters legally. A machine manufacturer should be able to produce a chain of reasoning of the form:

EHSR → identified cyber-physical hazard → security/safety requirement → chosen control → verification evidence

rather than:

EHSR → we use IEC 62443 → assumed conformity.

The latter skips the actual machinery risk assessment.

Substantial modification by digital means

Substantial modification is the other major digital change. Article 3(16) expressly recognises modification by physical or digital means. But the term has a narrower legal meaning than significant software change. The modification must be made after market placement/putting into service, not be foreseen or planned by the original manufacturer, affect machinery safety by creating a new hazard or increasing an existing risk, and meet the further protective-measure conditions set out in the definition. Article 18 then provides that the natural or legal person carrying out such a substantial modification is considered a manufacturer for the purposes of the Regulation and assumes the corresponding obligations. ⁵¹

That produces very different answers for superficially similar digital changes:

Change	Likely treatment under the Article 3(16) test
Manufacturer-planned cybersecurity firmware update, installed through the validated update process, with no change to the safety envelope	Normally not substantial merely because it changes code. It was foreseen and does not necessarily create/increase a hazard. Compliance and configuration evidence still matter. 52
HMI bug fix with no influence on safety functions or control authority	Usually outside the substantial-modification test, assuming the risk assessment confirms no safety impact. 53
Integrator modifies PLC/safety PLC logic so an interlocked guard can be opened during a new automatic mode and additional safeguarding or safety-control changes are required	Strong candidate for a substantial modification; Article 18 may make the integrator the manufacturer of the affected machinery. 54
Addition of permanent remote-control functionality not envisaged by the OEM, enabling machine motion from outside the original operator location	Not automatically substantial, but it may satisfy the test if it creates/increases risk and necessitates the statutory protective measures. 55
Cloud optimisation sends only recommendations that are validated and bounded by existing local safety/control limits	The presence of cloud software is not enough; the safety effect must be evaluated against Article 3(16). 56
Cloud optimisation receives unrestricted write authority over speeds, trajectories or safety-relevant parameters	Much more likely to change the hazard/control model; whether it legally crosses the substantial-modification threshold still depends on the complete statutory test. 57

Table 5: Examples illustrating how Article 3(16) may apply to digital modifications.

The practical lesson is that digital modification and substantial modification are not synonyms. Conversely, we only changed software is no longer a viable categorical argument against the possibility of substantial modification. ⁵⁸

When a cyberattack becomes a machinery-safety event

The Regulation’s cyber provisions are easier to interpret if the problem is modelled not as a catalogue of cybersecurity controls but as a causal path from digital compromise to machinery hazard. The crucial question is not simply whether a machine contains a vulnerability, but whether exploitation of that vulnerability can cross the machine’s digital trust boundary, alter behaviour or control authority, and ultimately invalidate a safety assumption.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR

    subgraph T["Threat and access paths"]
        T1[Remote maintenance<br/>or vendor access]
        T2[Plant or machine<br/>network interface]
        T3[Engineering workstation<br/>or programming tool]
        T4[Software / firmware<br/>update path]
        T5[Connected service<br/>edge or cloud]
    end

    subgraph D["Safety-relevant digital dependencies"]
        D1[Software and<br/>control logic]
        D2[Configuration and<br/>safety parameters]
        D3[Sensor and<br/>process data]
        D4[Communication<br/>state and messages]
        D5[Control authority<br/>and privileges]
    end

    subgraph C["Control-system consequence"]
        C1[Unauthorised or<br/>altered command]
        C2[Safety action<br/>inhibited or bypassed]
        C3[Incorrect state<br/>estimation]
        C4[Unsafe response to<br/>loss / restoration of communication]
        C5[Validated operating<br/>limits exceeded]
    end

    subgraph H["Hazardous machine behaviour / degraded protection"]
        H1[Unexpected start<br/>or movement]
        H2[Excessive speed,<br/>force or torque]
        H3[Guard / interlock<br/>protection defeated]
        H4[Unsafe mode,<br/>sequence or trajectory]
    end

    P[Exposure of a person] --> R[Physical harm]

    T1 --> D5
    T1 --> D1
    T2 --> D4
    T2 --> D5
    T3 --> D1
    T3 --> D2
    T4 --> D1
    T4 --> D2
    T5 --> D3
    T5 --> D5

    D1 --> C1
    D1 --> C2
    D2 --> C2
    D2 --> C5
    D3 --> C3
    D4 --> C4
    D5 --> C1
    D5 --> C2

    C1 --> H1
    C1 --> H4
    C2 --> H3
    C3 --> H4
    C4 --> H1
    C4 --> H4
    C5 --> H2

    H1 --> P
    H2 --> P
    H3 --> P
    H4 --> P

    E119["Annex III §1.1.9<br/>Protection against corruption"]
    E121["Annex III §1.2.1<br/>Safety and reliability<br/>of control systems"]
    E126["Annex III §1.2.6<br/>Power / communication<br/>failure"]

    E119 -. protects .-> D1
    E119 -. protects .-> D2
    E119 -. protects .-> D3
    E119 -. protects .-> D4
    E119 -. protects .-> D5

    E121 -. constrains .-> C1
    E121 -. constrains .-> C2
    E121 -. constrains .-> C3
    E121 -. constrains .-> C5

    E126 -. constrains .-> C4

Figure 1: Cyber-physical causal model linking attack paths, corrupted digital dependencies, unsafe control effects and machinery hazards.

The diagram separates three questions that are easy to collapse into a generic notion of cybersecurity:

1. There is the attack path: remote maintenance, an engineering workstation, a network interface, an update mechanism or a connected external service. These mechanisms are not hazardous merely because they are connected. They become relevant when they provide a route to a digital dependency on which safe machine behaviour relies.
2. There is the digital dependency itself: software, configuration, safety parameters, sensor data, communications or control authority. This is where Annex III §1.1.9 becomes particularly important. Its concern is not the existence of an exploitable vulnerability in the abstract, but the protection of hardware, software and data whose corruption can affect compliance with the applicable safety requirements.
3. Compromise must produce a control-system consequence before it becomes a machinery-safety event. The attacker may alter a command, inhibit a protective action, corrupt the machine’s estimate of its physical state, change a validated operating limit or exploit the machine’s response to communication loss or restoration. Those effects can then produce unexpected motion, excessive force or speed, defeated interlocks or another hazardous operating state.

This is where §1.2.1 adds a distinct requirement. Protection against corruption is not sufficient if the control architecture still permits a reasonably foreseeable malicious external influence to produce a hazardous situation. The Regulation therefore reaches beyond protection of individual digital assets and into the behaviour of the control system as a whole. Section 1.2.6 addresses a related but narrower causal path: interruption, restoration or fluctuation of a communication-network connection must itself not result in hazardous behaviour.⁵⁹

The important boundary is therefore:

cyber vulnerability ≠ machinery-safety non-conformity

but, potentially,

cyber vulnerability → compromised safety-relevant dependency → unsafe control effect → hazardous machine state → possible failure of an applicable EHSR / machinery-safety non-conformity

That distinction explains why the Regulation does not create a general-purpose OT cybersecurity regime. A compromise that exposes production data without affecting machinery behaviour may remain highly significant under the Cyber Resilience Act, NIS2 or the operator’s own cybersecurity requirements, but it does not automatically become an Annex III machinery-safety failure. The Machinery Regulation becomes directly engaged when the digital compromise can alter the causal conditions under which the machine remains physically safe.

Cyber-physical threat scenarios

This produces a useful threat model for industrial machinery.

Threat scenario	Security consequence	Possible safety consequence	Principal Machinery Regulation hook
Stolen vendor credentials give an attacker engineering access to a PLC	Unauthorised logic/configuration modification	Unexpected motion or removal of safe sequencing	Annex III §§1.1.9, 1.2.1 60
Safety PLC password/account compromised	Modification of safety logic or parameters	Guard bypass, incorrect safe-speed limit, defeated stop function	§§1.1.9, 1.2.1
HMI compromised and command channel permits remote start	Control authority captured	Person exposed to unexpected start	§§1.1.9, 1.2.1
Network injection changes VFD speed/torque command	Command integrity lost	Speed/force exceeds assumptions underlying risk reduction	§§1.1.9, 1.2.1
OPC UA credentials permit writes to safety-relevant tags	Authorised protocol used by unauthorised actor	Safety envelope/setpoint altered	§§1.1.9, 1.2.1
Manipulated sensor values	State estimation corrupted	Controller fails to detect person, obstruction or unsafe position	§§1.1.9, 1.2.1
Malicious firmware update to drive/controller	Trusted execution base corrupted	STO/safe-motion or braking assumptions invalidated	§§1.1.9, 1.2.1
Remote gateway compromise	New privileged path to internal controls	Any downstream unsafe control action enabled by the path	§§1.1.9, 1.2.1
Network outage/reconnection creates stale or replayed command	Communications state loses integrity/availability	Unexpected restart, uncontrolled parameter change or inability to stop	§1.2.6 61
ML safety component poisoned or its parameters maliciously altered	Learned decision boundary changed	Safety decisions depart from validated limits	§1.2.1 and AI/ML provisions 62
Production historian exfiltrated, with no ability to affect machine control	Confidentiality loss	No necessary physical safety effect	Possibly CRA/NIS2 issue; not automatically an MR EHSR failure. 63

Table 6: Cyber-physical threat scenarios and the Machinery Regulation provisions they may implicate.

This is why the expression cyber-physical safety is useful. It does not mean that safety and security have become identical. It means the independence assumption between the two domains is no longer defensible when security compromise can invalidate a safety assumption.

Functional safety meets adversarial behaviour

Traditional machinery risk engineering remains indispensable. ISO 12100 specifies machinery risk assessment and risk reduction across relevant lifecycle phases; ISO 13849-1:2023 addresses the design and integration of safety-related parts of control systems, including software; IEC 62061:2021 addresses design, integration and validation of machinery safety-related control systems and is a machinery-sector implementation within the IEC 61508 framework. ⁶⁴

What changes is the failure model. Performance Level or SIL reasoning can establish how a safety function tolerates defined random and systematic failures, but an adversary can intentionally select inputs, credentials, configuration pathways and timing to defeat assumptions shared across otherwise independent protection layers. A safety PLC with an excellent dangerous-failure probability does not solve the problem if an attacker can legitimately authenticate with a stolen engineering account and upload a hazardous configuration.

IEC itself now makes the relationship explicit in IEC TS 63074:2023, Safety of machinery — Security aspects related to functional safety of safety-related control systems. The specification identifies IEC 62443 security threats and vulnerabilities that can lead to loss of the ability of a machinery safety-related control system to maintain safe operation and explicitly includes threat modelling in its scope. That is powerful evidence that functional safety and cybersecurity are distinct engineering disciplines whose risk models have to meet at the safety-related control system. ⁶⁵

The risk-assessment implication can therefore be derived without overreading the Regulation:

1. Annex III §1.2.1 explicitly introduces reasonably foreseeable malicious third-party attempts into the control-system safety requirement. ⁶⁶
   
2. ISO 12100 requires identification and assessment of machinery hazards and risk reduction. ⁶⁷
   
3. IEC TS 63074 demonstrates that security threats/vulnerabilities can cause loss of machinery safety-control capability. ⁶⁸
   
4. Therefore, where cyber compromise can defeat a risk-reduction measure or produce a hazardous state, the cyber pathway has to enter the machine safety analysis.

That does not require calculating a SIL for hacking. It requires determining which cyber events can invalidate safety functions and ensuring that the machine architecture prevents, constrains or safely handles those events.

The most useful design question becomes:

What must an attacker be able to alter before this machine can hurt somebody?

The answer identifies the machine’s safety-security trust boundary: safety PLC logic, safety parameters, safe-motion configuration, firmware authenticity, interlock mapping, authorised modes, control ownership, sensor trust, update mechanisms and the communication paths capable of changing them.

From connected machine to defensible architecture

IEC 62443 as an engineering implementation framework

IEC 62443 is currently the strongest general engineering framework for translating that trust boundary into industrial cybersecurity architecture, but it must be used with the correct legal status. The IEC describes the 62443 series as addressing security of industrial automation and control systems throughout their lifecycle. IEC 62443-3-2 addresses system security risk assessment and zones/conduits; IEC 62443-3-3 provides system security requirements; IEC 62443-4-1 specifies a secure product-development lifecycle; and IEC 62443-4-2 specifies technical security requirements for IACS components. ⁶⁹

IEC 62443 is not made mandatory by Regulation (EU) 2023/1230, nor, as of 3 October 2026, is there a Machinery Regulation harmonisation decision making the series a blanket presumption-of-conformity route for Annex III §§1.1.9 and 1.2.1. The first Machinery Regulation harmonised-standard list is still being prepared. EN 50742 is the more machinery-specific standardisation project explicitly entitled Safety of machinery — Protection against corruption; as of 3 October 2026 it has progressed to FprEN 50742:2026 in the formal-approval phase, but has not yet been published as a final European Standard or cited in the Official Journal under the Machinery Regulation. ⁷⁰

The correct relationship is therefore:

Machinery Regulation = required safety outcome and IEC 62443 = useful engineering mechanism for achieving and evidencing parts of that outcome

not:

IEC 62443 certificate = automatic Machinery Regulation compliance.

A practical mapping looks like this.

Machinery concern	Useful IEC 62443 engineering layer	Why
Identify malicious paths capable of changing machine state	62443-3-2	System-under-consideration analysis, zones/conduits and cybersecurity risk assessment. 71
Prevent unauthorised users/devices controlling machinery	62443-3-3 / 4-2: Identification & Authentication Control, Use Control	Authentication and authorisation support protection of safety-relevant access paths. 72
Prevent corruption of software/configuration	System Integrity in 3-3/4-2 plus 4-1	Supports integrity, secure development, verification and controlled updates. 73
Restrict PLC/safety-controller exposure	Restricted Data Flow; zones and conduits	Limits paths from enterprise, cloud, vendor or HMI zones to control assets. 74
Generate evidence of intervention	Timely Response to Events plus audit mechanisms	Supports detection/event evidence; the MR itself establishes the safety-related evidence requirement. 75
Resist network/resource disruption	Resource Availability	Complements the MR §1.2.6 safe-behaviour requirement under network interruption. 76
Secure controller/product development	62443-4-1	Secure-development lifecycle, verification, defect and patch management. 77
Secure PLC/HMI/gateway components	62443-4-2	Component-level requirements for embedded, host, network and software components. 78
Secure OEM/integrator remote-service processes	62443-2-4	Security-program requirements for IACS service providers. 79
Operate and maintain the installed machine securely	62443-2-1	Asset-owner security management and lifecycle governance. 80

Table 7: Mapping Machinery Regulation concerns to relevant IEC 62443 engineering layers.

The seven 62443 foundational requirement families—identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events and resource availability—are useful, but their relevance to machinery safety is not symmetrical. Integrity, authentication, use control, restricted data flow, event evidence and availability often have direct cyber-physical significance; confidentiality may be essential under other legislation yet have little machinery-safety significance unless loss of confidentiality enables or contributes to a hazardous attack. ⁸¹

Reference architecture

A defensible connected-machine architecture should be derived from the digital dependencies of the safety case, not from operational convenience or inherited network topology. The objective is not simply to segment the network, but to ensure that reachability, manageability and control authority remain distinct things. A system may be reachable for monitoring without being reachable for administration; administrable without being able to program the controller; and able to exchange production data without being able to alter a safety limit.

That is why IEC 62443’s zones-and-conduits model is useful here: it provides a structured way to separate systems according to function, trust level and required interaction, while Regulation (EU) 2023/1230 supplies the safety outcome that the architecture must protect.⁸²

A defensible connected-machine architecture can therefore be represented as follows:

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD

    subgraph EXT["External and enterprise services"]
        V[Vendor Remote Service]
        I[Identity / approval / PAM]
        P[Plant SCADA / MES / historian]
        A[Cloud Analytics]
        L[Logging / monitoring / backup]
        T[Time synchronisation]
    end

    subgraph BND["Plant OT boundary"]
        R[Remote Access Gateway<br/>default off / per-user VPN]
        J[Jump Host / Session Broker]
        F[OT Firewall]
    end

    subgraph MDMZ["Machine DMZ / Industrial Edge"]
        D[Machine DMZ / Edge Services<br/>protocol mediation / local historian<br/>update staging / data broker]
        E[HMI / Engineering Zone<br/>HMI / engineering workstation<br/>local maintenance tools]
    end

    subgraph CORE["Machine execution core"]
        C[Machine Control Zone<br/>PLC / CNC / robot controller / VFD]
        S[Machine Safety Zone<br/>Safety PLC / safe I/O / interlocks<br/>safe motion / protective functions]
    end

    V -->|named user + MFA + VPN/TLS| R
    I -->|authorisation / approval context| R
    R -->|time-bounded session| J
    J -->|proxied remote maintenance| E

    P -->|application-specific OT flows| F
    F --> D
    D -->|mediated operational data<br/>recipes / patch staging| E
    E -->|approved engineering / HMI access| C
    C <--> |bounded control-safety interface| S

    C -->|status / alarms / production data| D
    D -->|outbound telemetry only| A

    E -->|logs / configuration evidence| L
    C -->|logs / events / baselines| L
    S -->|safety events / change evidence| L

    T --> D
    T --> E
    T --> C
    T --> S

    X[No direct enterprise, vendor<br/>or cloud path to control or safety]
    X -. boundary rule .-> C
    X -. boundary rule .-> S

Figure 2: Reference architecture for a connected industrial machine, separating enterprise and remote-service functions, plant OT integration, machine DMZ services, engineering access, machine control and safety functions.

The diagram is intended to show functional separation and authority separation, not just layer-3 segmentation. It distinguishes six architectural roles:

1. External and enterprise services. These include vendor support, plant supervisory applications, cloud analytics, logging infrastructure and time synchronisation. They may be operationally necessary, but none of them should automatically inherit authority over machine execution or safety state.
2. Plant OT boundary. The OT firewall, remote-access gateway and jump or session-broker functions form the boundary through which external actors or plant-level systems reach the machine environment. This is where identity, approval, session initiation and high-level policy enforcement are anchored. In architectural terms, this boundary should convert generic connectivity into explicitly mediated conduits.
3. Machine DMZ / industrial edge. This zone is the integration and buffering layer between the machine and the plant or external world. It is the natural location for protocol mediation, local historians, edge brokers, update staging, telemetry export and similar boundary services. Its purpose is not merely to sit between networks, but to absorb functions that would otherwise create direct trust relationships with the machine-control environment.
4. HMI / engineering zone. This zone hosts the interfaces through which humans operate, diagnose, adjust or engineer the machine. It is a privileged zone and should be treated as such. It is frequently the practical bridge between business requirements and control logic, which makes it one of the most consequential trust boundaries in the machine.
5. Machine control zone. This is the execution plane of the machine: PLCs, robot controllers, CNCs, motion controllers and drives. It is the zone that turns logic and parameters into physical behaviour. It must not be treated as a generic OT subnet. From the standpoint of machinery safety, it contains assets whose corruption can directly change force, speed, movement, sequencing or actuation.
6. Machine safety zone. This contains the safety PLC, safe I/O, safe motion functions, interlocks and associated protective logic. It is not merely another controller subnet; it is the digital embodiment of protective functions on which the safety case relies. Its interface to the control zone should therefore be tightly bounded, highly intentional and demonstrably justified.

The architecture should then be read in terms of conduits, not only zones. The most important conduits are the following.

• Remote-maintenance conduit: vendor service → remote-access gateway → jump host/session broker → HMI/engineering zone. This conduit exists for troubleshooting and maintenance, not as a permanent, standing extension of the vendor network into the machine.
• Plant-integration conduit: plant SCADA/MES/historian → OT firewall → machine DMZ. This conduit should carry only those industrial data exchanges required for production, coordination or supervision. Its semantics matter: a read-only production-data flow is architecturally different from a recipe-write function, and both are different again from controller programming access.
• Engineering conduit: HMI/engineering zone → control zone. This is a high-consequence conduit because it often carries the authority to change logic, parameters and operating modes. For that reason, it should be mediated by role, session context and approval, not treated as an ordinary internal trust relationship.
• Control–safety conduit: control zone ↔︎ safety zone. This conduit must exist, but it should be deliberately narrow. Only the information and commands necessary for safe coordinated operation should cross it. Its design should support the principle that ordinary control or production functions cannot silently expand into safety authority.
• Telemetry conduit: machine DMZ → cloud analytics. This conduit should normally be outbound and scoped to telemetry or analytics data. The key architectural discipline is that a service justified by observation does not thereby acquire the right to command.
• Evidence and support conduits: machine zones → logging/monitoring/backup; time source → machine zones. These conduits support traceability, recovery and temporal coherence. They matter directly because the Regulation requires evidence of intervention and traceability of safety-relevant software changes, while distributed troubleshooting and forensics become unreliable without trustworthy time alignment.⁸³

The architectural principle that follows is simple but far-reaching:

Connectivity should not automatically confer control authority.

An OPC UA session used to read production counts does not inherently need to write a speed limit. A cloud analytics service used for predictive maintenance does not inherently need controller-programming rights. An OEM maintenance tunnel does not inherently need permanent reachability to a safety PLC. A MES recipe service does not inherently need authority to overwrite the parameters that delimit a validated safe-motion function.

That is least privilege applied to physical causality. The relevant question is not only what access does this system need? but what hazardous physical effect could this system produce if its authority were abused or its integrity lost? This is the point at which enterprise-architecture thinking and machinery-safety analysis meet: authority has to be modelled not just by user role or application function, but by the physical consequences that the granted capability can trigger.

This also means that the reference architecture should separate at least four kinds of authority:

• observe: read data, alarms, states, logs or telemetry;
• operate: initiate normal production commands within the validated operating envelope;
• configure: change parameters, recipes or settings that influence machine behaviour;
• engineer: alter logic, firmware, safety functions or the configuration baseline itself.

These should not be conflated. Many connected systems need observation. Fewer need operation. Very few should be able to configure behaviour, and fewer still should be able to engineer the machine. Where those capabilities are combined, the safety case should explain why.

The safety zone should therefore have the narrowest trust boundary in the entire architecture. Depending on the machine and the risk assessment, appropriate engineering measures may include separate engineering roles, local enable conditions for especially sensitive actions, validated parameter ranges, cryptographically protected configuration where supported, signed or hashed baselines, authenticated software loading, independently enforced safe-motion constraints, strict change traceability and monitored access. None of these mechanisms is prescribed verbatim by Annex III. Their justification is architectural: they reduce the number of paths by which corruption or malicious influence can invalidate a protective function.⁸⁴

It is equally important to say what the reference architecture normally excludes:

• no direct Internet path to PLCs, robot controllers, drives or safety controllers;
• no direct cloud-to-controller write path justified merely by analytical convenience;
• no permanent vendor tunnel that bypasses plant approval and session control;
• no flat trust relationship between HMI/engineering systems and safety logic;
• no assumption that internal OT is sufficiently trusted to dispense with attribution, role separation or evidence of change;
• no uncontrolled path by which enterprise systems can acquire machine-control authority.

This is why the architecture should be understood as an authority architecture, not just a network diagram. The legal driver is still the Machinery Regulation’s requirement that connections, corruption and malicious external influence must not lead to hazardous situations. The engineering task is to translate that into zones, conduits, identities, roles, approval paths, software integrity controls, evidence generation and recovery design. In that sense, the diagram is not merely an illustration of segmentation. It is a model of how to preserve the assumptions under which the machine remains physically safe.⁸⁵

Remote access is remote authority

Remote access deserves special treatment because it collapses geography without reducing authority. An engineer thousands of kilometres away can, depending on implementation, possess the same logical privileges as a person connected locally to an engineering port. In some architectures, the remote path can be even more consequential because it traverses several independently administered systems—vendor identity infrastructure, VPN concentrators, cloud brokers, jump hosts, engineering workstations and machine controllers—before reaching the asset that can produce physical motion.

For machinery safety, the relevant architectural question is therefore not simply whether remote access is encrypted. It is:

What machine authority becomes available when the remote session succeeds?

A VPN may provide excellent cryptographic protection while still exposing an unnecessarily broad control surface. MFA may reduce credential theft without limiting what an authenticated engineer can change. A jump host may create an auditable choke point while still permitting unrestricted PLC or safety-PLC programming. These controls are important, but their safety value depends on the authority exposed beyond them.

Annex III does not prescribe MFA, PAM, jump hosts or a particular VPN architecture. It establishes the safety outcome: connected or remote paths must not create hazardous situations, compliance-critical software and data must be protected against corruption, and relevant control systems must withstand reasonably foreseeable malicious attempts capable of producing hazards.⁸⁶

Remote maintenance should therefore be modelled as a privileged control conduit with a lifecycle, rather than as a permanent network connection.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD

    A[Default deny<br/>no active remote path]

    subgraph ID["Identity and request"]
        B[Named engineer<br/>individual identity]
        C[MFA / credential validation]
        D[Maintenance request<br/>asset + purpose + scope]
    end

    subgraph AUTH["Plant authorisation"]
        E[Owner / operator approval]
        F[Maintenance window<br/>time limitation]
        G[Requested authority class]
    end

    subgraph PATH["Controlled remote conduit"]
        H[Remote Access Gateway<br/>plant controlled]
        I[Jump Host / Session Broker]
        J[Protocol / destination restriction]
    end

    subgraph AUTHORITY["Granted machine authority"]
        K1[Observe<br/>read-only]
        K2[Operate<br/>validated commands]
        K3[Configure<br/>parameters / recipes]
        K4[Engineer<br/>logic / firmware / safety]
    end

    subgraph SAFETY["Safety-sensitive change gate"]
        L[Change request / approved task]
        M[Elevated privilege]
        N[Local enabling condition<br/>where risk justifies]
        O[PLC / safety PLC / drive<br/>programming or configuration]
    end

    subgraph EVIDENCE["Monitoring and closure"]
        P[Session monitoring<br/>user + target + actions]
        Q[Configuration / software<br/>change evidence]
        R[Session termination]
        S[Automatic privilege<br/>and tunnel revocation]
        T[Baseline reconciliation<br/>and retained evidence]
    end

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I
    I --> J

    J --> K1
    J --> K2
    J --> K3
    J --> K4

    K1 --> P
    K2 --> P
    K3 --> P
    K4 --> L

    L --> M
    M --> N
    N --> O
    O --> P

    P --> Q
    Q --> R
    R --> S
    S --> T
    T --> A

    X[Break-glass path<br/>separately governed]
    X -. exceptional use .-> H
    X -. enhanced review .-> T

Figure 3: Reference control model for privileged remote maintenance, separating request, authorisation, connectivity, session authority, safety-sensitive change control and post-session evidence.

The important point is that remote access should not be modelled as binary—connected or disconnected. A mature architecture separates at least four levels of authority.

Authority class	Typical remote capability	Safety significance
Observe	View alarms, trends, diagnostics, logs and machine state	Normally lowest consequence; compromise should not permit state changes.
Operate	Issue validated operational commands within the existing operating envelope	Can cause physical action and therefore requires stronger session and command controls.
Configure	Change recipes, parameters, limits or operating modes	Can alter behaviour assumptions even without changing controller logic.
Engineer	Upload PLC logic, modify safety configuration, change firmware or redefine protective functions	Highest consequence because it can modify the machine’s validated control and safety baseline.

Table 8: Remote-access authority classes and their increasing ability to influence machinery behaviour.

A remote-access architecture should grant the lowest authority class compatible with the maintenance task. A vendor diagnosing a drive fault may need read access to diagnostics but not PLC programming. An OEM adjusting an ordinary recipe may require configuration privileges but not access to safety logic. Safety PLC programming, firmware replacement or modification of safe-motion parameters belongs to a different authority class again and may justify additional controls such as separate approval, temporary privilege elevation or a local physical enabling condition.

This distinction prevents a common architecture error: treating successful authentication as sufficient justification for unrestricted access. Authentication answers who the remote user is; authorisation determines what that user may do; safety engineering determines what physical consequences those authorised actions may produce.

The remote-access conduit should therefore be constrained along several independent dimensions:

• identity: individual rather than shared accounts, attributable to a specific engineer;
• purpose: access linked to a maintenance request or approved operational need;
• asset scope: explicit target systems rather than general reachability into the machine network;
• protocol scope: only the protocols required for the task;
• authority scope: observe, operate, configure or engineer;
• time: a bounded maintenance window rather than indefinite entitlement;
• session state: access activated for the approved task and revoked afterwards;
• change scope: safety-sensitive modifications subject to an additional control gate;
• evidence: sufficient logging to reconstruct who connected, to which asset, with which privilege and what was changed.

This gives a more precise formulation of deny by default. It does not merely mean that the firewall blocks an inbound packet until somebody opens a rule. It means that, outside an authorised maintenance event, no complete chain of identity, routing, privilege and application authority exists by which an external actor can exercise engineering control over the machine.

Plant-controlled versus vendor-controlled remote access

The ownership of the remote-access control plane also matters. A vendor-controlled appliance installed inside the machine may initiate an outbound tunnel to a cloud service and therefore avoid conventional inbound firewall exposure, but from an authority perspective the result may still be a persistent vendor-controlled path into the machine. Outbound only is consequently not synonymous with low risk.

A plant-controlled remote-access architecture provides stronger separation of duties because the asset owner controls whether the conduit exists, which target can be reached and when the session is permitted. Vendor identity can still be federated or accepted, but vendor authentication should not automatically equal plant authorisation.

The preferred trust sequence is therefore:

vendor identity → plant authorisation → temporary conduit → constrained machine authority

rather than:

vendor identity → permanent machine reachability

This distinction becomes especially important when the vendor’s identity provider, cloud remote-support platform or support organisation lies outside the manufacturer’s or asset owner’s direct security governance.

Jump hosts and session brokers

A jump host is valuable only if it actually reduces and mediates authority. Placing a Windows server between a VPN and a PLC does not improve the safety architecture if the user can immediately open an unrestricted engineering tool and reach every controller.

A useful jump or session-broker function should instead provide some combination of:

• destination allowlisting;
• protocol restriction;
• separate administrative roles;
• session attribution;
• file-transfer control;
• clipboard or data-transfer constraints where justified;
• temporary credential issuance;
• recording or command/event logging where technically feasible;
• prohibition of lateral movement beyond the approved target;
• automatic session termination and privilege revocation.

The function of the jump layer is therefore not simply to add another host. It should convert broad network access into a narrowly defined maintenance transaction.

Remote access to safety systems

Access to the safety zone deserves a stronger rule than access to ordinary control assets. The risk is not merely that an attacker can issue an operational command; engineering access can modify the very mechanism intended to constrain unsafe commands.

For safety PLCs, safe drives and other configurable protective systems, the architecture should therefore determine explicitly:

• whether remote engineering is allowed at all;
• whether it is permitted only for diagnostics and readback;
• whether programming requires separate credentials;
• whether an additional local mode or physical enabling action is required;
• how the safety configuration is baselined before and after intervention;
• how software or parameter changes are attributable;
• whether the modified safety function requires revalidation before production resumes.

Where a remote engineer can modify a validated safe-speed limit, interlock condition or safety program, the architecture has crossed from remote IT administration into remote modification of the machinery safety case.

Session monitoring is not enough: change evidence matters

Conventional remote-access products often emphasise session recording. That is useful, but Annex III’s concern with intervention and modification suggests a stronger evidentiary model.

For high-consequence maintenance, the relevant evidence may include:

who → accessed what → under which approval → using which privilege → changed which software/configuration → from which version → to which version → with what subsequent validation

A video recording of a remote desktop session may support investigation, but a machine-readable configuration baseline, PLC project hash, firmware identifier, safety parameter export or controlled change record is usually stronger evidence of what actually changed.

The architecture should therefore connect remote access to configuration management and baseline reconciliation, not just security-event logging.

Break-glass access

Some plants require emergency remote support outside the normal approval path. That does not invalidate the architecture, but it should be treated explicitly as a break-glass mechanism, not as an excuse to retain permanent privileged access.

A defensible break-glass path can use stronger compensating controls: restricted eligibility, explicit emergency declaration, heightened logging, immediate alerting, short validity, automatic revocation and mandatory post-event review. If the mechanism permits safety-sensitive changes, the post-event process should also establish whether the validated machine baseline has changed and whether revalidation is necessary.

Derived controls and the legal boundary

MFA, named accounts, plant-controlled gateways, temporary credentials, PAM, jump hosts, session recording, firewall rules, protocol restrictions, maintenance windows, local enabling conditions and automatic revocation are derived engineering controls. Regulation 2023/1230 does not prescribe this architecture verbatim.

They become relevant where the threat model shows that misuse or compromise of the remote-maintenance path can reach the hazardous states addressed by Annex III §§1.1.9 and 1.2.1. IEC 62443-2-4, IEC 62443-3-2 and IEC 62443-3-3 provide a useful engineering framework for turning that risk into service-provider requirements, zones and conduits, access-control requirements and restricted data flows.⁸⁷

This is why permanent vendor VPNs, shared service accounts, unmanaged support appliances and remote-desktop tools installed directly on HMIs deserve close scrutiny. They are not automatically prohibited by the Machinery Regulation. The regulatory question is whether the resulting architecture adequately protects compliance-critical software, configuration and control systems and whether a reasonably foreseeable malicious use of that path can produce a hazardous situation.

The fact that an operational stakeholder requested a particular remote-access mechanism does not answer that question.

The customer requested TeamViewer is a functional requirement, not a safety justification.

The manufacturer or integrator still has to demonstrate that the resulting remote authority is bounded in a way that preserves the machinery safety case.

Standards landscape

The standards landscape as of 3 October 2026 can therefore be characterised as follows:

Standard / family	Role	Machinery Regulation status as of 3 October 2026
ISO 12100:2010	Machinery risk assessment/risk reduction. 88	Foundational machinery-safety reference; exact MR harmonisation list still pending. 89
ISO 13849-1:2023	Safety-related control-system design, including software. 90	Important functional-safety standard; future MR OJ status must be checked when list publishes.
ISO 13849-2	Validation of safety-related control systems. 91	Functional-safety validation, not general cybersecurity.
IEC 62061:2021, incl. current amendments	Machinery functional safety of safety-related control systems. 92	Functional-safety framework; not a complete security framework.
IEC 61508 series	Generic functional-safety basis for E/E/PE safety-related systems.	Generic rather than machinery-specific; IEC 62061 is the machinery-sector application. 93
IEC TS 63074:2023	Security aspects related to machinery functional safety. 94	Highly relevant bridge document; a Technical Specification, not itself a blanket harmonised-MR route.
IEC 62443 series	IACS cybersecurity across product, system, service-provider and asset-owner lifecycle. 95	Powerful engineering reference, not mandated by MR.
FprEN 50742:2026	Safety of machinery — Protection against corruption.	Formal-approval stage as of 3 October 2026; not yet published as a final EN and not yet cited in the Official Journal under Regulation (EU) 2023/1230. 96
ISO/IEC 27001	Organisational information-security management	Useful organisationally but not a machine/product-safety conformity route.
ETSI EN 303 645	Consumer-IoT security reference	Not a general Machinery Regulation compliance standard.
EN 18031 family	Cybersecurity standardisation in another EU product-law context	It should not be assumed to confer Machinery Regulation conformity; applicability depends on the separate product regime involved.

Table 9: Standards relevant to machinery safety, functional safety and cybersecurity, with their status as of 3 October 2026.

The broader point is important: harmonised-standard status is legal metadata, not a property intrinsic to a technically good standard. A technically excellent IEC 62443 implementation can provide strong evidence but does not acquire presumption of conformity until the applicable EU legal mechanism says that it does. The Commission’s current machinery page is explicit that the first Regulation-specific harmonised list is still forthcoming. ⁹⁷

AI, the Cyber Resilience Act and NIS2: one machine, multiple legal lenses

AI and autonomous behaviour

The digital-regulatory picture changed materially again in July 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and amended both the AI Act and Regulation 2023/1230. The Commission’s current AI Act page confirms that high-risk AI rules for systems embedded in regulated Annex I products now have an extended transition to 2 August 2028 and that the amendment was designed in part to clarify interaction between the AI Act and product-safety legislation, particularly the Machinery Regulation. ⁹⁸

The amendment is particularly relevant to machinery. It adds to Machinery Regulation Article 8 a delegation requiring the Commission to amend Annex III with health and safety requirements for AI systems classified as high-risk under the AI Act because they are safety components of machinery or themselves covered products, reflecting the relevant AI Act requirements; those delegated acts are to apply by 2 August 2028. It also adds a transitional presumption-of-conformity bridge in Article 20 for relevant AI standards/common specifications. ⁹⁹

This does not mean that machinery has no AI requirements until 2028. Regulation 2023/1230 already contains machinery-specific obligations concerning fully or partially self-evolving behaviour, varying autonomy, safety-function limits and records of safety-related software decisions; Annex I also specifically addresses ML-based safety-function categories for conformity assessment. Those machinery provisions apply with the Regulation’s main regime from 20 January 2027. ¹⁰⁰

Nor should four distinct technologies be conflated:

Technology	Machinery analysis
Deterministic PLC logic	Ordinary automation; still subject to software integrity and cyber-safety requirements when compromise can create hazards.
Adaptive controller	May become relevant to the self-evolving requirements if operating rules/behaviour change during operation; safety limits must remain bounded. 101
Machine-learning safety function	Explicitly important under the Machinery Regulation’s high-risk/conformity-assessment architecture and potentially the AI Act product-safety regime. 102
Generative AI	Not automatically a machinery safety component. Its legal significance depends on what it does. A chatbot describing maintenance manuals is fundamentally different from an AI agent authorised to generate and execute motion commands. 103

Table 10: Distinguishing deterministic automation, adaptive control, machine learning and generative AI in machinery analysis.

The Cyber Resilience Act

The next layer is the Cyber Resilience Act, Regulation (EU) 2024/2847. The CRA entered into force on 10 December 2024. Its main product obligations apply from 11 December 2027, while its reporting obligations apply from 11 September 2026—meaning that, as of the date of this research, the CRA reporting regime has already begun. The Commission characterises the CRA as imposing mandatory cybersecurity requirements across the planning, design, development and maintenance of products with digital elements, including vulnerability handling throughout their lifecycle. ¹⁰⁴

That timing creates a notable overlap:

• 11 September 2026: CRA vulnerability/incident reporting starts,
• 20 January 2027: Machinery Regulation main requirements, including Annex III cyber-safety, apply,
• 11 December 2027: CRA main product cybersecurity requirements apply,
• 2 August 2028: revised high-risk AI product timetable / machinery AI integration point.¹⁰⁵

The two product regulations solve different problems.

Lens	Core question	Typical obligations
Machinery Regulation	Can the machine cause injury or other covered harm, including because digital systems are corrupted or maliciously manipulated?	Risk reduction, EHSRs, safe control systems, protection against corruption, safety-software identification/logging, safe network-failure behaviour. 106
Cyber Resilience Act	Is the product with digital elements sufficiently cyber-resilient throughout its supported lifecycle?	Cyber risk assessment, secure design/default, vulnerability handling, security updates, vulnerability reporting, technical documentation and CRA conformity assessment. 107
NIS2	Is the organisation operating its network and information systems with adequate cybersecurity risk management and incident resilience?	Entity-level risk-management measures, incident handling, continuity, supply-chain security, vulnerability management, access security and MFA where appropriate. 108
AI Act/MR AI layer	Does safety-relevant AI meet the specific risk-management, data, technical, oversight and product-safety requirements applicable to high-risk AI?	AI-specific requirements according to classification and current transition timetable, increasingly integrated with sectoral product legislation. 109

Table 11: Four regulatory lenses that may apply simultaneously to a connected industrial machine.

A connected industrial machine can readily be a CRA product with digital elements when its intended or reasonably foreseeable use involves a direct or indirect data connection. Its embedded PLC/HMI software, update mechanism and vulnerabilities then matter even where a particular vulnerability would never generate a machinery hazard. The CRA addresses the larger product cybersecurity envelope; the Machinery Regulation narrows its cyber inquiry around health-and-safety consequences. ¹¹⁰

The intersection is the important part:

vulnerability → exploit → control-system compromise → unsafe physical state

At that point the same technical defect can matter under both laws. For example, an unauthenticated PLC firmware-update endpoint is a CRA problem because it is a cybersecurity weakness in a digital product. If exploiting it allows safety-critical behaviour to be changed so that a person can be injured, it is also a Machinery Regulation issue under Annex III §§1.1.9/1.2.1. The CRA itself recognises that its cybersecurity requirements and those of the Machinery Regulation can address similar cybersecurity risks; the regimes should therefore be engineered coherently rather than as unrelated compliance projects. ¹¹¹

The CRA additionally brings lifecycle mechanisms that the Machinery Regulation does not specify at the same level: vulnerability handling, security-update responsibilities, reporting and support-period responsibilities. Its vulnerability-handling requirements also make software-component knowledge and SBOM-type practices much more directly relevant. The CRA should thus become the product-security lifecycle layer, while Machinery Regulation analysis determines which of those security properties also form part of the safety case. ¹¹²

NIS2 and the plant operator

NIS2 sits somewhere else again. Directive (EU) 2022/2555 regulates entities and their network/information-system risk, not CE conformity of an individual machine. Article 21 covers such matters as risk-analysis policies, incident handling, business continuity, supply-chain security, secure acquisition/development/maintenance, vulnerability handling, cyber hygiene, access control and, where appropriate, multi-factor authentication. NIS2 also reaches manufacturing categories through its annexes, so a machinery manufacturer or plant operator may itself be an essential or important entity depending on sector, size and applicable national transposition. ¹¹³

This gives a useful first-principles model:

• Machinery Regulation → protect the person from hazardous machine behaviour.
• CRA → protect the digital product and its users against cybersecurity risk.
• NIS2 → protect the organisation and its network/information systems.
• AI Act / MR AI provisions → control risks specific to qualifying AI systems.

They overlap technically, but they are not interchangeable legally.

Lifecycle compliance: procurement, FAT/SAT, updates and substantial modification

The largest implementation mistake would be to treat Annex III §§1.1.9 and 1.2.1 as a cybersecurity feature to be added immediately before CE marking. The requirements touch architecture, component selection, development, integration, commissioning, maintenance and future updates. IEC 62443 reinforces this lifecycle view through the distinct responsibilities of product suppliers, system integrators/service providers and asset owners. ¹¹⁴

Procurement requirements

For procurement, requirements should therefore be classified according to their actual legal basis rather than all being labelled Machinery Regulation requirements.

Legend: MR-E = explicit Machinery Regulation requirement; MR-D = derived engineering measure supporting an MR safety requirement; CRA = Cyber Resilience Act requirement/supporting implementation; 62443 = IEC 62443 engineering practice; OWNER = purchaser/asset-owner contractual requirement.

Procurement requirement	Proper classification	Rationale
Inventory of safety-relevant software/firmware versions	MR-E + CRA	MR requires identification of software necessary for safe operation; CRA reinforces component/vulnerability lifecycle management. 115
SBOM in machine-readable form	CRA / OWNER, not a standalone MR mandate	Useful for vulnerability/component management; MR requires identification/protection of safety-relevant software but does not simply say provide an SBOM. 116
Secure configuration baseline	MR-D + 62443 + CRA	Demonstrates which configuration constitutes the validated machine state.
Unique named privileged accounts	MR-D + 62443	Supports attribution and prevention of unauthorised modification; MR states the safety outcome, not account syntax. 117
RBAC / least privilege	MR-D + 62443	Limits who can change safety/control state. 118
MFA for remote privileged access	MR-D + 62443 + NIS2 where applicable + OWNER	Strong response to credential-based remote attack; not literally prescribed by MR. 119
Disable unused services/ports	MR-D + CRA + 62443	Reduces paths capable of compromising compliance-critical assets.
Cryptographically protected/signed updates	MR-D + CRA + 62443	Strong implementation for preventing intentional software corruption and securing product updates. 120
Vulnerability-management process	CRA + 62443, and MR-D where vulnerabilities affect safety	CRA explicitly establishes lifecycle vulnerability responsibilities. 121
Patch policy and maximum remediation windows	CRA + OWNER; safety impact assessed under MR	CRA creates product-security lifecycle duties; purchaser should convert them into contractual service levels. 122
Plant-controlled remote-access gateway	MR-D + 62443 + OWNER	Limits the authority of remote paths; topology itself is not legally prescribed.
Complete network-interface and protocol documentation	OWNER + MR-D + 62443	Needed to establish attack surface and validate conduits.
Firewall / segmentation requirements	MR-D + 62443	Derived from threat model and restricted-data-flow design. 123
Safety/control logging and modification evidence	MR-E for the safety-related evidence required by Annex III, expanded by 62443/OWNER	The Regulation expressly requires intervention/configuration evidence and safety-software traceability. 124
Time synchronisation	62443 / OWNER / MR-D	Makes distributed evidence attributable and reconstructable; not an explicit MR requirement by itself.
Backup and tested restore of PLC/HMI/safety configurations	62443 + NIS2/OWNER + MR-D	Supports recovery and known-good restoration.
Coordinated vulnerability-disclosure contact	CRA + OWNER	Part of a mature vulnerability-handling lifecycle. 125
Support lifetime / end-of-support declaration	CRA + OWNER	Cyber support horizon affects whether the machine can be operated securely over its physical life. 126
Notification before safety-relevant firmware becomes unsupported	OWNER + MR-D	Prevents an asset owner unknowingly depending on an unmaintainable safety-security component.

Table 12: Procurement requirements classified by legal or engineering basis.

For machinery with twenty-year physical lives, the final two rows are strategic. The useful mechanical lifetime of a press, packaging line or robot cell can greatly exceed the support life of an embedded operating system, VPN appliance or industrial PC. The CRA makes security support a product-lifecycle issue; the Machinery Regulation makes obsolete digital components a safety concern whenever their vulnerabilities can compromise the protective functions on which the safety case depends. ¹²⁷

FAT/SAT and commissioning

FAT and SAT therefore need a cybersecurity extension. Traditional FAT proves that the machine performs and that its safety functions operate under designed test conditions. For connected machinery subject to Regulation (EU) 2023/1230, acceptance should also generate evidence that relevant digital attack or failure paths do not invalidate those functions.

FAT/SAT test family	Example evidence	Regulatory/engineering purpose
Identity and access	User/account list, privilege matrix, default-account test, failed-login tests, remote MFA test	Demonstrate controlled access to compliance-critical software. Annex III §1.1.9 plus IEC 62443 IAC/UC. 128
Network exposure	Port/service scan, firewall rules, machine data-flow diagram, approved OPC UA methods/tags	Demonstrate that conduits correspond to intended functionality.
Software baseline	PLC/safety-PLC program hash, firmware versions, HMI version, drive firmware, signed baseline	Supports §1.1.9 software identity and intervention evidence. 129
Safety configuration	Safety parameter export, checksum, PL/SIL validation references, access-control test	Demonstrates that cyber controls protect the same configuration validated by functional safety.
Remote maintenance	Test of default-deny state, authorisation, MFA, timeout, revocation and audit trail	Validates the highest-risk external control conduit.
Logging and traceability	Successful/failed programming-event records, user attribution, configuration-change records	Directly supports MR evidence requirements. 130
Communication failure	Disconnect/reconnect Ethernet, loss of OPC UA/MES/cloud link, malformed/stale input test where justified	Demonstrates Annex III §1.2.6 safe behaviour. 131
Unauthorised change attempt	Rejected PLC/safety parameter upload, firmware-integrity rejection, alarm/log evidence	Tests protection against intentional corruption.
Backup/restore	Restore from trusted backup followed by safety-validation check	Demonstrates recoverability to known configuration.
Update process	Authenticity validation, controlled installation, rollback/recovery and post-update verification	Links CRA lifecycle practice to preservation of the MR safety case. 132

Table 13: Cybersecurity extensions to machinery FAT/SAT and the evidence they can generate.

FAT/SAT cyber evidence should not be viewed merely as an IT appendix. Where the manufacturer relies on cybersecurity controls to satisfy an applicable Annex III requirement, those controls become part of the reasoning by which conformity is demonstrated. The corresponding evidence should therefore be traceable to the machine risk assessment, architecture, software and configuration baseline, verification activities and technical documentation. Annex IV’s ability to reach safety-related software or programming logic reinforces the point: software state and digital configuration now belong inside the machinery conformity domain when they are relevant to safety.¹³³

The practical consequence is that FAT and SAT should establish more than a momentary pass/fail result. They should establish an assurance baseline against which later maintenance, updates and modifications can be compared.

That baseline may include the validated PLC and safety-PLC applications, firmware versions, safety parameters, controller configuration, network interfaces, approved communication paths, remote-access configuration, privileged-account model, software hashes or project checksums where available, firewall rules, backup sets and the evidence generated during functional-safety and cybersecurity verification.

The key distinction is between testing the machine and establishing the state of the machine that was tested. A successful FAT has limited evidential value if the organisation cannot later determine whether the software, parameters, network exposure or access paths operating in production are still the same ones that were validated.

A useful assurance model therefore has four evidence classes:

Evidence class	Typical contents	Purpose
Design evidence	Risk assessment, safety requirements, threat analysis, architecture, zones/conduits, control-authority model, software and network specifications	Explains why the architecture should satisfy the applicable safety requirements.
Verification evidence	Functional-safety validation, cybersecurity tests, communication-loss tests, access-control tests, software-integrity checks, FAT/SAT records	Demonstrates that the implemented machine behaves as intended under the tested conditions.
Baseline evidence	PLC/safety-PLC project versions, firmware inventory, safety parameters, configuration exports, approved firewall rules, account/role matrix, backup set	Defines the known and accepted digital state of the commissioned machine.
Change evidence	Patch records, software uploads, configuration changes, approvals, vulnerability assessments, post-change testing and revalidation results	Demonstrates whether the original assurance case remains valid after commissioning.

Table 14: Evidence classes supporting lifecycle assurance for digitally dependent machinery safety.

The same reasoning must then survive commissioning. The lifecycle is not a simple sequence from design to decommissioning; it is a set of assurance gates and feedback loops in which every change must be classified according to whether it preserves the validated baseline, modifies a safety-relevant dependency, or potentially changes the machinery risk model itself.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TB

    subgraph DESIGN["Design and conformity engineering"]
        A[Hazard and risk assessment]
        B[Safety requirements<br/>and safety functions]
        C[Digital dependency<br/>and cyber threat analysis]
        D[Architecture / zones / conduits<br/>control-authority model]
        E[Implementation<br/>hardware + software + configuration]
    end

    subgraph VERIFY["Verification and acceptance"]
        F[FAT<br/>functional + cyber verification]
        G[SAT<br/>installed-system verification]
        H[Commissioning approval]
        I[Accepted digital baseline<br/>software / firmware / parameters<br/>network / access / backups]
    end

    subgraph OPERATE["Operation and maintenance"]
        J[Normal operation]
        K[Maintenance event]
        L[Security patch]
        M[Firmware / software update]
        N[Configuration or parameter change]
        O[Functional modification]
    end

    subgraph CHANGE["Change impact assessment"]
        P{Does the change affect<br/>a safety-relevant dependency?}
        Q[Controlled verification<br/>against existing baseline]
        R[Safety + cybersecurity<br/>impact assessment]
        S{Does it create a new hazard<br/>or increase an existing risk?}
        T[Revalidation of affected<br/>safety / security assumptions]
        U{"Possible substantial<br/>modification under Art. 3(16)?"}
    end

    subgraph REASSESS["Reassessment path"]
        V[Manufacturer obligations /<br/>conformity reassessment as applicable]
        W[Updated technical documentation<br/>risk assessment / verification]
        X[New accepted baseline]
    end

    subgraph EVIDENCE["Lifecycle assurance record"]
        Y[Architecture / requirements]
        Z[Test and validation records]
        AA[Software / configuration baseline]
        AB[Change / intervention evidence]
        AC[Revalidation / reassessment evidence]
    end

    A --> B --> C --> D --> E
    E --> F --> G --> H --> I
    I --> J

    J --> K
    J --> L
    J --> M
    J --> N
    J --> O

    K --> P
    L --> P
    M --> P
    N --> P
    O --> P

    P -->|No| Q
    Q --> J

    P -->|Yes| R
    R --> S

    S -->|No material safety increase| T
    T --> X
    X --> J

    S -->|New hazard / increased risk| U
    U -->|No| T
    U -->|Yes| V
    V --> W --> X

    D -. evidence .-> Y
    F -. evidence .-> Z
    G -. evidence .-> Z
    I -. baseline .-> AA
    K -. intervention .-> AB
    L -. intervention .-> AB
    M -. intervention .-> AB
    N -. intervention .-> AB
    O -. intervention .-> AB
    T -. validation .-> AC
    W -. reassessment .-> AC

Figure 4: Lifecycle assurance model for connected machinery, linking design, verification, commissioned baselines, operational changes and substantial-modification assessment.

The central object in this model is the accepted digital baseline created at commissioning. It represents the software and configuration state for which the safety and cybersecurity assumptions were actually validated. From that point onward, operational change management is not merely an ITSM process; it becomes part of preserving the machine’s conformity rationale whenever the changed element participates in a safety function or in the protection of that function.

A useful way to think about the lifecycle is therefore:

validated architecture → verified implementation → accepted baseline → controlled change → impact assessment → revalidation where necessary → updated baseline

rather than:

FAT passed → machine commissioned → maintenance proceeds independently.

This distinction is particularly important for software and configuration changes because the physical machine may appear unchanged while its behaviour, attack surface or safety assumptions have materially changed.

A security patch, for example, may leave the safety envelope completely unchanged and merely restore the integrity of a component. A firmware upgrade may change communications, diagnostics or controller behaviour while leaving the intended safety function intact. A PLC parameter change may alter production performance without affecting risk reduction. Conversely, a seemingly minor modification to a safety limit, interlock mapping, operating mode, communication path or remote-access capability may change an assumption on which the original risk assessment relied.

The lifecycle process should therefore classify changes according to their effect on the assurance case, not according to their apparent size. A one-line change to PLC logic can be more consequential than replacement of an entire HMI. A firmware update affecting only diagnostics may be less significant than opening a previously unavailable remote programming path. The relevant question is whether the change alters a digital dependency that participates in preventing hazardous behaviour.

This is also where cybersecurity vulnerability management and machinery change management converge. A vulnerability may require a patch; the patch changes software; the changed software may participate in a safety-related function; and the organisation must then determine how much verification is required before the machine can return to service.

That does not mean that every security update requires a new conformity assessment. It means that the change process should answer a sequence of progressively stronger questions:

Did the change alter the validated digital baseline?

If not, ordinary maintenance evidence may be sufficient.

Does the changed element participate in, protect, communicate with or influence a safety-relevant function?

If yes, the safety and cybersecurity assumptions associated with that dependency should be reviewed.

Does the change modify the machine’s hazardous behaviour, safety limits, protective functions, control authority or risk-reduction measures?

If yes, revalidation of the affected safety case becomes necessary.

Does the modification meet the complete legal test for substantial modification under Article 3(16)?

Only at that stage does the specific regulatory consequence associated with substantial modification have to be considered.

This layered logic prevents two opposite errors. The first is under-classification: treating every software change as routine IT maintenance even when it changes the machine’s safety behaviour. The second is over-classification: treating every cybersecurity patch or firmware update as though it automatically created a new machine requiring full conformity reassessment.

The correct unit of analysis is the safety-relevant delta between the previously accepted baseline and the proposed state. That delta should be supported by evidence. Depending on the change, the evidence may include a software-version comparison, configuration diff, firmware release assessment, modified network-flow matrix, updated threat model, safety-parameter comparison, regression test, functional-safety validation, remote-access test or restored baseline hash. The purpose is not to create documentation for its own sake; it is to demonstrate that the assumptions used to justify safe operation remain true after the intervention.

This makes configuration management a central part of cyber-physical safety. In a conventional IT environment, configuration management primarily supports service reliability and recovery. In machinery, the same mechanism can also preserve evidence that the logic and parameters enforcing a physical safety constraint are still the ones that were validated.

For the same reason, backup and restore should be understood as more than availability controls. Restoring an old PLC project, safety configuration or controller image can itself create a hazardous state if the restored baseline is incompatible with subsequent mechanical, electrical or software changes. A known-good backup therefore means not only malware-free or technically recoverable, but known to correspond to a valid machine configuration.

The assurance record should consequently follow the machine throughout its useful life. It should connect design intent, verification evidence, commissioned baseline, interventions and subsequent revalidation sufficiently well that a competent person can reconstruct the state of the machine and understand why it was considered safe at a particular point in time.

This is the deeper lifecycle implication of the Machinery Regulation’s treatment of software, intervention evidence and digital modification: conformity is established at a point in time, but the assumptions on which conformity depends can subsequently be changed by software and configuration. Cyber-physical safety therefore requires a mechanism for detecting, assessing and evidencing those changes throughout the operational lifecycle.

Updates and substantial modification after commissioning

The difficult point is the boundary between maintenance and a legally substantial modification. A usable decision logic is:

Was the change foreseen or planned by the original manufacturer?

If yes, that weighs strongly against Article 3(16), although implementation still has to preserve conformity.

Does the change create a new hazard or increase an existing risk?

If no, the substantial-modification definition is not satisfied merely because code changed.

If safety is affected, does the modification meet the remaining Article 3(16) threshold concerning required guards/protective devices and safety-control modification, or additional protective measures for stability/mechanical strength?

Only if the complete definition is met should Article 18’s modifier becomes manufacturer consequence be triggered. ¹³⁴ This is why a critical CVE patch and a new production mode should not be processed identically. A validated security patch can preserve the manufacturer’s original safety envelope. A small PLC change that defeats an interlock can transform the risk model even if the binary file changes by only a few bytes.

Nor does the existing CE marking answer the question. CE marking describes conformity of the product placed on the market under its applicable assessment; it is not an immutable property of every future configuration. If a later modification satisfies Article 3(16), the person making it assumes manufacturer obligations under Article 18 for the affected machinery/product and the conformity question reopens accordingly. ¹³⁵

Case study, critical questions and the boundary of cyber-physical safety

Conventional architecture and attack paths

Consider a robotic palletising/packaging cell containing a standard PLC, safety PLC, HMI, Ethernet-connected variable-frequency drives, robot controller, safe I/O and guard interlocks. The machine exchanges production data with SCADA/MES through OPC UA. The OEM maintains it remotely through an Internet-connected gateway, and an industrial edge computer sends telemetry to a cloud predictive-maintenance service.

A conventional architecture might place the HMI, PLC, robot, drives, safety controller and remote gateway on a largely flat machine network. The vendor tunnel is permanently available, PLC programming is possible from an engineering laptop or HMI, MES can write recipes, and the cloud edge has broad access because that was operationally convenient.

The machine can still achieve a calculated PL or SIL when tested against random hardware failures. But the architecture has introduced new common-cause paths that the PL/SIL number does not represent.

Representative cyber-physical attack paths

The distinction between a cybersecurity incident and a machinery-safety event becomes clearer when representative attacks are decomposed along the same causal dimensions.

Attack path	Entry path	Compromised asset or authority	Control-system effect	Safety consequence	Machinery Regulation path	Architectural lesson
A — Remote maintenance compromise	Stolen vendor credentials are used through the remote-maintenance infrastructure and engineering path.	Vendor identity plus privileged engineering authority over the PLC.	The attacker uploads modified PLC logic and changes a validated mode transition, removing a condition such as the requirement for local reset.	Unexpected start or hazardous robot motion becomes possible.	Annex III §1.1.9: intentional modification of software through a connected path can affect safe behaviour. §1.2.1: a reasonably foreseeable malicious third-party action can cause a hazardous situation.136	Credential security alone is insufficient. The remote conduit must bound destination, protocol, privilege, duration and engineering authority. Successful remote authentication should not automatically imply unrestricted PLC programming.
B — Safety-parameter manipulation	An engineering workstation or legitimate safety-engineering session is compromised.	Safety-PLC configuration authority and the validated safety-parameter baseline.	The attacker changes a safety parameter—for example, increasing the permissible speed in reduced-speed maintenance mode. The safety PLC continues to enforce the configured value correctly.	The machine operates outside the risk-reduction assumptions even though the safety controller has not failed in the conventional random-failure sense.	Annex III §1.1.9: safety-relevant configuration/software integrity is compromised. §1.2.1: validated safety-function limits can be maliciously altered, creating a hazardous situation.137	Safety parameters are part of the safety assurance baseline. They require integrity protection, controlled engineering access, attributable change records and appropriate post-change validation.
C — Cloud-to-control authority	A cloud credential, cloud application or connected industrial-edge device is compromised.	External-service identity and the controller-write authority delegated to the cloud/edge integration.	An analytical or optimisation service modifies recipe values, motion parameters, controller tags or other externally writable inputs.	The machine may exceed validated limits, enter an unsafe operating state or execute an unsafe sequence if local controls do not constrain the externally supplied values.	Annex III §1.1.9: relevant where an external connection can corrupt safety-relevant software, data, configuration or commands. §1.2.1: relevant where malicious external influence can generate hazardous behaviour. §1.2.6: additionally relevant where communication loss, restoration or instability can itself create a hazard.	The mistake is not cloud connectivity but cloud-derived control authority. Observation, optimisation and command should be separated; external values should be locally constrained where necessary, and cloud compromise should not bypass the validated control/safety envelope.

Table 15: Representative attack paths showing how a cybersecurity compromise can propagate through control authority into machinery-safety consequences.

The three scenarios expose different failure mechanisms even though all ultimately cross the same cyber-physical boundary:

• In remote-maintenance compromise, the attacker captures an existing privileged path. The principal architectural question is therefore how far authenticated remote identity is allowed to propagate into engineering authority.
• In safety-parameter manipulation, the attacker does not need to make the safety controller malfunction. The more subtle failure is that the controller continues to execute correctly against a corrupted definition of what safe means. This is why configuration integrity and safety-parameter provenance are as important as controller reliability.
• In cloud-to-control compromise, the critical design decision is the delegation of authority to an external service. A cloud analytics function can be well isolated from the safety system at the network level yet still become safety-relevant if its outputs are accepted as unconstrained control inputs.

The common pattern is therefore:

entry path → compromised authority or trusted state → altered control semantics → invalidated safety assumption → hazardous physical behaviour

The architecture should be designed to break this chain as early as possible, preferably by preventing compromise of a less-trusted domain from automatically acquiring the authority required to alter a safety-relevant state.

Applying the authority architecture to the case study

The redesign should now be read as an application of the architectural principles developed above rather than as another generic segmentation model. The objective is to break the causal paths identified in the three attack scenarios:

remote identity compromise must not automatically become PLC engineering authority; safety-parameter access must not automatically permit unvalidated modification of the safety baseline; and compromise of an analytical or cloud service must not automatically become machine-control authority.

The resulting architecture therefore separates connectivity, identity, operational authority, engineering authority and safety authority and introduces control points at the transitions between them.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD

    subgraph EXT["External / plant services"]
        OEM[OEM Service<br/>named engineer]
        PLANT[Plant SCADA / MES]
        CLOUD[Cloud Analytics]
        IAM[Identity / PAM / approval]
    end

    subgraph ACCESS["Access mediation"]
        RAG[Remote Access Gateway<br/>default deny / time bounded]
        JH[Jump Host / Session Broker]
        FW[OT Firewall]
    end

    subgraph EDGE["Machine integration boundary"]
        DMZ[Machine DMZ / Edge<br/>OPC UA broker / historian<br/>update staging / telemetry]
    end

    subgraph ENG["Engineering authority"]
        HMI[HMI / Engineering Workstation]
        ENGCTRL[Engineering approval<br/>target + task + privilege]
    end

    subgraph CONTROL["Machine control authority"]
        PLC[PLC / Robot / CNC]
        DRIVE[Drives / Motion Control]
    end

    subgraph SAFETY["Safety authority"]
        SGATE[Safety-change gate<br/>separate approval]
        LOCAL[Local enable / maintenance mode<br/>where required]
        SPLC[Safety PLC / Safe I/O]
        SAFE[Safe motion / interlocks<br/>protective functions]
    end

    subgraph ASSURE["Assurance and evidence"]
        LOG[Central logs / session evidence]
        BASE[Approved software and<br/>configuration baseline]
        CHANGE[Change record / validation<br/>baseline reconciliation]
    end

    OEM -->|individual identity + MFA| RAG
    IAM -->|authorisation context| RAG
    RAG -->|temporary conduit| JH
    JH -->|restricted destination / protocol| HMI

    PLANT -->|approved OT flows| FW
    FW --> DMZ

    DMZ -->|operational data / mediated services| HMI
    DMZ -->|read / bounded operational data| PLC

    PLC -->|status / telemetry| DMZ
    DMZ -->|outbound telemetry| CLOUD

    HMI --> ENGCTRL
    ENGCTRL -->|approved engineering session| PLC
    PLC --> DRIVE

    ENGCTRL -->|safety-relevant change request| SGATE
    SGATE --> LOCAL
    LOCAL -->|authorised safety engineering| SPLC

    PLC <-->|bounded functional interface| SPLC
    SPLC --> SAFE
    SAFE -. constrains physical behaviour .-> DRIVE

    HMI -. session / change evidence .-> LOG
    PLC -. events / configuration evidence .-> LOG
    SPLC -. safety-change evidence .-> LOG

    BASE -. approved state .-> HMI
    BASE -. approved state .-> PLC
    BASE -. approved state .-> SPLC

    LOG --> CHANGE
    CHANGE -->|reconcile / revalidate| BASE

    X1[No direct OEM path<br/>to PLC or safety PLC]
    X2[No direct cloud<br/>write authority]
    X3[No ordinary engineering session<br/>automatically grants safety authority]

    X1 -. architectural invariant .-> PLC
    X2 -. architectural invariant .-> PLC
    X3 -. architectural invariant .-> SPLC

Figure 5: Case-study authority architecture showing how remote service, plant integration and cloud analytics are prevented from automatically acquiring engineering or safety authority.

The significant change is not the addition of another firewall. It is the introduction of authority boundaries.

The OEM path terminates first in a plant-controlled access layer. Authentication establishes the identity of the remote engineer, but does not itself create engineering authority. A temporary session must then be authorised, restricted to the required destination and protocol, and passed through the engineering environment. Only after a separate engineering decision does the session acquire the ability to modify machine control.

Safety authority is separated again. An engineer who can modify ordinary PLC logic does not thereby acquire the right to alter safety logic, safe-motion parameters or protective-function configuration. A safety-relevant change crosses an additional control point and, where justified by the risk assessment, can require a local enabling condition before the safety controller becomes writable.

This is the architectural answer to attack path A. Theft of an OEM credential no longer produces a continuous causal chain:

compromised vendor identity → network access → engineering workstation → arbitrary PLC programming

Instead, several independent conditions must hold:

authenticated identity → plant approval → temporary conduit → authorised target → authorised engineering privilege → permitted change

Compromise of one layer therefore does not automatically confer all downstream authority.

The treatment of the safety zone addresses attack path B differently. The problem in that scenario was not arbitrary network reachability but corruption of the value that defined the validated safety envelope. The redesigned architecture therefore treats the safety configuration itself as a controlled baseline. Access to it is distinct from ordinary control-system administration, changes are attributable, and the resulting configuration must be reconciled against the approved baseline and revalidated where necessary.

The relevant security objective is therefore stronger than prevent unauthorised access. It is:

prevent an unauthorised or insufficiently controlled change from silently redefining what the machine considers safe.

This is also why the assurance plane appears explicitly in the architecture. Logs alone cannot establish that the machine remains in the validated state. The design links session evidence to software and configuration baselines, change records and subsequent validation. After safety-relevant maintenance, the relevant question is not merely whether the authorised engineer disconnected successfully, but whether the resulting machine state still corresponds to an accepted safety configuration.

The architecture addresses attack path C through a different invariant: analytics does not imply actuation authority. Cloud analytics receives telemetry through the machine integration layer, but no direct cloud-to-PLC programming or arbitrary tag-write path exists. If a legitimate business requirement later requires optimisation commands or externally generated setpoints, that function should be introduced as a separate, explicitly modelled conduit rather than by converting the telemetry channel into bidirectional general-purpose control.

Where external values are accepted, the machine-side architecture can constrain them according to their semantics: permitted variables, admissible ranges, rate limits, operating modes, state-dependent validity and other conditions derived from the control and safety design. The external service can then request a value without automatically possessing unrestricted authority over the physical process.

The three attack paths can therefore be mapped directly to the architectural controls:

Attack path	Original authority failure	Architectural break introduced by the redesign	Residual safety mechanism
A — Remote maintenance	Compromised vendor identity inherits end-to-end PLC engineering authority.	Plant-controlled approval, temporary remote conduit, jump/session mediation, destination restriction and explicit engineering-authority grant.	Machine logic and safety functions still constrain physical behaviour; privileged changes remain attributable.
B — Safety-parameter manipulation	Ordinary engineering compromise reaches the validated safety configuration.	Separate safety authority, safety-change gate, potentially local enabling, controlled safety baseline and post-change reconciliation.	Safety modification is subject to revalidation rather than silently becoming the new trusted state.
C — Cloud-to-control authority	An analytical or edge service possesses controller-write capability beyond its functional need.	Telemetry and control conduits are separated; cloud analytics is outbound/read-oriented by default and any required command interface is independently constrained.	Local control and safety functions enforce the admissible physical operating envelope.

Table 16: Relationship between the case-study attack paths and the authority boundaries introduced by the redesigned architecture.

This architecture still does not make the firewall, jump host, MFA mechanism or segmentation scheme into safety functions. Functional safety remains engineered and validated through the applicable machinery and functional-safety methods, including ISO 13849 or IEC 62061 where relevant. The cybersecurity architecture instead protects the digital assumptions on which those safety functions depend: the integrity of their logic and parameters, the legitimacy of control authority, the trustworthiness of communications and the traceability of intervention.¹³⁸

The same distinction applies to communications failure. The architecture can reduce the probability and scope of malicious communication events, but §1.2.6 additionally requires the machine itself to avoid hazardous behaviour when a communication connection fails. Loss of a cloud link, OPC UA session, plant supervisory connection or remote-maintenance tunnel should therefore lead to an explicitly defined machine behaviour rather than leaving the physical consequence to incidental protocol or application behaviour.¹³⁹

The redesigned case can consequently be expressed through three architectural invariants:

external identity does not equal machine authority; machine engineering authority does not equal safety authority; external data connectivity does not equal control authority.

Those invariants are derived engineering principles rather than literal text from Annex III. Their purpose is to make the Regulation’s required safety outcomes structurally defensible: compromise of a lower-trust digital service should not, by architectural default, be sufficient to invalidate the machine’s safety case.

Critical questions

The principal questions can now be answered directly.

Question	Evidence-based answer
Does Regulation 2023/1230 impose cybersecurity requirements?	Yes. Annex III §1.1.9 expressly requires protection against intentional corruption, and §1.2.1 expressly addresses reasonably foreseeable malicious attempts by third parties leading to hazardous situations. The Commission itself describes the Regulation as integrating cyber-safety provisions. 140
Which cybersecurity requirements are explicit?	Protection of compliance-critical hardware/software/data against intentional corruption; safety-relevant software identification; intervention/modification evidence; resistance of control systems to relevant foreseeable malicious attempts; safety-function limits; safety-software/change traceability; and safe behaviour under network-connection failure are explicit. 141
Which controls are indirect engineering consequences?	MFA, firewalls, zones/conduits, jump hosts, signed firmware, secure boot, allowlisting, IDS, session recording and particular RBAC models are not named by MR. They can be justified as engineering means to meet its objectives. 142
Is IEC 62443 mandatory?	No. It is a highly relevant engineering framework, not a statutory requirement of the Machinery Regulation. As of 3 October 2026, the first Machinery Regulation harmonised-standard list is still pending. 143
Can a cyber vulnerability make a functionally safe machine non-compliant?	Yes, conditionally. If the vulnerability means compliance-critical assets are inadequately protected or a reasonably foreseeable malicious path can lead to a hazardous situation, satisfying a PL/SIL target does not cure the Annex III non-conformity. Not every vulnerability has that safety consequence. 144
Can a software update constitute a substantial modification?	Yes. Article 3(16) explicitly includes digital modifications, but the full statutory test must be satisfied; a software update is not automatically substantial. 145
Who is responsible when an integrator substantially modifies machine software?	Article 18 can treat the natural/legal person carrying out the substantial modification as the manufacturer for the purposes of the Regulation. 146
How should manufacturers treat remote vendor access?	As a communication/control path within the machinery threat and risk model. Where it can influence hazardous behaviour, its authentication, authorisation, scope, duration, monitoring and ability to reach safety-critical assets require justification. The exact technical solution is not prescribed. 147
Does an original CE marking automatically remain sufficient after significant software modification?	No general safe-harbour exists merely because the machine was once CE marked. Apply the Article 3(16) test. A substantial modification invokes Article 18 manufacturer obligations; a non-substantial update still has to preserve conformity. 148
Must intentional cyber manipulation enter the machinery risk assessment?	Where a malicious manipulation is reasonably foreseeable and can lead to a hazardous situation, §1.2.1 makes the answer effectively yes for that safety pathway. The risk analysis should connect the threat to the hazardous machine state rather than conduct an unrelated enterprise-IT assessment. 149
How do CRA and Machinery Regulation interact?	CRA supplies horizontal product-cybersecurity lifecycle duties; MR addresses machinery health-and-safety consequences. The same weakness can violate both when exploitation creates unsafe physical behaviour, but compliance with one should not be assumed automatically to discharge the other except where EU law creates a specific presumption/equivalence mechanism. 150
What changes for manufacturers on 20 January 2027?	Machinery newly placed on the EU market moves to the Regulation’s regime: new definitions and economic-operator framework, Annex I conformity-assessment architecture, explicit substantial-modification rules, digital-documentation provisions, and the new software, corruption, malicious-attempt, network and self-evolving-system EHSRs become operative. 151

Table 17: Critical questions and evidence-based answers concerning the Machinery Regulation’s digital and cyber-physical implications.

From machine safety to cyber-physical safety

The argument developed through the preceding sections can now be stated more precisely. Regulation (EU) 2023/1230 does not transform machinery legislation into a general OT cybersecurity regime, and it does not make every vulnerability in a connected machine a CE-conformity issue. Its significance is narrower, but technically more important: it brings digital integrity, malicious interference, communication dependencies and software modification inside the machinery-safety problem whenever they can affect the conditions under which physical risk is controlled.

That is the substantive shift from conventional machine safety toward cyber-physical safety. The Regulation now expressly addresses protection against intentional and accidental corruption of safety-relevant hardware, software and data; requires relevant control systems to withstand malicious third-party attempts capable of creating hazardous situations; requires intervention and modification of safety-related software or configuration to be traceable; addresses hazardous consequences of communication-network failure; and extends the machinery framework to software, digital safety components, digitally implemented modifications and certain self-evolving behaviour.¹⁵²

The consequences can be summarised as follows.

Layer	What changes under the cyber-physical interpretation
Legal requirement	Applicable Annex III EHSRs concern not only mechanical and electrical failure, but also corruption, malicious influence, software/configuration integrity and communication-dependent hazardous behaviour.
Risk assessment	The manufacturer must consider whether digital compromise can invalidate a risk-reduction measure or create a hazardous machine state.
Functional safety	PL/SIL reasoning remains necessary where applicable, but it is not by itself sufficient to demonstrate that a safety function remains trustworthy when its logic, parameters, dependencies or control authority can be intentionally manipulated.
Cybersecurity engineering	Threat modelling, privilege architecture, integrity protection, segmentation, remote-access controls and secure change management become relevant where they protect assumptions necessary for machinery safety.
Architecture	Connectivity, identity, operational authority, engineering authority and safety authority should be treated as distinct design concepts.
Verification	FAT/SAT and validation should test not only nominal safety behaviour but also the digital conditions on which that behaviour depends.
Lifecycle	Software, firmware, configuration and access-path changes must be assessed against the accepted machine baseline and revalidated where they affect safety-relevant assumptions.
Evidence	The conformity rationale increasingly depends on traceable architecture, software/configuration state, interventions, tests and subsequent changes.

Table 18: The principal consequences of treating digitally mediated hazards as part of the machinery-safety problem.

The decisive conceptual change is therefore not that cybersecurity has become another safety function. It is that cybersecurity can protect the assumptions on which safety functions depend.

A safety PLC may achieve its required PL or SIL and still participate in an unsafe system if an attacker can remotely replace its program. A safe-speed function may execute perfectly while enforcing a maliciously altered speed limit. A robot controller may behave exactly according to its software while that software has been changed through a compromised engineering workstation. A machine may contain independently validated safety components while a remote-maintenance path gives an external identity sufficient authority to alter the state those components were designed to protect.

In all of these cases, the relevant failure is not necessarily failure of the safety mechanism in the traditional sense. It is failure of an assumption surrounding that mechanism.

Those assumptions include:

• that the safety logic being executed is the logic that was validated;
• that safety parameters remain within their approved values;
• that only authorised actors can modify the configuration;
• that external services cannot silently acquire unintended control authority;
• that communication loss produces a defined non-hazardous response;
• that software and firmware changes are known and assessed;
• that the machine operating in production still corresponds sufficiently closely to the state for which the safety case was established.

Cyber-physical safety therefore requires the safety case to include not only the function itself, but also the digital dependencies and trust relationships necessary for that function to remain valid.

From safety function to assurance chain

The resulting assurance model is broader than a conventional sequence of hazard analysis followed by functional-safety validation. A modern connected machine requires a chain in which safety analysis and cybersecurity analysis meet at the level of the digital dependencies of physical risk reduction.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TB

    subgraph SAFETY["Machinery safety case"]
        A[Hazards and hazardous situations]
        B[Risk assessment]
        C[Required risk reduction]
        D[Safety functions<br/>PL / SIL where applicable]
        E[Validated operating<br/>and safety assumptions]
    end

    subgraph DEP["Digital safety dependencies"]
        F[Software / firmware]
        G[Configuration / safety parameters]
        H[Communications / external data]
        I[Identity / privilege]
        J[Control and engineering authority]
    end

    subgraph CYBER["Cybersecurity reasoning"]
        K[Threat model]
        L[Attack paths and abuse cases]
        M[Security requirements]
        N[Zones / conduits / trust boundaries]
        O[Authority architecture<br/>observe / operate / configure / engineer]
    end

    subgraph VERIFY["Integrated verification"]
        P[Functional-safety validation]
        Q[Cybersecurity verification]
        R[Remote-access / communication<br/>failure tests]
        S[Software / configuration<br/>integrity checks]
    end

    subgraph ASSURE["Conformity and accepted state"]
        T[Accepted digital baseline]
        U[Technical documentation]
        V[FAT / SAT / validation evidence]
        W[Conformity rationale]
    end

    subgraph LIFE["Operational lifecycle"]
        X[Operation]
        Y[Maintenance / patch / update]
        Z[Configuration / functional change]
        AA{Safety-relevant<br/>delta?}
        AB[Impact assessment<br/>and revalidation]
        AC{Possible substantial<br/>modification?}
        AD[Conformity reassessment<br/>where applicable]
    end

    A --> B --> C --> D --> E

    D --> F
    D --> G
    E --> H
    E --> I
    E --> J

    F --> K
    G --> K
    H --> K
    I --> K
    J --> K

    K --> L --> M
    M --> N --> O

    D --> P
    O --> Q
    O --> R
    F --> S
    G --> S

    P --> T
    Q --> T
    R --> T
    S --> T

    T --> U
    T --> V
    U --> W
    V --> W

    W --> X
    X --> Y
    X --> Z

    Y --> AA
    Z --> AA

    AA -->|No| X
    AA -->|Yes| AB
    AB --> AC

    AC -->|No| T
    AC -->|Yes| AD
    AD --> B

Figure 6: Integrated cyber-physical assurance model connecting machinery hazards, safety functions, digital dependencies, threat modelling, authority architecture, verification, conformity evidence and lifecycle change.

This model contains several important dependencies:

1. Hazard → safety function → digital dependency. A cybersecurity requirement should not appear merely because a machine contains Ethernet, Windows or a cloud connection. It should be possible to explain which safety assumption depends on the protected digital asset or authority.
2. Digital dependency → threat → architectural requirement. Once a safety-relevant dependency is identified, the analysis asks how it can be corrupted, replaced, misused or made unavailable. That analysis can then justify requirements such as protected engineering access, separation of authority, configuration integrity, bounded communication paths or local validation of externally supplied values.
3. Architecture → verification → baseline. Security controls do not become credible merely because they appear in a network drawing or cybersecurity specification. Their implementation must be verified, and the resulting machine state must be sufficiently captured to establish what was actually validated.
4. Baseline → change → reassessment. Cyber-physical assurance does not end at commissioning because the digital part of the machine remains mutable. Patches, firmware changes, remote-maintenance activities, parameter changes and functional modifications can alter the assumptions incorporated into the original safety case.

That feedback loop is one of the most important consequences of software becoming part of machinery conformity.

The boundary between cybersecurity and machinery safety

The resulting boundary can be expressed causally. A vulnerability becomes relevant to machinery safety when exploitation can plausibly create a chain such as:

digital compromise → corrupted safety-relevant dependency → altered control semantics or authority → invalidated risk-reduction assumption → hazardous machine state

The chain may be short. A compromised safety-engineering workstation may directly alter a safe-speed parameter.

It may also be long. Compromise of a cloud identity may allow modification of an edge application, which changes a controller setpoint, which alters motion, which defeats an assumption about the separation distance protecting an operator. What matters is not the number of layers but the existence of a credible path to physical hazard.

The converse is equally important. A cybersecurity weakness that cannot affect safety-relevant behaviour does not automatically become a Machinery Regulation non-conformity. Leakage of production data, theft of commercial information or compromise of a non-safety analytics environment may be serious cybersecurity incidents while remaining primarily within the domain of the CRA, NIS2, contractual obligations or the operator’s broader cybersecurity programme.

This distinction prevents two analytical errors:

not every cybersecurity problem is a machinery-safety problem; not every machinery-safety problem can still be analysed without cybersecurity.

Functional safety remains necessary, but its assumptions must now be defended

This does not displace ISO 13849, IEC 62061 or established functional-safety engineering. Those disciplines remain central to determining the required performance and reliability of safety functions.

What changes is the boundary of the assurance problem.

Traditional functional-safety reasoning is highly developed for random hardware failure and systematic faults arising from specification, design, implementation and lifecycle processes. The Machinery Regulation’s explicit treatment of malicious influence forces another question:

What if the safety function remains technically operational but the digital state on which it relies has been intentionally changed?

The answer cannot be expressed exclusively through failure probability.

A malicious actor may not need the safety function to fail. It may be sufficient to:

• redefine its permitted limit;
• alter the state from which it derives its decision;
• change its software;
• change the mode in which it operates;
• manipulate the command source it trusts;
• prevent an intervention from being detected;
• introduce a new route through which control authority can be exercised.

This is why integrity, provenance, authority and traceability emerge as central concepts.

IEC TS 63074 and the IEC 62443 series provide useful engineering bridges for analysing these dependencies, while EN 50742 is being developed specifically to translate the Machinery Regulation’s protection-against-corruption requirements into machinery-oriented technical requirements.¹⁵³

But none of these standards changes the fundamental allocation of responsibility. The manufacturer still has to connect the applicable EHSR to the hazard, the design decision, the implemented control and the evidence demonstrating that the required safety outcome has been achieved.

Compliance is therefore not established by writing:

IEC 62443 applied.

Nor by writing:

MFA enabled.

Nor:

safety PLC certified.

The relevant conformity argument is closer to:

this hazardous situation requires this safety property; this property depends on these digital states and authorities; these threats can invalidate those dependencies; these architectural and security controls constrain those threats; these tests demonstrate the controls and safety behaviour; this baseline records the state that was validated; this lifecycle process preserves or reassesses that state when it changes.

That is an assurance argument rather than a checklist.

Authority becomes part of the safety architecture

A recurring result throughout this analysis has been that authority is more important than connectivity alone:

• A network connection becomes dangerous when it carries authority capable of affecting physical behaviour.
• A remote identity becomes safety-relevant when authentication allows engineering access.
• A cloud service becomes safety-relevant when its outputs can directly alter machine state.
• An HMI becomes more than a display when its authenticated session can modify parameters.
• An engineering workstation becomes part of the safety perimeter when compromise of that workstation can redefine protective logic.

The resulting architectural rule is therefore:

Connectivity should be treated as transport; authority should be treated as a safety-relevant capability.

That is why observation, operation, configuration and engineering should be distinguished architecturally. It is also why ordinary engineering authority should not automatically imply safety-engineering authority, and why an external analytical service should not inherit arbitrary control authority simply because bidirectional connectivity is technically convenient.

This authority model is not written literally into Annex III. It is an engineering derivation from the requirement that corruption, external malicious influence and communication dependencies must not produce hazardous situations.

Conformity becomes partly a state-management problem

Software also changes the temporal nature of conformity.

For a predominantly mechanical product, many safety-relevant properties remain stable unless the physical machine is modified. Connected programmable machinery can change substantially without a wrench being used.

Its effective behaviour can be changed by:

• PLC code;
• robot programs;
• firmware;
• safety parameters;
• recipes;
• certificates and trust relationships;
• user roles;
• firewall rules;
• remote-access configuration;
• cloud or edge integrations;
• updates to external software dependencies.

Consequently, part of the machinery assurance problem becomes a state-management problem.

The organisation needs to know what state was validated, what subsequently changed, whether the delta affects a safety-relevant assumption, and whether revalidation or potentially a substantial-modification assessment follows.

This is why the software/configuration baseline developed during FAT, SAT and commissioning is not administrative overhead. It is the reference against which future interventions can be understood.

The same principle explains why backups, logging, configuration management, software inventories and change evidence acquire machinery-safety significance in some architectures. They may originate as ordinary cybersecurity or IT/OT management controls, but they become part of the conformity argument when they are necessary to establish or preserve the integrity of a safety-relevant state.

The resulting engineering model

The most defensible organisational model is therefore not:

Safety does CE. Cybersecurity secures the network. OT operates the machine. The vendor maintains it remotely.

That decomposition assigns responsibility according to organisational boundaries while the hazard crosses all of them. The stronger model is a common cyber-physical assurance process in which machinery safety, controls engineering, OT architecture, cybersecurity, software engineering, commissioning and lifecycle maintenance share one causal model.

The disciplines remain distinct. Their questions are different:

• machinery safety asks what physical harm must be prevented;
• functional safety asks what protective behaviour and reliability are required;
• controls engineering asks how machine behaviour is implemented;
• cybersecurity asks how digital assumptions and authority can be maliciously invalidated;
• architecture asks where trust and authority boundaries must exist;
• verification asks whether the implemented system satisfies those assumptions;
• configuration management asks whether that validated state is still the state that exists.

What Regulation 2023/1230 changes is that those questions can no longer always be answered independently.

The final proposition is therefore stronger than saying that machinery now needs cybersecurity.

Modern machinery safety increasingly depends on the integrity of a cyber-physical control system.

Once software, communications, remote services and external computation can influence motion, force, speed, sequencing, protective logic or the authority to command them, protecting those digital dependencies becomes one of the conditions under which the machine remains physically safe.¹⁵⁴

That does not erase the boundary between safety and cybersecurity. It defines where the boundary now lies.

See also cybersecurity longforms

Operational Technology in the Crosshairs: What the 2025–2026 Attacks Reveal About Industrial Cyber Risk

From exposed PLCs and composable trust failures to an IEC 62443-aligned architecture for constraining operational authority, bounding compromise, preserving safe operation, and restoring trusted control

VEX Standards from First Principles

From software inventories and SBOM evidence to defensible, product-specific vulnerability-exploitability decisions, interoperable VEX exchange, lifecycle governance, and Cyber Resilience Act compliance across CISA, CSAF, CycloneDX, SPDX, and OpenVEX

The December 2025 Cyberattack on Poland’s Energy Sector

A detailed reconstruction of the incident, the malware, and the wider significance for energy and OT security

See also enterprise risk management longforms

Operational Technology in the Crosshairs: What the 2025–2026 Attacks Reveal About Industrial Cyber Risk

From exposed PLCs and composable trust failures to an IEC 62443-aligned architecture for constraining operational authority, bounding compromise, preserving safe operation, and restoring trusted control

Measuring Cyber Risk in the Italian Corporate Sector

A Banca d’Italia indicator of cybersecurity vulnerability designed to support creditworthiness evaluation

When Digital Trust Expires: Quantum Computing and the Collapse of Signature-Based Security

How quantum attacks turn long-lived signatures into silent integrity and impersonation risks

See also regulation and compliance longforms

Operational Technology in the Crosshairs: What the 2025–2026 Attacks Reveal About Industrial Cyber Risk

From exposed PLCs and composable trust failures to an IEC 62443-aligned architecture for constraining operational authority, bounding compromise, preserving safe operation, and restoring trusted control

VEX Standards from First Principles

From software inventories and SBOM evidence to defensible, product-specific vulnerability-exploitability decisions, interoperable VEX exchange, lifecycle governance, and Cyber Resilience Act compliance across CISA, CSAF, CycloneDX, SPDX, and OpenVEX

Cyber Resilience Act: The New Product-Security Baseline

Scope, legal roles, secure design, conformity, reporting, and lifecycle assurance across the digital-product supply chain

See also posts

Photovoltaic Cybersecurity Is an Authority-Architecture Problem

What the 2026 NTC findings imply for procurement, IEC 62443 design, hardening, and commissioning

When the User Becomes the Exploit

TerminalFix, WeWorm, and why security must survive the failure of its first boundary

Data Is Not the New Oil

What Google's bid for Spirit Airlines' corporate archive reveals about enterprise data in the AI era

Guerra profonda: recensione tecnica e guida all'approfondimento

Sovranità digitale, guerra algoritmica, AI e conflittualità ibrida nel libro di Arturo Di Corinto

Programming Authority Is the Real PLC Security Boundary

Why network reachability, authentication, and controller programming must be treated as separate security states.

A CVE Is Not an Article 14 Report: What Actually Makes a Vulnerability Reportable?

How to distinguish identifiers, severity scores, exploitation signals, product evidence, and the CRA reporting threshold

Footnotes

1. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

2. Essential health and safety requirements (EHSRs) are the mandatory health-and-safety requirements applicable to the design and construction of machinery and related products under Regulation (EU) 2023/1230. They are set out in Annex III. Under Directive 2006/42/EC, the corresponding requirements were contained in Annex I. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023. Official text.

3. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website.

4. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

5. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website. New legislative framework. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Overview of the EU New Legislative Framework and product-legislation alignment, including Regulation (EU) 2023/1230. Official website.

6. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Commission overview of Regulation (EU) 2023/1230, including its New Legislative Framework alignment, conformity model, digital documentation, cyber-safety provisions and transition from Directive 2006/42/EC. Official website.

7. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

8. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

9. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

10. Regulation (EU) 2023/1230 on machinery, Article 8 and Annex III. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023. Official text.

11. Regulation (EU) 2023/1230 on machinery, Annex III, Part B — General principles. The general principles require a risk assessment to determine the EHSRs applicable to the machinery or related product and explain the relationship between the general requirements of Section 1 and the supplementary requirements of Sections 2–6. Official text.

12. Directive 2006/42/EC on machinery. EUR-Lex. European Parliament and Council of the European Union, 17 May 2006; consolidated version available through EUR-Lex. Official text.

13. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website.

14. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website.

15. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

16. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website.

17. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

18. Directive 2006/42/EC on machinery. EUR-Lex. European Parliament and Council of the European Union, 17 May 2006; consolidated version available through EUR-Lex. Official text.

19. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

20. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

21. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

22. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. Regulation (EU) 2026/1744 — Digital Omnibus on AI. EUR-Lex. European Parliament and Council of the European Union, 8 July 2026. The Regulation amends the AI Act and Regulation (EU) 2023/1230, including machinery-specific AI provisions and transition arrangements. Official text.

23. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

24. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website.

25. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

26. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

27. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website.

28. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

29. Regulation (EU) 2023/1230 on machinery, Article 20. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Article 20 establishes the presumption-of-conformity mechanism, common specifications and the Regulation’s bridge to applicable European cybersecurity certification schemes. Official text.

30. Harmonised standards — Machinery Directive. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. The Commission states that the first harmonised-standard list under Regulation (EU) 2023/1230 is being prepared and is expected before the end of 2026, with the vast majority of Directive-era standards expected to carry over subject to limitations where new or revised EHSRs are not fully covered. Official website. See also Commission Implementing Decision (EU) 2026/2015 of 4 September 2026, published in the Official Journal of the European Union on 7 September 2026, which amended the Directive-era list and provides for repeal of Decision (EU) 2023/1586 from 20 January 2027. Official text.

31. EN 50742 / FprEN 50742 — Safety of machinery — Protection against corruption. The earlier national draft DIN EN 50742:2026-03 is based on prEN 50742:2025; subsequent project records identify FprEN 50742:2026 and the formal-approval stage. The project remains unpublished as a final EN and has not been cited in the Official Journal under Regulation (EU) 2023/1230 as of 3 October 2026. DIN draft record. FprEN project record.

32. CLC/TC 44X — Safety of machinery: electrotechnical aspects. CENELEC. The EN 50742 project is assigned to CLC/TC 44X; DIN’s committee records identify CLC/TC 44X/WG 02, Protection against corruption (including safety-related cybersecurity aspects) as the relevant working group. Committee/project record.

33. FprEN 50742:2026 — Safety of machinery — Protection against corruption. The draft states that it addresses accidental and intentional corruption, including malicious third-party actions resulting in hazardous situations, and applies to hardware interfaces, software and data capable of influencing machinery safety. It expressly identifies Regulation (EU) 2023/1230 Annex III §1.1.9 and associated requirements §1.2.1(a) and §1.2.1(f) as requirements it is intended to address. Project record.

34. Commission Implementing Decision C(2025) 129 of 20 January 2025 — standardisation request M/605. The Commission requested CEN and CENELEC to draft new harmonised standards and revise existing standards in support of Regulation (EU) 2023/1230 on machinery and related products. EN 50742 is being developed within this Machinery Regulation standardisation programme.

35. EN 50742 / FprEN 50742 — Safety of machinery — Protection against corruption. The earlier national draft DIN EN 50742:2026-03 is based on prEN 50742:2025; subsequent project records identify FprEN 50742:2026 and the formal-approval stage. The project remains unpublished as a final EN and has not been cited in the Official Journal under Regulation (EU) 2023/1230 as of 3 October 2026. DIN draft record. FprEN project record.

36. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

37. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

38. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

39. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

40. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

41. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

42. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

43. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

44. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

45. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

46. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

47. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

48. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

49. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

50. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC 62443 series — system and component security references used in this article. International Electrotechnical Commission. See IEC 62443-3-2:2020 on system security risk assessment and zones/conduits, Standard; IEC 62443-3-3:2013 on system security requirements, Standard; and IEC 62443-4-2:2019 on IACS component security requirements, Standard.

51. Regulation (EU) 2023/1230 on machinery, Articles 3(16) and 18. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Article 3(16) defines substantial modification, expressly including modification by physical or digital means, while Article 18 establishes the resulting manufacturer obligations for the person carrying out such a modification. Official text.

52. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

53. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

54. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

55. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

56. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

57. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

58. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

59. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

60. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

61. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

62. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. Regulation (EU) 2026/1744 — Digital Omnibus on AI. EUR-Lex. European Parliament and Council of the European Union, 8 July 2026. The Regulation amends the AI Act and Regulation (EU) 2023/1230, including machinery-specific AI provisions and transition arrangements. Official text.

63. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website. Directive (EU) 2022/2555 — NIS2 Directive. EUR-Lex. European Parliament and Council of the European Union, 14 December 2022. Article 21 establishes cybersecurity risk-management measures for essential and important entities. Official text.

64. ISO 12100:2010 — Safety of machinery — General principles for design — Risk assessment and risk reduction. International Organization for Standardization, 2010; confirmed current in 2022. Standard. ISO 13849-1:2023 — Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design. International Organization for Standardization, 2023. Standard. IEC 62061:2021 — Safety of machinery — Functional safety of safety-related control systems. International Electrotechnical Commission, 2021. IEC describes it as a machinery-sector-specific standard within the IEC 61508 framework. Standard.

65. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.

66. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

67. ISO 12100:2010 — Safety of machinery — General principles for design — Risk assessment and risk reduction. International Organization for Standardization, 2010; confirmed current in 2022. Standard.

68. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.

69. IEC 62443 series — system, component and secure-development references used in this article. International Electrotechnical Commission. See IEC 62443-3-2:2020 on system security risk assessment and zones/conduits, Standard; IEC 62443-3-3:2013 on system security requirements, Standard; IEC 62443-4-1:2018 on secure product development lifecycle requirements, Standard; and IEC 62443-4-2:2019 on technical security requirements for IACS components, Standard.

70. Harmonised standards — Machinery Directive. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. The Commission states that the first harmonised-standard list under Regulation (EU) 2023/1230 is being prepared and is expected before the end of 2026, with the vast majority of Directive-era standards expected to carry over subject to limitations where new or revised EHSRs are not fully covered. Official website. See also Commission Implementing Decision (EU) 2026/2015 of 4 September 2026, published in the Official Journal of the European Union on 7 September 2026, which amended the Directive-era list and provides for repeal of Decision (EU) 2023/1586 from 20 January 2027. Official text. EN 50742 / FprEN 50742 — Safety of machinery — Protection against corruption. The earlier national draft DIN EN 50742:2026-03 is based on prEN 50742:2025; subsequent project records identify FprEN 50742:2026 in the formal-approval stage. As of 3 October 2026, the project has not yet been published as a final EN or cited in the Official Journal under Regulation (EU) 2023/1230. DIN draft record. FprEN project record.

71. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. International Electrotechnical Commission, 2020. Standard.

72. IEC 62443-3-3:2013 — Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels. International Electrotechnical Commission, 2013. Standard. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard.

73. IEC 62443-4-1:2018 — Security for industrial automation and control systems — Part 4-1: Secure product development lifecycle requirements. International Electrotechnical Commission, 2018. Standard. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard.

74. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. International Electrotechnical Commission, 2020. Standard. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard.

75. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

76. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

77. IEC 62443-4-1:2018 — Security for industrial automation and control systems — Part 4-1: Secure product development lifecycle requirements. International Electrotechnical Commission, 2018. Standard.

78. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard.

79. IEC 62443-2-4:2023 — Security for industrial automation and control systems — Part 2-4: Security program requirements for IACS service providers. International Electrotechnical Commission, 2023. Standard.

80. IEC 62443-2-1:2024 — Security for industrial automation and control systems — Part 2-1: Security program requirements for IACS asset owners. International Electrotechnical Commission, 2024. Standard.

81. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

82. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. International Electrotechnical Commission, 2020. Standard.

83. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.

84. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.

85. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. International Electrotechnical Commission, 2020. Standard.

86. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

87. IEC 62443-2-4:2023 — Security for industrial automation and control systems — Part 2-4: Security program requirements for IACS service providers. International Electrotechnical Commission, 2023. Standard. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. International Electrotechnical Commission, 2020. Standard. IEC 62443-3-3:2013 — Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels. International Electrotechnical Commission, 2013. Standard.

88. ISO 12100:2010 — Safety of machinery — General principles for design — Risk assessment and risk reduction. International Organization for Standardization, 2010; confirmed current in 2022. Standard.

89. Harmonised standards — Machinery Directive. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. The Commission states that the first harmonised-standard list under Regulation (EU) 2023/1230 is being prepared and is expected before the end of 2026, with the vast majority of Directive-era standards expected to carry over subject to limitations where new EHSRs are not fully covered. Official website. See also Commission Implementing Decision (EU) 2026/2015 of 4 September 2026, which amended the Directive-era list and provides for repeal of Decision (EU) 2023/1586 from 20 January 2027. Official text.

90. ISO 13849-1:2023 — Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design. International Organization for Standardization, 2023. Standard.

91. ISO 13849-2:2012 — Safety of machinery — Safety-related parts of control systems — Part 2: Validation. International Organization for Standardization, 2012. Standard.

92. IEC 62061:2021 — Safety of machinery — Functional safety of safety-related control systems. International Electrotechnical Commission, 2021. IEC describes it as a machinery-sector-specific standard within the IEC 61508 framework. The current consolidated edition incorporates AMD1:2024 and AMD2:2026. Base standard and consolidated-version information. AMD2:2026.

93. IEC 62061:2021 — Safety of machinery — Functional safety of safety-related control systems. International Electrotechnical Commission, 2021. IEC describes it as a machinery-sector-specific standard within the IEC 61508 framework. Standard.

94. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.

95. IEC 62443 series — industrial automation and control system cybersecurity. International Electrotechnical Commission. Relevant references include IEC 62443-3-2:2020 on system security risk assessment and zones/conduits, Standard; IEC 62443-3-3:2013 on system security requirements, Standard; IEC 62443-4-1:2018 on secure product development lifecycle requirements, Standard; and IEC 62443-4-2:2019 on technical security requirements for IACS components, Standard.

96. EN 50742 / FprEN 50742 — Safety of machinery — Protection against corruption. The earlier national draft DIN EN 50742:2026-03 is based on prEN 50742:2025; subsequent project records identify FprEN 50742:2026 in the formal-approval stage. As of 3 October 2026, the project has not yet been published as a final EN or cited in the Official Journal under Regulation (EU) 2023/1230. DIN draft record. FprEN project record. See also Harmonised standards — Machinery Directive. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. The Commission states that the first harmonised-standard list under Regulation (EU) 2023/1230 is still being prepared and is expected before the end of 2026. Official website.

97. Harmonised standards — Machinery Directive. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. The Commission states that the first harmonised-standard list under Regulation (EU) 2023/1230 is being prepared and is expected before the end of 2026, with the vast majority of Directive-era standards expected to carry over subject to limitations where new EHSRs are not fully covered. Official website. See also Commission Implementing Decision (EU) 2026/2015 of 4 September 2026, which amended the Directive-era list and provides for repeal of Decision (EU) 2023/1586 from 20 January 2027. Official text. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Commission overview of the Machinery Regulation, its New Legislative Framework alignment, conformity model and transition from Directive 2006/42/EC. Official website.

98. AI Omnibus enters into force. European Commission — Shaping Europe’s digital future, 31 July 2026. The Commission states that rules for high-risk AI embedded in physical Annex I products, including machinery, apply from 2 August 2028. Official website. Regulation (EU) 2024/1689 — Artificial Intelligence Act. EUR-Lex. European Parliament and Council of the European Union, 13 June 2024; current version reflects the 2026 amendments. Official text. Regulation (EU) 2026/1744 — Digital Omnibus on AI. EUR-Lex. European Parliament and Council of the European Union, 8 July 2026. The Regulation amends the AI Act and Regulation (EU) 2023/1230, including machinery-specific AI provisions and transition arrangements. Official text.

99. Regulation (EU) 2026/1744 — Digital Omnibus on AI. EUR-Lex. European Parliament and Council of the European Union, 8 July 2026. The Regulation amends both the AI Act and Regulation (EU) 2023/1230, including machinery-specific AI integration provisions, conformity mechanisms and associated application arrangements. Official text.

100. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

101. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

102. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. Regulation (EU) 2024/1689 — Artificial Intelligence Act. EUR-Lex. European Parliament and Council of the European Union, 13 June 2024; current version reflects the 2026 amendments. Official text.

103. Regulation (EU) 2024/1689 — Artificial Intelligence Act. EUR-Lex. European Parliament and Council of the European Union, 13 June 2024; current version reflects the 2026 amendments. Official text.

104. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. The Regulation lays down horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text.

105. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website. Regulation (EU) 2024/1689 — Artificial Intelligence Act. EUR-Lex. European Parliament and Council of the European Union, 13 June 2024; current version reflects the 2026 amendments. Official text.

106. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

107. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. The Regulation lays down horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text.

108. Directive (EU) 2022/2555 — NIS2 Directive, Article 21. EUR-Lex. European Parliament and Council of the European Union, 14 December 2022. Article 21 establishes cybersecurity risk-management measures for essential and important entities, including incident handling, business continuity, supply-chain security, secure acquisition/development/maintenance, vulnerability handling, access control and, where appropriate, multi-factor authentication. Official text.

109. Regulation (EU) 2024/1689 — Artificial Intelligence Act. EUR-Lex. European Parliament and Council of the European Union, 13 June 2024; current version reflects the 2026 amendments. Official text. Regulation (EU) 2026/1744 — Digital Omnibus on AI. EUR-Lex. European Parliament and Council of the European Union, 8 July 2026. The Regulation amends the AI Act and Regulation (EU) 2023/1230, including machinery-specific AI provisions and transition arrangements. Official text.

110. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. The Regulation lays down horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website.

111. Regulation (EU) 2024/2847 — Cyber Resilience Act, recital 53. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. Recital 53 expressly addresses products also falling within Regulation (EU) 2023/1230, noting that the two instruments can address similar cybersecurity risks and specifically referring to Machinery Regulation Annex III §§1.1.9 and 1.2.1. The Regulation more generally establishes horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text.

112. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. The Regulation lays down horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website.

113. Directive (EU) 2022/2555 — NIS2 Directive. EUR-Lex. European Parliament and Council of the European Union, 14 December 2022. The Directive applies entity-level cybersecurity obligations across the sectors and entity categories defined by its scope and annexes, subject to its size, sector and national-implementation rules; Article 21 establishes cybersecurity risk-management measures for essential and important entities. Official text.

114. IEC 62443-4-1:2018 — Security for industrial automation and control systems — Part 4-1: Secure product development lifecycle requirements. International Electrotechnical Commission, 2018. Standard. IEC 62443-2-1:2024 — Security for industrial automation and control systems — Part 2-1: Security program requirements for IACS asset owners. International Electrotechnical Commission, 2024. Standard. IEC 62443-2-4:2023 — Security for industrial automation and control systems — Part 2-4: Security program requirements for IACS service providers. International Electrotechnical Commission, 2023. Standard.

115. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. The Regulation lays down horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text.

116. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. The Regulation lays down horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text.

117. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

118. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard.

119. Directive (EU) 2022/2555 — NIS2 Directive. EUR-Lex. European Parliament and Council of the European Union, 14 December 2022. Article 21 establishes cybersecurity risk-management measures for essential and important entities. Official text. IEC 62443-3-3:2013 — Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels. International Electrotechnical Commission, 2013. Standard.

120. IEC 62443-4-1:2018 — Security for industrial automation and control systems — Part 4-1: Secure product development lifecycle requirements. International Electrotechnical Commission, 2018. Standard. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. The Regulation lays down horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text.

121. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website.

122. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website.

123. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. International Electrotechnical Commission, 2020. Standard. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard.

124. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

125. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website.

126. Regulation (EU) 2024/2847 — Cyber Resilience Act. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. The Regulation lays down horizontal cybersecurity requirements for products with digital elements, including secure design, vulnerability handling, updates, technical documentation and conformity assessment. Official text.

127. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

128. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard.

129. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

130. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

131. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

132. IEC 62443-4-1:2018 — Security for industrial automation and control systems — Part 4-1: Secure product development lifecycle requirements. International Electrotechnical Commission, 2018. Standard. The Cyber Resilience Act — summary of the legislative text. European Commission — Shaping Europe’s digital future. The Commission records entry into force on 10 December 2024, reporting obligations from 11 September 2026 and full application from 11 December 2027, and summarises the CRA lifecycle and vulnerability-handling duties. Official website.

133. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

134. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

135. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

136. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

137. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

138. ISO 13849-1:2023 — Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design. International Organization for Standardization, 2023. Standard. IEC 62061:2021 — Safety of machinery — Functional safety of safety-related control systems. International Electrotechnical Commission, 2021. IEC describes it as a machinery-sector-specific standard within the IEC 61508 framework. Standard. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.

139. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC 62443-3-2:2020 — Security for industrial automation and control systems — Part 3-2: Security risk assessment for system design. International Electrotechnical Commission, 2020. Standard. IEC 62443-4-2:2019 — Security for industrial automation and control systems — Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission, 2019. Standard.

140. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

141. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

142. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC 62443 series — system and component security references used in this article. International Electrotechnical Commission. See IEC 62443-3-2:2020 on system security risk assessment and zones/conduits, Standard; IEC 62443-3-3:2013 on system security requirements, Standard; and IEC 62443-4-2:2019 on IACS component security requirements, Standard.

143. Harmonised standards — Machinery Directive. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. The Commission states that the first harmonised-standard list under Regulation (EU) 2023/1230 is being prepared and is expected before the end of 2026, with the vast majority of Directive-era standards expected to carry over subject to limitations where new EHSRs are not fully covered. Official website. See also Commission Implementing Decision (EU) 2026/2015 of 4 September 2026, which amended the Directive-era list and provides for repeal of Decision (EU) 2023/1586 from 20 January 2027. Official text. IEC 62443 series — secure product and system engineering. International Electrotechnical Commission. See IEC 62443-4-1:2018, secure product development lifecycle requirements, Standard, and IEC 62443-4-2:2019, technical security requirements for IACS components, Standard.

144. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.

145. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

146. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

147. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC 62443-2-4:2023 — Security for industrial automation and control systems — Part 2-4: Security program requirements for IACS service providers. International Electrotechnical Commission, 2023. Standard.

148. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

149. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.

150. Regulation (EU) 2024/2847 — Cyber Resilience Act, recital 53. EUR-Lex. European Parliament and Council of the European Union, 23 October 2024. Recital 53 expressly addresses the interaction with Regulation (EU) 2023/1230, recognising that both instruments can address similar cybersecurity risks and specifically referring to Machinery Regulation Annex III §§1.1.9 and 1.2.1. The CRA establishes the broader horizontal product-cybersecurity framework for products with digital elements. Official text.

151. Machinery. European Commission — Internal Market, Industry, Entrepreneurship and SMEs. Current Commission overview of Regulation (EU) 2023/1230, including the 20 January 2027 application date, New Legislative Framework alignment, digital documentation, AI and cyber-safety provisions. Official website. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

152. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text.

153. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification. IEC 62443 series — secure product and system engineering. International Electrotechnical Commission. See IEC 62443-4-1:2018, secure product development lifecycle requirements, Standard, and IEC 62443-4-2:2019, technical security requirements for IACS components, Standard.

154. Regulation (EU) 2023/1230 on machinery. EUR-Lex. European Parliament and Council of the European Union, 14 June 2023; consolidated version current to 27 July 2026. Official text. IEC TS 63074:2023 — Safety of machinery — Security aspects related to functional safety of safety-related control systems. International Electrotechnical Commission, 2023. The Technical Specification addresses IEC 62443-related threats and vulnerabilities that can cause loss of the ability of machinery safety-related control systems to maintain safe operation and includes threat modelling. Technical Specification.