The EU Machinery Regulation (EU) 2023/1230 becomes generally applicable on 20 January 2027, replacing the Machinery Directive 2006/42/EC. It updates the EU's machinery-safety framework for increasingly connected, software-controlled and autonomous machines. An important change is its explicit treatment of cybersecurity where compromised software, data or control systems could create safety hazards.
For manufacturers, this raises a practical question: how do these requirements relate to the Cyber Resilience Act, ISO 27001, IEC 62443 and other existing frameworks?
The answer is integration, not substitution. Organisations can reuse controls, processes and evidence across these instruments, but must still demonstrate that they meet each applicable requirement.
1. What the Machinery Regulation changes
The Machinery Regulation remains primarily a product-safety law. Cybersecurity becomes relevant when a digital compromise could undermine machinery safety.
Two provisions in Annex III are particularly important:
- Section 1.1.9, "Protection against corruption", addresses protection of safety-relevant hardware, software and data against accidental or intentional corruption. It also includes requirements concerning identification and evidence of relevant interventions.
- Section 1.2.1, "Safety and reliability of control systems", includes reasonably foreseeable malicious attempts that could lead to hazardous situations.
Manufacturers need to consider not only whether a component can be compromised, but also whether that compromise could cause dangerous movement, defeat a protective function or otherwise create a hazardous situation.
For example, a vulnerability in a remote-maintenance interface may become a machinery-safety issue if an attacker could use it to change a robot's operating limits or interfere with a safety-related control function.
2. The main frameworks address different layers
The Machinery Regulation, Cyber Resilience Act and NIS2 are legal instruments. ISO 27001 and IEC 62443 are standards that can support implementation and assurance. Adopting a standard does not, by itself, establish compliance with an applicable law.
| Instrument | Main focus | What it addresses | Relationship to machinery |
|---|---|---|---|
| Machinery Regulation, EU 2023/1230 | Product safety | Machinery hazards, protective measures and safety-related control systems | Requires manufacturers to address cybersecurity where it can affect machine safety. |
| Cyber Resilience Act, EU 2024/2847 | Product cybersecurity | Secure design, vulnerability handling, security updates and other obligations for in-scope products with digital elements | Can apply alongside the Machinery Regulation to connected machinery and digital components. |
| ISO/IEC 27001 | Organisational information-security management | A management system for identifying, treating and reviewing information-security risks | Provides governance and supporting processes, but does not certify an individual machine's safety or cybersecurity. |
| IEC 62443 series | Industrial cybersecurity | Secure development, technical security and protection of industrial automation and control systems | Provides engineering and lifecycle requirements relevant to manufacturers, integrators and operators. |
| NIS2 | Organisational and operational cybersecurity | Cybersecurity risk management and reporting for entities within scope | May apply to manufacturers or operators independently of their product-compliance duties. |
A manufacturer may use ISO 27001 to manage its internal security programme, IEC 62443 to guide industrial product engineering, the CRA to address product-cybersecurity obligations, and the Machinery Regulation to demonstrate that the finished machine is safe.
3. Machinery Regulation and CRA: where the overlap is strongest
The Machinery Regulation asks whether a cybersecurity failure could make the machine unsafe. The CRA addresses product cybersecurity more broadly, including risks that do not necessarily result in physical harm. Its requirements cover secure design, vulnerability handling, security updates and component documentation, including software bills of materials, or SBOMs.
Shared areas and different expectations
| Area | Machinery Regulation perspective | CRA perspective |
|---|---|---|
| Risk assessment | Identify whether digital interference could create a machinery hazard. | Assess cybersecurity risks associated with the product. |
| Software and data integrity | Protect software and data relevant to safety and compliance. | Protect the product against cybersecurity risks, including unauthorised manipulation. |
| Access and interfaces | Prevent connected devices or remote access from creating hazardous situations. | Reduce attack surfaces and protect against unauthorised access. |
| Updates and changes | Ensure modifications do not undermine safety-related functions. | Provide security updates and address vulnerabilities during the applicable support period. |
| Documentation | Demonstrate machinery safety and satisfaction of applicable essential requirements. | Demonstrate product-cybersecurity compliance and vulnerability-handling arrangements. |
This is a thematic mapping, not a legal equivalence table. Each row requires assessment against the precise provisions applicable to the product.
Does CRA compliance satisfy the Machinery Regulation?
Not automatically. Manufacturers still need to demonstrate how cybersecurity measures address relevant machinery-safety requirements and follow applicable conformity-assessment procedures.
The Machinery Regulation also contains a specific mechanism for a presumption of conformity under qualifying European cybersecurity certification schemes. This is limited to the requirements and coverage specified in the legislation; it is not a general exemption from machinery-safety assessment or a benefit automatically provided by ISO 27001 certification.
4. ISO 27001: a useful foundation, not product approval
ISO 27001 establishes requirements for an information security management system, or ISMS. It helps an organisation manage security through defined responsibilities, risk assessment, controls, performance evaluation and continual improvement. Its certification applies to a defined organisational scope.
Manufacturers may already have processes for access control, supplier assurance, change management and incident handling. Those processes need to produce evidence relevant to the machine itself. A policy describing how software changes are approved does not demonstrate that an unauthorised change to safety-critical software will be prevented or detected. That requires product-specific design, implementation and verification evidence.
Mapping organisational capabilities to product evidence
| Existing capability | What can be reused | What needs to be added for machinery |
|---|---|---|
| Risk management | Ownership, assessment methods, review cycles and treatment tracking | Analysis linking cyber threats to machinery hazards and safety measures |
| Access management | Identity lifecycle, privileged-access controls and access reviews | Controls over machine interfaces, maintenance access and safety-relevant configuration |
| Change management | Approval workflows, traceability and release records | Verification that changes preserve required safety behaviour |
| Supplier management | Due diligence, contractual requirements and assurance reviews | Evidence concerning supplied components and their integration into the machine |
| Incident management | Escalation, investigation and remediation processes | Assessment of physical-safety consequences and applicable product-specific obligations |
| Document control | Controlled records, responsibilities and retention processes | Product-specific technical documentation and conformity evidence |
Reuse the management system while extending its evidence to cover product engineering and machine safety. This mapping identifies opportunities for reuse; it does not mean that an ISO 27001 control automatically satisfies a Machinery Regulation requirement.
5. IEC 62443: connecting governance to industrial engineering
IEC 62443 addresses cybersecurity in industrial automation and control systems. The series covers development processes, technical capabilities and the roles of different participants in an industrial system.
Two parts are especially useful for product manufacturers:
- IEC 62443-4-1 specifies secure product-development lifecycle requirements, including security requirements, design, implementation, verification, defect management, updates and end-of-life considerations.
- IEC 62443-4-2 specifies technical security requirements for industrial automation and control-system components.
IEC 62443 can help a manufacturer implement engineering practices that support CRA and machinery-safety obligations. Conformity with a particular part must be assessed in context and should not be presented as automatic compliance with either regulation.
6. NIS2 and other adjacent obligations
NIS2 adds an organisational and operational perspective. Where a manufacturer or machine operator falls within scope, it may need to manage cybersecurity risks affecting its own networks, systems and services alongside its product-related duties.
This creates two distinct responsibilities:
- A manufacturer must address applicable requirements for products it places on the market.
- An operator must manage the security of its operating environment and use of those products.
The same organisation may hold both roles.
GDPR remains relevant where machinery or associated services process personal data. Product-liability rules address responsibility for damage caused by defective products, including circumstances involving cybersecurity and missing security updates. Neither replaces preventive obligations under product-safety or cybersecurity legislation.
7. Building one evidence base without merging the obligations
The most useful integration happens at the evidence level. An organisation can maintain shared records and processes while assessing each legal or standards requirement separately.
Step 1: Establish applicability
Identify the machine, its intended use, connectivity, software dependencies and supply-chain roles. Determine which legislation applies to the finished product, its components and the organisation.
Step 2: Link cybersecurity risks to safety hazards
Connect relevant vulnerabilities and attack scenarios to the functions they could affect. Record whether a compromise could cause hazardous behaviour, and which measures prevent or limit that outcome.
Step 3: Reuse common technical evidence
Maintain architecture records, component inventories, SBOMs, access-control specifications, release histories, security-test results and vulnerability decisions in a form that can support multiple assessments.
Step 4: Add machinery-specific assurance
Document safety-relevant software and data, protection against corruption, relevant interventions and verification that security-related changes preserve safe operation.
Step 5: Keep compliance outputs distinct
Retain technical documentation, conformity assessments, declarations and reporting processes required by each applicable instrument. Reusing evidence should reduce duplication, not obscure which requirement has been satisfied.
An SBOM can help identify which machines contain a vulnerable component. It does not, by itself, show whether the vulnerability could defeat a safety function. That requires a connection between the component, its function, the machine's hazards and the relevant verification evidence.
8. The implementation timeline
| Date | Milestone |
|---|---|
| 11 September 2026 | CRA reporting obligations began applying for actively exploited vulnerabilities and severe incidents affecting product security, subject to the regulation's conditions. |
| 20 January 2027 | The Machinery Regulation becomes generally applicable, replacing the Machinery Directive. |
| 11 December 2027 | The CRA's main product requirements become applicable. |
Manufacturers should plan for a staged transition. Work on CRA product security can support preparations for the Machinery Regulation, but it should not postpone the machinery-specific safety assessment.
Conclusion
The upcoming Machinery Regulation connects cybersecurity to a product-safety question: could interference with this machine's software, data or control systems make it dangerous? The CRA addresses the wider cybersecurity lifecycle of in-scope digital products, ISO 27001 supplies an organisational management foundation, and IEC 62443 supports industrial security engineering.
The practical goal is not to combine them into one undifferentiated checklist. It is to connect common controls and evidence to distinct requirements while preserving the product-specific engineering, safety assessment and legal accountability that each instrument requires.
FAQs
Not automatically. The CRA addresses product cybersecurity more broadly, including risks that do not necessarily cause physical harm. The Machinery Regulation still requires manufacturers to show how cybersecurity measures address relevant machinery-safety requirements and to follow applicable conformity-assessment procedures.
No. ISO 27001 certifies an organisation's information security management system for a defined scope. It does not certify that an individual machine is safe or cyber-secure. Organisational processes can be reused, but manufacturers still need product-specific design, implementation and verification evidence.
IEC 62443-4-1 and IEC 62443-4-2 provide secure development and technical security requirements for industrial automation and control-system components. They can support engineering practices that help meet CRA and machinery-safety obligations, but conformity with a particular part is not automatic compliance with either regulation.
It becomes generally applicable on 20 January 2027, replacing the Machinery Directive 2006/42/EC. Manufacturers should plan the machinery-specific safety assessment alongside CRA work rather than waiting until after product-cybersecurity preparations are complete.
Yes, at the evidence level. Shared records such as architecture descriptions, SBOMs, access-control specifications, release histories and security-test results can support multiple assessments. Compliance outputs should still stay distinct so it remains clear which legal or standards requirement each piece of evidence supports.