What is IEC 62443-3-3?
IEC 62443-3-3 is the international standard in the IEC 62443 series that sets out the technical security requirements a complete industrial automation and control system (IACS) must meet, linked to four security levels (SL). It contains 51 system requirements (SR), grouped under seven foundational requirements, and applies to systems such as a SCADA environment, a DCS or a set of PLCs with HMIs and servers. With IEC 62443-3-3, vendors, integrators and asset owners can state unambiguously which security level a system can technically achieve in industrial automation.
🧠 What exactly does IEC 62443-3-3 cover?
IEC 62443-3-3 was published in August 2013 as edition 1.0, with a corrigendum issued in April 2014. CENELEC adopted the text unchanged in 2019 as EN IEC 62443-3-3:2019, which in the Netherlands is available through NEN. Edition 1 is still the current version. The IEC has set 2027 as its stability date: until then the text is, in principle, left unchanged.
The standard looks at the system as a whole: the combination of servers, workstations, network and controllers within a zone. For each requirement it specifies the security level from which it applies. This produces the SL-C (capability): the level the system can reach with its built-in functions.
Two principles run through the entire standard:
- Essential functions come first - security must never cause a loss of protection with consequences for health, safety or the environment. An account lockout after failed logins must not, for example, prevent an operator from reaching an emergency stop, and authentication must not delay the initiation of a safety function.
- Compensating countermeasures are allowed - if the system cannot meet a requirement itself, an external component may do so, such as a firewall or a central SIEM. That choice follows the risk assessment in IEC 62443-3-2.
🔧 Which seven foundational requirements does the standard contain?
The 51 system requirements are grouped under the seven foundational requirements (FR) defined in IEC 62443-1-1:
| FR | Name | Number of SRs | Example system requirements | Typical measures |
|---|---|---|---|---|
| FR 1 | Identification and authentication control (IAC) | 13 | SR 1.1 human user authentication, SR 1.7 password strength, SR 1.13 access via untrusted networks | User-Based Access Control, MFA, unique user accounts |
| FR 2 | Use control (UC) | 12 | SR 2.1 authorisation enforcement, SR 2.5 session lock, SR 2.8 auditable events, SR 2.12 non-repudiation | Least Privilege, RBAC, Logging |
| FR 3 | System integrity (SI) | 9 | SR 3.1 communication integrity, SR 3.2 malicious code protection, SR 3.4 software and information integrity | Whitelisting, Application Control, Antivirus |
| FR 4 | Data confidentiality (DC) | 3 | SR 4.1 information confidentiality, SR 4.2 information persistence, SR 4.3 use of cryptography | Encryption of traffic, passwords and data |
| FR 5 | Restricted data flow (RDF) | 4 | SR 5.1 network segmentation, SR 5.2 zone boundary protection | Network segmentation, Protocol Filtering, Firewalls |
| FR 6 | Timely response to events (TRE) | 2 | SR 6.1 audit log accessibility, SR 6.2 continuous monitoring | Anomaly detection, Security Monitoring, SIEM, Incident Response |
| FR 7 | Resource availability (RA) | 8 | SR 7.1 DoS protection, SR 7.3 control system backup, SR 7.7 least functionality, SR 7.8 component inventory | Protection against DDoS, backups, redundancy, High Availability |
What is notably absent: patch management is not a system requirement in 3-3. It is covered by IEC TR 62443-2-3 and by the process standards for asset owners and service providers. SR 3.4 does, however, require software integrity checks, which matter directly when you install patches.
📊 How do security levels and requirement enhancements work?
Each system requirement has a base text and often one or more requirement enhancements (RE) that only become mandatory at a higher level. Annex B of the standard maps every SR and RE to SL 1 to 4. The levels are defined in terms of the attacker:
| SL | Protects against | Example SR 1.1 (human user authentication) |
|---|---|---|
| SL 1 | Casual or coincidental violation | Users are identified and authenticated |
| SL 2 | Intentional violation using simple means, low resources, generic skills and low motivation | Plus: every user uniquely identifiable (RE 1) |
| SL 3 | Intentional violation using sophisticated means, IACS-specific skills, moderate resources and motivation | Plus: MFA for access via untrusted networks (RE 2) |
| SL 4 | Intentional violation using sophisticated means, IACS-specific skills, extended resources and high motivation, for example by state actors | Plus: MFA for all networks (RE 3) |
Most base requirements already apply at SL 1, but not all. For example, SR 1.2 (software process and device authentication), SR 1.8 (PKI certificates), SR 3.9 (protection of audit information), SR 4.2 (information persistence), SR 6.2 (continuous monitoring) and SR 7.8 (component inventory) are only required from SL 2. SR 2.7 (concurrent session control) and SR 2.12 (non-repudiation) only come into play at SL 3.
A security level is also not a single number but a vector with one value per FR, in the order IAC, UC, SI, DC, RDF, TRE, RA. A zone might, for example, receive SL-T = {2 2 2 1 3 2 3}: strict on data flows and availability, light on confidentiality. That fits OT, where availability usually weighs more heavily than secrecy.
| Term | Meaning | Who determines it? |
|---|---|---|
| SL-T (target) | Required level per zone or conduit | Asset owner, via IEC 62443-3-2 |
| SL-C (capability) | Level the system can achieve | Vendor or integrator, via 3-3 |
| SL-A (achieved) | Level actually achieved in practice | Verification after configuration and commissioning |
🏭 What does IEC 62443-3-3 look like in an OT installation?
| Component | Examples of 3-3 requirements |
|---|---|
| SCADA server and HMI | Individual accounts (SR 1.1), roles per operator (SR 2.1), system-wide audit trail with timestamps (SR 2.8, SR 2.11) |
| PLC and controllers | Authentication of devices and software processes (SR 1.2), communication integrity (SR 3.1), disabling unused ports and services (SR 7.7) |
| Historian | Encrypted traffic towards the office zone (SR 4.1, SR 4.3), protection against overload (SR 7.1) |
| Engineering Station | Application whitelisting against malware (SR 3.2), restricting USB media (SR 2.3), permission management via RBAC (SR 2.1) |
| Zone boundary | Deny-by-default rules (SR 5.2 RE 1), segmentation of critical networks (SR 5.1) |
SR 5.2 also shows the standard’s caution: at higher levels a zone boundary may switch to island mode or close on failure (fail close), but never in a way that obstructs a safety instrumented system.
🔄 How does 3-3 relate to the other parts of IEC 62443?
- IEC 62443-1-1 - provides the terminology and the seven foundational requirements.
- IEC 62443-3-2 - uses a risk assessment to define zones, conduits and the SL-T; 3-3 then supplies the requirements to reach that level.
- IEC 62443-4-2 - translates the system requirements to individual components (the SL-C of a single PLC or switch).
- IEC 62443-4-1 - describes the vendor’s secure development process.
- IEC 62443-2-4 - sets requirements for the integrator who builds and maintains the system.
A system can be certified through ISASecure SSA (System Security Assurance). This requires meeting the 3-3 system requirements for the claimed security level as well as the development process of 4-1, assessed by an accredited certification body. Sector frameworks also build on 3-3: NAMUR Open Architecture bases the protection profiles in NE 177 on the security levels from this standard.
🧭 How do you apply IEC 62443-3-3 step by step?
- Inventory the system - record which assets, networks and connections fall within scope.
- Divide it into zones and conduits using the Zones and Conduits Model and a risk assessment in line with IEC 62443-3-2.
- Set the SL-T vector per zone; in practice SL 2 is often the baseline, with SL 3 common for critical zones and remote access.
- Request the SL-C from the vendor or integrator, per FR, and compare it with the SL-T.
- Close the gaps with compensating countermeasures, such as an industrial firewall, a jump server or central logging.
- Verify the SL-A after handover with a configuration review or penetration test, and repeat this after major changes.
For Dutch organisations this is no longer theory. The Dutch Cybersecurity Act (Cyberbeveiligingswet) has been in force since 15 August 2026 and requires appropriate measures for network and information systems, including OT. IEC 62443-3-3 is a recognisable way to demonstrate this for control systems. Product manufacturers also face the Cyber Resilience Act, which applies in full from 11 December 2027.
✅ What are the benefits of implementation?
- Measurable technical requirements - you can specify in a tender exactly which SRs and REs you expect.
- Support for Defense in Depth - the seven FRs cover identity, integrity, data flows and availability.
- Applicable per zone - you do not have to bring the entire plant to the same level.
- Alignment with other frameworks - supports compliance with NIS2, ISO 27001 and the NIST CSF.
❓ Frequently asked questions
How many requirements does IEC 62443-3-3 contain?
IEC 62443-3-3 contains 51 system requirements, grouped under seven foundational requirements. In addition, many of those requirements have requirement enhancements that apply only at higher security levels. The more enhancements a system fulfils, the higher the security level it can achieve.
Is IEC 62443-3-3 mandatory?
IEC 62443-3-3 is not legally mandatory as a standard. Laws such as NIS2 and the Dutch Cybersecurity Act do require appropriate security measures, and IEC 62443-3-3 is a common way to demonstrate those for industrial control systems. Many asset owners therefore include the standard in their procurement terms.
What is the difference between IEC 62443-3-3 and IEC 62443-3-2?
IEC 62443-3-2 describes how you use a risk assessment to divide a system into zones and conduits and determine the required security level (SL-T) for each zone. IEC 62443-3-3 describes which technical requirements a system must meet to reach a given security level. The two standards are therefore almost always used together.
Who is IEC 62443-3-3 intended for?
IEC 62443-3-3 is primarily intended for vendors and integrators who design and build industrial control systems. Asset owners use the standard to set requirements in tenders and to verify delivered systems. Auditors and certification bodies also work with the system requirements from this standard.
Can a system be certified against IEC 62443-3-3?
A control system can be certified against IEC 62443-3-3, for example through the ISASecure SSA programme. An accredited body then assesses the 3-3 system requirements for the claimed security level together with the development process according to IEC 62443-4-1. The certificate states the security level the system is capable of, not the level of your own installation.
What is a security level vector in IEC 62443-3-3?
A security level vector in IEC 62443-3-3 is a series of seven numbers, one per foundational requirement, that together describe the security level of a zone or system. This allows a zone to be strict on data flows and availability and less strict on confidentiality. As a result, the level matches the actual risk more closely.
📌 In summary
IEC 62443-3-3 uses 51 system requirements and four security levels to define which technical protection an industrial control system must provide as a whole. Together with the risk assessment from IEC 62443-3-2 and the component requirements from IEC 62443-4-2, the standard forms the technical backbone for protecting OT systems, without security coming at the expense of safety and availability.