You are currently viewing IEC 62443 and EN 50742: How the Two Standards Work Together

IEC 62443 and EN 50742: How the Two Standards Work Together

How Do IEC 62443 and EN 50742 Fit Together?

IEC 62443 is the general framework for securing industrial automation systems. EN 50742 is the machinery standard that asks a narrower question: can corruption of a machine’s hardware, software or data lead to a hazardous situation? EN 50742 does not replace IEC 62443, and IEC 62443 alone does not answer the machinery question. The two meet formally in Approach B of EN 50742, which lets manufacturers build on parts of the IEC 62443 series.

EN 50742 was published for comment as prEN 50742:2025, in Germany as E DIN EN 50742 (VDE 0113-742):2026-03. At the time of writing, in November 2026, the final draft FprEN 50742:2026 is in the last stage of approval at CENELEC. The clause references in this article follow the public draft, so check them against the final text.

Two Standards, Two Questions

  • Goal: IEC 62443 protects the automation system against cyber threats, whatever the consequence, including lost production or disclosed data. EN 50742 protects the safety of the machine against corruption, whether accidental or intentional.
  • Legal background: IEC 62443 is a voluntary international standard. EN 50742 is being prepared to support Annex III of the EU Machinery Regulation (EU) 2023/1230, sections 1.1.9 and 1.2.1.
  • Starting point: IEC 62443 starts from the system under consideration and its zones and conduits. EN 50742 starts from the risk assessment according to EN ISO 12100.
  • Who it addresses: IEC 62443 addresses asset owners, service providers and product suppliers. EN 50742 addresses the manufacturer of the machine, who can be a product supplier or a system integrator. The role of the user is not covered.

The draft of EN 50742 states two principles that shape the whole analysis. Vulnerabilities do not create new hazards, but they can turn existing hazards into dangerous situations. And because the probability of a malicious attempt cannot be predicted, the risk is assessed by its impact on functional safety. That is a different mindset from the usual IT risk matrix.

Where They Meet: Approach B

The draft offers two approaches, and one of them has to be applied:

  • Approach A (Clauses 5 and 7) is meant for machinery developed without reference to the EN IEC 62443 series.
  • Approach B (Clauses 6 and 8) is meant for machinery developed in the context of EN IEC 62443-3-3, EN IEC 62443-4-1 and EN IEC 62443-4-2.

Under Approach B, each of these parts has a clear job:

  • IEC 62443-4-1 provides the process requirements for development and maintenance.
  • IEC 62443-3-3 applies to the machinery system, with a defined selection of its requirements for the safety functions.
  • IEC 62443-4-2 applies to machinery components, with a defined selection that includes support of essential functions and least privilege. In this context, the safety functions of the machine count as essential functions.

So Approach B does not ask you to apply all of IEC 62443 to the entire machine. It concentrates on the requirements that protect the safety functions. We explain the practical steps in our article on the EN 50742 threat assessment under Option B.

Security Levels and SRSL Are Different Scales

Security levels (SL 1 to 4) in IEC 62443 describe the attacker a zone, system or component can withstand, in terms of means, resources, skills and motivation. The Safety-Related Security Levels (SRSL 0 to 3) in EN 50742 are derived from a safety perspective and assigned to each safety function, based on the machine’s exposure, the capability of an attacker and the available window of opportunity.

The numbers look similar, but they do not measure the same thing. We have not found an official mapping between the two, so SL 2 should not be read as SRSL 2. If your team works with both, record each level with its own reasoning.

One Workflow for Safety and Security

The standards fit together best when the work is done once, in the right order:

  • Risk assessment: Define the machine limits, hazards and safety functions according to EN ISO 12100.
  • System model: Model components, interfaces and data flows, and group them into zones and conduits if you work with IEC 62443. Interfaces to external systems are in scope, the external systems themselves are not.
  • Threat assessment: Work out which threats can reach a safety function and what an attack would take.
  • Requirements: Derive the protection requirements and record where each one comes from: EN 50742, IEC 62443 or both.
  • Evidence: Link each requirement to design decisions, tests and information for the user, with versions and review status.
  • Maintenance: Re-check the analysis when the machine changes or a new vulnerability becomes known.

Where the Cyber Resilience Act Comes In

The Cyber Resilience Act adds a third perspective. A connected machine can fall under both the CRA and the Machinery Regulation. The CRA looks at the cybersecurity of the product, EN 50742 at the consequences for safety, and IEC 62443 offers a method that can serve the security work for both. Meeting one law does not automatically mean meeting the other, so each requirement should be traced to the rule it serves.

Where EnCo ASE Fits In

EnCo ASE Threat Assessment guides you through the EN 50742 threat assessment on one system model, from assets and safety functions through threats at each interface, attack potential and the SRSL of each safety function to protection requirements, treatments and evidence. Catalogues for interfaces, technologies and data kinds keep the system model consistent.

EnCo ASE covers both approaches of EN 50742, approach A and approach B with IEC 62443, along with everything you need around the standard, including SBOM and catalogues.

Next Steps

Conclusion

IEC 62443 shows how to secure industrial automation. EN 50742 shows what that has to achieve for the safety of a machine. Approach B connects them: manufacturers who already work with IEC 62443 can build on it, provided they focus the work on the safety functions and document the link. Done in one workflow, safety and security stop being two separate projects.