IEC 62443-3-3: Complete 2026 Guide to 51 System Requirements

IEC 62443-3-3 is the part of the IEC 62443 series that defines what a secure industrial control system must be able to do. It sets out 51 system requirements (SRs) grouped under 7 foundational requirements (FRs), and many SRs carry requirement enhancements that switch on as the security level rises from SL 1 to SL 4.

The current version is IEC 62443-3-3:2013, Edition 1.0, published on 7 August 2013, with a corrigendum issued in April 2014. No newer edition has been published, so if a bid document quotes a “2024 version” of Part 3-3, ask for the reference.

This guide covers the FR and SR structure, how security levels attach to requirements, SL-C versus SL-T, who uses Part 3-3, ISASecure SSA certification, and the mistakes we see most in specifications.

What IEC 62443-3-3 covers (and what it does not)

Part 3-3 is a system-level technical standard. It describes the security capabilities of an integrated control system: authentication, authorization, integrity, confidentiality, segmentation, monitoring and availability. It does not describe how an asset owner runs a security program (that is 2-1), how service providers work (2-4) or how a supplier develops products (4-1). For the full map, see our IEC 62443 parts explained guide.

Before any SR, clause 4 sets three common constraints that shape every requirement:

• Support of essential functions. Security measures must not get in the way of the functions the process depends on, such as safety functions and the operator’s ability to see and control the plant.
• Compensating countermeasures. When a system cannot meet a requirement natively, an external measure can cover the gap, provided it is designed and documented.
• Least privilege. Users, accounts and processes get only the access their role needs.

In Europe the standard is adopted as EN IEC 62443-3-3:2019. The official IEC webstore listing for Part 3-3 confirms the edition and the corrigendum.

The 7 IEC 62443 foundational requirements and 51 system requirements

The seven FRs come from IEC 62443-1-1, and Part 3-3 breaks each into numbered SRs. The counts are uneven: identification and use control hold 25 of the 51 SRs, while timely response to events has only two.

FR	Name	SRs	Practical example
FR 1	Identification and authentication control (IAC)	13	Named accounts for every operator and engineer instead of a shared “operator” login; monitored and controlled access from untrusted networks (SR 1.13)
FR 2	Use control (UC)	12	Role-based authorization so an operator can acknowledge alarms but cannot download controller logic; auditable events with reliable timestamps (SR 2.8, SR 2.11)
FR 3	System integrity (SI)	9	Malicious code protection on engineering workstations (SR 3.2); integrity protection for control traffic (SR 3.1)
FR 4	Data confidentiality (DC)	3	Encrypting historian data that leaves the zone; clearing configuration and credentials from retired devices (SR 4.2)
FR 5	Restricted data flow (RDF)	4	Separating control and business networks (SR 5.1) and enforcing deny-by-default rules at zone boundaries (SR 5.2)
FR 6	Timely response to events (TRE)	2	Audit logs that security staff can actually reach (SR 6.1) and continuous monitoring (SR 6.2)
FR 7	Resource availability (RA)	8	Tested backup and recovery (SR 7.3, SR 7.4); disabling unused ports and services (SR 7.7); a component inventory (SR 7.8)
Total	7 FRs	51	Plus requirement enhancements attached to many SRs

Note that several SRs sound like policy topics but are system capabilities: SR 7.8 Control system component inventory is about what the system can report on its installed components, not whether someone keeps a spreadsheet. The FR numbering also carries over into IEC 62443-4-2, so component requirement CR 5.1 lines up with SR 5.1.

How security levels work with SRs and requirement enhancements

Every SR has a base requirement. Many also have one or more requirement enhancements (REs) that add strength or scope. The standard then shows, for each SR, which combination of base requirement and REs a system needs to claim capability at SL 1, 2, 3 or 4.

SR 1.1 Human user identification and authentication is the classic example. The base requirement applies at every level. Enhancements add unique identification of each user, then multifactor authentication on untrusted networks, and only at SL 4 multifactor authentication on all networks.

How to read an IEC 62443-3-3 SL mapping

• Not every SR applies at SL 1. Some, such as SR 4.2 Information persistence, carry no requirement until a higher level.
• Levels build on each other. A higher level keeps the lower-level requirement and adds REs.
• Levels are set per FR. The standard expresses capability as SL-C(IAC), SL-C(UC) and so on, and a zone’s target can likewise be expressed as seven values rather than one number.

Behind each number is an attacker profile. SL 1 protects against casual or coincidental violation; SL 2 against intentional violation using simple means, low resources and generic skills; SL 3 against sophisticated means with IACS-specific skills and moderate resources; SL 4 against the same skills backed by extended resources and high motivation. Our guide to IEC 62443 security levels covers the definitions in depth.

SL-C of a system vs SL-T of a zone in IEC 62443-3-3

Many explainers skip this distinction, yet it drives most procurement conversations.

• SL-T (target) belongs to a zone or conduit. The asset owner sets it through the IEC 62443-3-2 risk assessment and records it in the Cybersecurity Requirements Specification (ZCR 6.1).
• SL-C (capability) belongs to the system or component. It is what the system can deliver natively, when properly configured, without additional compensating countermeasures.
• SL-A (achieved) is what the installed, operating zone actually delivers. It depends on configuration, maintenance and people, not only on the product.

The real work is a comparison, FR by FR. Say a packaging line zone has an SL-T of 2 in most FRs but 3 in restricted data flow, because a vendor remote access path terminates there. A system with SL-C 2 in FR 5 leaves a gap.

You then have three options: add a compensating countermeasure such as a stricter boundary device in the conduit, select a system with higher capability in that FR, or document the residual risk and get asset owner approval. Either way, record the gap and its treatment against the zone.

Who uses IEC 62443-3-3 system requirements

• Asset owners writing specifications. The strongest specifications state the SL-T per zone and per FR, reference the SRs, and ask bidders to respond requirement by requirement with any deviations and proposed compensating countermeasures.
• System integrators. They design and configure the solution to meet the specified SRs, then produce the evidence: hardening records, test results and a compliance matrix. Their own service processes fall under 2-4.
• Product suppliers of systems. DCS, SCADA and other control platform suppliers design reference architectures to a declared SL-C per zone, and some certify them through ISASecure.

ISASecure SSA certification for control systems

The ISASecure System Security Assurance (SSA) program certifies a control system: an integrated set of more than one component, supported as a whole by a single supplier and kept under configuration control. Under SSA version 4.0.0, the scope covers all control system requirements in 3-3 and all process requirements in 4-1, assessed through four elements:

• Security development lifecycle process assessment (SDLPA-S)
• Security development artifacts review (SDA-S)
• Functional security assessment (FSA-S), applied zone by zone
• Vulnerability identification testing (VIT-S)

The supplier chooses a capability level for each zone. Certification applies to a specific system version and layout (or set of layouts), and the certificate names the security zones and their certified capability levels. Assessments are carried out by ISO/IEC 17065-accredited certification bodies, and ISASecure publishes a list of certified systems. Details are on the ISASecure SSA certification page.

When a bidder cites SSA, check that the certified version and layout match what you are buying and that the certified zone levels cover your SL-T. SSA certifies a supplier’s system, not your plant. For an operating IACS, ISASecure’s ACSSA program assesses against 2-1, 2-4, 3-2 and 3-3, and its version 1.0.0 took effect on 17 February 2026.

How Part 3-3 relates to 3-2 and 4-2

Think of the three parts as a chain from risk to product:

1. IEC 62443-3-2 partitions the system under consideration into zones and conduits, assesses risk and sets an SL-T for each.
2. IEC 62443-3-3 turns that SL-T into capabilities the integrated system must deliver.
3. IEC 62443-4-2 sets component requirements (CRs) under the same seven FRs, with specific prefixes for software applications (SAR), embedded devices (EDR), host devices (HDR) and network devices (NDR).

The chain does not run automatically. A system assembled from 4-2 certified components does not automatically reach the same SL-C at system level; architecture, integration and conduits decide what the system can do. Conversely, a capability gap in one component can be covered when another element of the design provides it and is documented as a compensating countermeasure. Our IEC 62443-4-2 component requirements guide covers the component side.

Common IEC 62443-3-3 mistakes

• Asking for SL 3 everywhere. A blanket SL 3 specification ignores the risk assessment, rules out legacy equipment you may have no reason to replace and, in our experience, produces long deviation lists from every bidder. Set SL-T per zone and per FR, and reserve SL 3 for the places where the risk justifies it.
• Treating SL as a single number. “An SL 2 system” hides the detail. Ask for SL-C per FR and compare it with your SL-T for each zone.
• Confusing SL-C with SL-A. A capable system shipped with default accounts and open services achieves far less than its rating. Verify the configuration at factory and site acceptance testing.
• Locking out operators. Copying IT-style account lockout onto an operator console can conflict with the essential-functions constraint. Consider compensating controls such as physical access control for the control room.
• Undocumented compensating countermeasures. If a firewall rule or procedure covers an SR gap, record which SR, which zone and who approved it, or the gap resurfaces at the next audit.
• Using Part 3-3 to audit the security program. It tests system capabilities. Policies, training and incident management sit under 2-1.

If you are the asset owner setting SL-T values and checking bids against them, the IEC 62443 Toolkit ($149) supplies the documented layer: 117 editable templates (82 Word, 35 Excel) written against IEC 62443-2-1:2024, including a target security level register, an SL-T/SL-C/SL-A gap workbook, and 3-2 risk assessment and CRS templates. It is built for asset owners and service providers. Part 3-3 appears as a cross-reference in its mapping workbook rather than as a full SR checklist, and like any document set it cannot certify anyone.

IEC 62443-3-3 FAQs

Is IEC 62443-3-3:2013 still the current edition?

Yes. Edition 1.0, published on 7 August 2013 and incorporating the April 2014 corrigendum, is the edition IEC currently sells. No newer edition has been published.

How many requirements are in IEC 62443-3-3?

There are 51 system requirements across 7 foundational requirements, and many SRs add requirement enhancements at higher levels. How many apply to you depends on each zone’s SL-T per FR, so the practical count varies by zone.

Can our plant be certified to Part 3-3?

Not through SSA, which certifies a supplier’s control system rather than an installed site. ISASecure’s ACSSA program is the route for an operating IACS: it assesses 2-1, 2-4, 3-2 and 3-3 together. Both are voluntary.

What is the difference between Part 3-3 and 4-2?

Part 3-3 sets requirements for an integrated system; 4-2 sets requirements for the individual components inside it. Both use the same seven FRs and express capability as SL-C, so you can trace a system requirement down to the components that deliver it.