IEC 62443-3-3 System Security Requirements and Security Levels
IEC 62443-3-3 is the standard you need if you secure an industrial automation and control system (IACS) against cyber threats. It sets the technical system requirements against which a machine or plant system is measured, and it maps them to four security levels (SL 1 to SL 4). The Cyber Resilience Act (CRA) and the new Machinery Regulation make it relevant in two ways. Through EN 50742, IEC 62443-3-3 is also the main bridge standard into machinery safety.
Contents
- What IEC 62443-3-3 covers
- Security levels SL 1 to SL 4
- The seven foundational requirements (FR 1 to FR 7)
- System requirements and requirement enhancements
- Zones, conduits, and the link to IEC 62443-3-2
- IEC 62443-3-3 and the Cyber Resilience Act
- Application in machine and plant engineering
- Machinery Regulation and EN 50742
- IEC 62443-3-3 and certification in practice
- How to apply IEC 62443-3-3 in a project
- Further reading
What IEC 62443-3-3 covers
IEC 62443-3-3 sets the technical system requirements (SR) for control systems and derives the capability security levels (SL-C) of the system from them. Its main audience is asset owners, system integrators, and product suppliers in industrial automation.
In machine and plant engineering, the question of who the standard addresses is not simple. A machine builder can take on several roles in a single delivery: integrator (integration service provider), service provider (for maintenance), and product supplier for its own software or components. Each role falls under a different part of the IEC 62443 series. Part 3-3 is the system building block that sets the technical benchmark.
For an overview of the whole series, see the IEC 62443 overview page.
Security levels SL 1 to SL 4
SL 1 to SL 4 as levels of protection
Security levels describe which attacker profile a system must be protected against. They are not relative values. Each level is tied to the resources, skills, and motivation of the attacker.
| SL | Attacker profile | Typical use case |
|---|---|---|
| SL 1 | Protection against casual or coincidental violation | Stand-alone machines without critical network connections; given today's threat situation, sufficient only in justified exceptions |
| SL 2 | Protection against intentional violation using simple means with low resources, generic skills, and low motivation | Realistic target level for most machines and plants, both installed base and new development |
| SL 3 | Protection against intentional violation using sophisticated means with moderate resources, IACS-specific skills, and moderate motivation | Sensitive components, critical infrastructure, highly exposed plants |
| SL 4 | Protection against intentional violation using sophisticated means with extended resources, IACS-specific skills, and high motivation | State-sponsored attacks, highest protection needs; rarely realistic as a target level |
SL-T, SL-A, and SL-C: three views of a security level
A security level has more than one dimension. IEC 62443 distinguishes three types that build on each other during a project:
- Target security level (SL-T): the intended level of protection. The asset owner or integrator derives it for each zone from a risk assessment under IEC 62443-3-2.
- Capability security level (SL-C): the level of protection that a system (or a component) can provide based on its technical capabilities. This is where IEC 62443-3-3 comes in. It defines SL-C(FR, control system) 1 to 4 for each of the seven foundational requirements.
- Achieved security level (SL-A): the level of protection actually achieved in operation, that is, after commissioning and including all organizational and compensating countermeasures.
The literature uses the concept of a security protection rating (SPR) to combine these three views into one consistent assessment model (see further reading). In day-to-day work, SL-C is the most important view. It states what the system is capable of, regardless of whether that capability is actually switched on in the end.
SL-T is set under IEC 62443-3-2
IEC 62443-3-3 assumes that the SL-T for each zone is already known. It does not define it. The SL-T is set in a security risk assessment under IEC 62443-3-2, and this must happen before you select the SRs.
The seven foundational requirements (FR 1 to FR 7)
The core of IEC 62443-3-3 is a set of seven foundational requirements (FR). They structure the entire body of requirements:
- FR 1 Identification and authentication control (IAC): identification and authentication of all human users, software processes, and devices before any access.
- FR 2 Use control (UC): enforcement of authorizations, session control, logging of auditable events.
- FR 3 System integrity (SI): protection of the integrity of communication, software, data, and control logic.
- FR 4 Data confidentiality (DC): confidentiality of information on communication channels and in data repositories.
- FR 5 Restricted data flow (RDF): segmentation into zones, protection of zone boundaries, control of data flows.
- FR 6 Timely response to events (TRE): detection of incidents, audit capability, continuous monitoring.
- FR 7 Resource availability (RA): availability of resources, protection against denial of service, backup and recovery.
| FR | Title | Number of SRs | Number of REs | Typical content |
|---|---|---|---|---|
| FR 1 | Identification and authentication control | 13 | 11 | User and device authentication, account and authenticator management, PKI |
| FR 2 | Use control | 12 | 12 | Authorization, session control, auditable events, timestamps, non-repudiation |
| FR 3 | System integrity | 9 | 10 | Communication, software, and information integrity, malicious code protection, input validation |
| FR 4 | Data confidentiality | 3 | 3 | Confidentiality, use of cryptography |
| FR 5 | Restricted data flow | 4 | 7 | Network segmentation, zone boundary protection, general purpose person-to-person communication restrictions |
| FR 6 | Timely response to events | 2 | 1 | Audit logs, continuous monitoring |
| FR 7 | Resource availability | 8 | 5 | DoS protection, backup and recovery, component inventory, emergency power |
| Total | 51 | 49 |
The standard contains 51 system requirements and 49 requirement enhancements in total. How many of them you must implement depends on the SL-T of each zone. A German industry guide by VDMA (German Mechanical Engineering Industry Association) shows this with a model machine. It picks 20 of the 51 SRs as examples and covers 9 of the 11 REs that also apply for SL 2 according to Annex B of the standard. The 11 REs are therefore the SL 2 selection in the VDMA model, not the total number of SL 2 REs across the whole standard.
System requirements and requirement enhancements
Every SR in the standard follows the same structure:
- Requirement: the normative requirement itself (in the form “The control system shall provide the capability to …”).
- Rationale and supplemental guidance: the reasoning behind the requirement and guidance on applying it.
- Requirement enhancements (RE): optional additions that apply depending on the target SL.
- Security levels: a mapping of which REs are mandatory for which SL-C (1 to 4).
An example shows the pattern. SR 1.1 “Human user identification and authentication” requires the control system to provide the capability to identify and authenticate all human users. For SL 1, the base requirement is enough. For SL 2, RE 1 adds unique identification (not just group identification). For SL 3, RE 2 adds multifactor authentication for access from untrusted networks. For SL 4, RE 3 requires multifactor authentication for all networks.
This escalation applies to all SRs. Annex B of the standard contains the full mapping of all SRs and REs to the four SLs.
Zones, conduits, and the link to IEC 62443-3-2
IEC 62443-3-3 builds on the zone and conduit model of IEC 62443-3-2. You do not set one SL-T for “the system” as a whole. You set it for each zone, that is, for each group of assets with common security requirements. Conduits model the connections between zones, and each conduit also gets an SL-T.
In practice, this means dividing the plant into zones whose boundaries are protected by firewalls, data diodes, or similar measures. The SRs of FR 5 (restricted data flow) provide the normative basis for this zone model. The VDMA guide recommends grouping assets by criteria such as IT and OT devices, safety-relevant and non-safety-relevant devices, temporarily and permanently connected devices, and wireless and wired devices.
IEC 62443-3-3 and the Cyber Resilience Act
The Cyber Resilience Act (Regulation (EU) 2024/2847) gives IEC 62443-3-3 a new role. It is not yet settled whether IEC 62443-3-3 will be listed as a harmonized standard under the CRA and so give a formal presumption of conformity with the essential cybersecurity requirements in Annex I. Our article on harmonized standards under the CRA explains which standards are being developed for the CRA. Applying the standard consistently helps you meet these requirements in any case. Whether that is formally sufficient remains open. Even so, the character of the standard changes: it is no longer only a mark of quality but becomes a de facto minimum requirement for placing products on the market.
VDMA sums up this shift: with the CRA, the relevant standards change from a voluntary mark of quality to a de facto minimum requirement for anyone who wants to sell a connected product in the EU single market.
Further reading:
- Using IEC 62443 to meet Cyber Resilience Act requirements
- ENISA maps CRA requirements to existing standards
Find out your CRA maturity
Do you want to know how far your product is from the CRA requirements and which standards you should aim for? The CRA readiness check gives you a first structured assessment.
Application in machine and plant engineering
For machine and plant builders, choosing the target SL is a balancing act between economics and technology. The VDMA guide to IEC 62443 for machine and plant engineering (in German) recommends SL 2 as a realistic target level for most machines and plants. It considers SL 1 (protection only against casual violation) no longer sufficient given the threat situation. SL 3 (sophisticated attacks with IACS expertise) is already a real threat level in many areas, but cannot yet be implemented across the board in terms of processes and cost.
This recommendation reflects the multiple roles of the machine builder mentioned above. As an integrator under IEC 62443-2-4, the machine builder ensures that the system implements the SRs. As a service provider, it covers maintenance and commissioning under the same requirements. As a manufacturer of its own components or software, it addresses the requirements of IEC 62443-4-1 (development process) and IEC 62443-4-2 (technical component requirements). IEC 62443-3-3 is the common technical reference point that brings these roles together at system level.
A practical observation from the VDMA community: the standard intends the asset owner to carry out the risk assessment under IEC 62443-3-2 and to set the SL-T. In reality, the asset owner usually hands this task to the machine builder, because the specification only contains functional safety requirements. If you do not address this actively, you take over the risk assessment implicitly, without knowing the asset owner's basis for it (risk decisions, threat situation, business continuity criteria). You should therefore raise the topic early in the sales process and agree on it with the asset owner.
Machinery Regulation and EN 50742
The new Machinery Regulation (Regulation (EU) 2023/1230, applicable from January 20, 2027) adds a second regulatory layer for connected machinery. Annex III contains two central cybersecurity provisions: section 1.1.9 (protection against corruption) and section 1.2.1 (safety and reliability of control systems). The text of the regulation does not say how to implement these requirements technically.
EN 50742 on protecting machinery against corruption fills this gap. It is intended to be listed as a harmonized standard under the Machinery Regulation. For details, see the EN 50742 page.
The draft offers two approaches:
- Approach A: a stand-alone approach with self-contained requirements, suited to manufacturers starting without an IEC 62443 background.
- Approach B: the “IEC 62443 approach”. IEC 62443-4-1 applies to the process requirements. For the safety-related functions of the machine, the standard names, for each foundational requirement, a selection of system requirements from IEC 62443-3-3 that must be met as a minimum. The safety-related functions of individual components follow the same pattern via IEC 62443-4-2. You check this selection against the results of the security risk assessment and the protection that the intended operating environment already provides.
Within one machine, you may combine both approaches and design some components under Approach A and others under Approach B. The general requirements of the standard and its requirements for user information apply regardless of the approach you choose.
The conceptual bridge in EN 50742 matters most: the essential functions of IEC 62443-3-3 include the safety functions of a machine. This lets you apply the established FR and SR framework of IEC 62443 to the Machinery Regulation. If you set up IEC 62443-3-3 for the CRA anyway, you can use the same framework through Approach B of EN 50742 for the cybersecurity requirements of the Machinery Regulation.
The two regulations often overlap. A connected machine can fall under both the CRA and the Machinery Regulation. In that case, you need both conformity assessments; one does not replace the other. For more on how the two fit together, see our detailed article on how the CRA and the Machinery Regulation overlap.
Risk assessment template for EN 50742
Want to set up the risk assessment for your machine under EN 50742 in a structured way? We provide a template that goes through the requirements of EN 50742 step by step.
IEC 62443-3-3 and certification in practice
IEC 62443-3-3 itself does not require certification. It provides the technical requirements and the logic for assigning levels, nothing more. In practice, however, a set of accredited schemes has developed that allows conformity with the standard to be confirmed: ISASecure SSA, the IECEE CB Scheme, and accredited conformity assessment programs of various testing and certification companies (for example TÜV).
Practice shows an important link that the standard text does not state as such. A reliable SL-C of a system or component depends on the underlying product capabilities having been developed in an assessed development process under IEC 62443-4-1. Conformity assessment bodies working under the IECEE CB Scheme or as accredited bodies usually require this link, because an SL-C without documented development practice is hard to test. This link is a practical conclusion drawn from the two standards, not a normative statement of IEC 62443-3-3.
A second pillar for service and integration work is IEC 62443-2-4, which IEC 62443-3-3 references in its bibliography. IEC 62443-2-4 specifically addresses requirements for service providers. It adds the organizational framework for maintenance and commissioning to the system requirements of IEC 62443-3-3.
How to apply IEC 62443-3-3 in a project
When you apply IEC 62443-3-3 in a specific machine or plant project, this sequence has proven useful:
- Define zones and conduits under IEC 62443-3-2. Which asset groups share security requirements, and how must data flows be routed?
- Set the SL-T for each zone. For most machines and plants, practice recommends SL 2. Deviations are allowed but must be justified.
- Derive the SRs and REs for each SL. Annex B of the standard provides the full mapping.
- Document implementation and manage deviations. Document each implemented SR with the specific technical measure. Justify deviations and add compensating countermeasures.
- Bring in the neighboring parts. IEC 62443-4-1 for the development process, IEC 62443-2-4 for the service provider view, and IEC 62443-4-2 for the component level where needed.
If you take the standard seriously, you gain a structured technical catalog of requirements and a reliable line of argument toward the asset owner. You also gain a sound frame of reference for the CRA and the Machinery Regulation, which makes it much easier to argue on the basis of a harmonized standard later.
Book an initial call on IEC 62443-3-3
Planning a project under IEC 62443-3-3, or need to place the standard in the context of the CRA and the Machinery Regulation? In an initial call, we sort out where your project stands and which next steps make sense.
Further reading
- Pierre Kobes: Leitfaden Industrial Security: IEC 62443 einfach erklärt, 2nd, completely revised and expanded edition, VDE Verlag, Berlin/Offenbach 2025, ISBN 978-3-8007-5303-1 (in German).
- Pierre Kobes: Guideline Industrial Security, 4th revised edition, VDE Verlag, Berlin/Offenbach 2026, ISBN 978-3-8007-6389-4 (English edition).
- VDMA: Leitfaden Security für den Maschinen- und Anlagenbau: Der Weg durch die IEC 62443, January 2026 (in German).
