IEC 62443-3-3 system requirements explained

This guide shows how the standard is structured, how asset owners and integrators work with it and how to find the gap between target and capability for each zone. The examples are invented.

What IEC 62443-3-3 covers

IEC 62443-3-3 belongs to the "system" group of the series. The current edition dates from 2013 and has the same content as ANSI/ISA-62443-3-3-2013. It looks at the control system as a whole, not at the single device.

IEC 62443-3-2 comes first. The risk assessment partitions the plant into zones and conduits and sets a target security level (SL-T) for each zone.
IEC 62443-3-3 translates that target into concrete technical requirements for the system.
For single components IEC 62443-4-2 applies. A certificate for a device therefore does not tell you which level the system reaches.

The standard does not require specific products. How you meet it, with component functions, measures at the zone boundary or organizationally, is your decision.

Structure: from foundational requirement to enhancement

The standard has three levels:

Foundational requirements (FR). Seven foundational requirements form the top level.
System requirements (SR). Each FR contains several system requirements, numbered like "SR 5.2" for the second SR in FR 5.
Requirement enhancements (RE). Enhancements tighten an SR and apply from a certain security level.

The table shows the distribution. The counts follow the numbering of the 2013 edition, the questions in the last column are our own translation into practice.

FR	Foundational requirement	SR	RE	Question for the plant
FR 1	Identification and authentication control	13	11	Do we know who or what is logging in?
FR 2	Use control	12	12	Is this person or device allowed to do this, and is it logged?
FR 3	System integrity	9	10	Do programs, data and communication stay unchanged?
FR 4	Data confidentiality	3	3	Are recipes and credentials protected?
FR 5	Restricted data flow	4	7	Does only permitted traffic flow between zones?
FR 6	Timely response to events	2	1	Do we notice anomalies in time?
FR 7	Resource availability	8	5	Does the plant keep running under load, and can it be restored?
Total		51	49

How the security level sets the requirements

The security level applies per FR. For an SL-T 2 in FR 5, all SRs of FR 5 must be met, plus the enhancements the standard assigns to SL 2. The mapping is in Annex B of the standard.

Taking the zone boundary, SR 5.2, as an example, in our own words:

SL 1: The boundary between zones is monitored and controlled.
SL 2: In addition, "deny by default, allow only what is needed" applies (RE 1).
SL 3: In addition, the zone can be cut off from the outside (RE 2), and if the boundary fails it closes instead of letting everything through (RE 3).

Two points are worth knowing:

Some SRs only apply from SL 2, for example SR 1.8 (use PKI certificates), SR 6.2 (continuous monitoring) and SR 7.8 (control system component inventory). SR 2.7 and SR 2.12 only apply from SL 3.
Enhancements build on each other. An RE from SL 2 also applies at SL 3 and SL 4.

A higher level therefore means a concrete, verifiable list of additional functions.

Who uses the standard and how

The same standard has a different task for each role:

Asset owner. Sets and approves the SL-T for each zone. With IEC 62443-3-3, the asset owner checks whether the existing plant reaches the target and plans measures for the gaps.
Integrator. Implements the SL-T in the system design: selects components with a suitable capability (SL-C), plans zone boundaries, documents the configuration and proves the result in FAT and SAT. The integrator's own requirements are in IEC 62443-2-4.
Supplier of a system. States which SL-C the system reaches per FR when it is configured correctly.

Important for working together: the SL-T is a requirement of the asset owner. The SL-C is a capability. What the plant actually achieves (SL-A) only shows in the check on site. More on this in the guide "Security levels in IEC 62443".

The gap per zone in six steps

Take over the SL-T per zone and FR. The basis is the approved risk assessment under IEC 62443-3-2. One value per zone is often enough; for important zones a value per FR is worth it.
Select the requirements. Each zone needs all SRs and the REs up to its SL-T. Mark anything above as not required, with a justification.
Determine the SL-C. Use vendor statements, certificates and security manuals. For legacy systems without statements, check yourself, for example whether an operator panel supports personal accounts.
Assess the state. Record for each requirement: applicable or not, implementation status, evidence. Without evidence a requirement counts as not met in an audit.
Compensate where needed. If a system cannot meet a requirement, the standard provides for compensating countermeasures, for example a tight rule at the zone boundary. Note which SR the measure replaces and until when it applies.
Plan the measures. Every open gap becomes a task with an owner and a date.

Assess the zone as a whole, not every device on its own. What counts is whether the zone meets the requirement, if necessary through measures at its boundary.

Example from production

The example is invented. A maker of plastic parts has an integrator build a new injection molding line. The risk assessment gives the zone "Line 4" an SL-T 2 in all FRs. The integrator designs to IEC 62443-3-3 and hands over a list of components with their SL-C.

The joint check before acceptance shows four gaps:

SR 1.1, RE 1 (unique identification): The operator panel supports personal accounts, but a group account is set up. The accounts are activated; no investment is needed.
SR 5.2, RE 1 (deny by default, allow only what is needed): The zone boundary still has an open rule from commissioning. It is replaced by rules for the connections actually needed.
SR 7.3, RE 1 (verify backups): Backups of the control programs exist, but a restore was never tested. A test before acceptance goes into the plan.
Legacy controller from Line 3: A device taken over from the old line has no login. The zone boundary allows write access only from the engineering workstation, and program changes follow the four-eyes principle until the device is replaced.

Result: the asset owner accepts the line with a documented remaining plan, backed by evidence.

Zones page of the demo company with the target security level and the gap per zone and foundational requirement — SL gap per zone and foundational requirement: target and achieved level at a glance (sample project).

Common mistakes

Reading a component certificate as system evidence. An SL-C under IEC 62443-4-2 says nothing about the configuration and architecture of the plant.
Ticking off enhancements across the board. What counts is the SL-T of each zone and FR, not an average.
"Partially implemented" without explanation. Describe what is missing. That is exactly the measure later.
Functions available but switched off. Many gaps exist because existing functions are not enabled.
Compensation without end. Substitute measures need a plan for their replacement.

Laws and standards together

IEC 62443-3-3 is a standard, not a law. It becomes binding through a contract, a tender or a customer requirement. For entities in the scope of NIS2 it still matters: under § 30(2) sentence 1 BSIG (German BSI Act), risk management measures should comply with the state of the art and take the relevant European and international standards into account. For control technology, IEC 62443 is such a standard.

Checklist

The SL-T per zone, and per FR where needed, is approved
For each zone it is defined which SRs and REs apply
Enhancements that are not required are marked with a justification
SL-C statements from vendors and integrators are available
Legacy systems without statements are checked in-house
Every requirement has a status and evidence
Compensating measures name the replaced SR and an end date
Every gap is a task with an owner

IEC 62443-3-3 in Complass

A spreadsheet with 100 rows per zone is quickly built and quickly out of date. With the IEC 62443 module booked, asset owners and integrators work on the same state in Complass:

Two catalogs. You assess the 51 system requirements and the 49 enhancements with applicability, status, evidence and owners.
Level filter. With "Not required at SL-T 2" and bulk editing you mark all enhancements above your target in one step, with a justification.
Implementation guide. For each requirement it names the goal, steps, typical evidence and frequent findings. You take a step over into the action plan as a task.
Gap per zone. In the network plan you see the SL-T for each zone and FR and the level achieved from the SL-C values of the assets. Measure for the gap creates a task directly.
Roles. You create projects as asset owner or as integrator; both share zones and inventory.

The standard texts are not included, because standards are protected by copyright. The requirements are described in our own words, with their number as a reference.

Frequently asked questions

Do we have to meet all 51 system requirements?

No, not across the board. Which SRs and REs apply depends on the SL-T of the zone per FR. Some requirements also do not apply in a zone, for example SR 1.6 on wireless access in a zone without radio. Record the justification.

What is the difference between IEC 62443-3-3 and IEC 62443-4-2?

IEC 62443-3-3 sets requirements for the system, IEC 62443-4-2 for the single component, such as a controller or a switch. Both use the same seven foundational requirements.

Who is responsible for meeting the requirements?

The asset owner sets the target and carries the risk. The integrator implements the design and proves it, the supplier provides the statements on the capability of its products. Put the split in writing for each plant.

Can we assess existing plants against 3-3 at all?

Yes. That is exactly where the check shows which existing functions only need to be switched on and where compensating measures are needed until replacement.

Do we need the standard itself?

Yes. For an assessment that holds up in an audit, you need the wording from your licensed edition. The table of contents of the ISA version is freely available and gives a first overview.

In a demo we show you with the demo company how the SL-T of a zone becomes an assessed list of requirements and an action plan.

Request a demo Try it for 14 days

Sources

IEC 62443-3-3:2013, System security requirements and security levels (IEC Webstore)
ANSI/ISA-62443-3-3-2013, freely available table of contents (ISA)
§ 30 BSIG (German BSI Act), risk management measures of particularly important and important entities
BSI, ICS Security Compendium

Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The current wording of the BSIG and your licensed edition of the standard are authoritative. As of November 2026.