IEC 62443-3-3: system security requirements and security levels, explained

IEC 62443-3-3 (published as ANSI/ISA-62443-3-3 in August 2013, and as IEC 62443-3-3 the same year) is the part of the ISA/IEC 62443 series that sets detailed technical security requirements at the control-system level — distinct from the component-level requirements in 62443-4-2 and the secure-development-process requirements in 62443-4-1. Its own scope clause states it "provides detailed technical control system requirements (SRs) associated with the seven foundational requirements (FRs) described in ISA-62443-1-1... including defining the requirements for control system capability security levels, SL-C (control system)." This guide works from that scope text and the standard's own introduction, which ISA publishes as a free preview, rather than from third-party paraphrases.

The seven foundational requirements

62443-3-3's scope clause restates the seven FRs from ISA-62443-1-1 verbatim, and every detailed system requirement (SR) in the standard is organized under one of them:

#	Foundational requirement	Abbreviation
FR1	Identification and authentication control	IAC
FR2	Use control	UC
FR3	System integrity	SI
FR4	Data confidentiality	DC
FR5	Restricted data flow	RDF
FR6	Timely response to events	TRE
FR7	Resource availability	RA

The standard's own text frames these as the foundation for control system capability SLs, SL-C(control system) — "defining security capability at the control system level is the goal and objective of this document." The exact count and numbering of individual SRs and requirement enhancements (REs) under each FR sits behind the paywalled clause text; any specific SR/RE count you see quoted elsewhere (including per-FR totals) should be treated as a third-party summary until checked against the purchased standard.

SL-T, SL-C and SL-A: three different uses of "security level"

The single word "level" in IEC 62443 covers three distinct concepts, and the standard is explicit about keeping 62443-3-3's own scope to just one of them. Its scope clause states plainly: defining SL-C(control system) "is the goal and objective of this document as opposed to target SLs, SL-T, or achieved SLs, SL-A, which are out of scope."

Term	What it measures	Where it is defined	Applies to
SL-T (Target)	The security level an asset owner decides a zone or conduit needs, based on risk assessment	ISA-62443-3-2	A zone or conduit
SL-C (Capability)	The security level a system or component can natively provide when properly integrated and configured	ISA-62443-3-3 (systems) / ISA-62443-4-2 (components)	A system or component
SL-A (Achieved)	The security level an installed system actually delivers, including any compensating countermeasures	Verified during design, certification testing or post-installation audit	A deployed zone or conduit

The standard's own clause 1.2 spells out how these interact in practice: "System integrators, product suppliers and service providers will use this document to evaluate whether their products and services can provide the functional security capability to meet the asset owner's target security level (SL-T) requirements," and where a design can't meet an SR natively, "compensating countermeasures can be employed... such that the overall SL-T requirements are met at the control system level," provided that "inclusion of compensating countermeasures during the design phase should be accompanied by comprehensive documentation so that the resulting achieved control system SL, SL-A(control system), fully reflects the intended security capabilities inherent in the design."

Where 62443-3-3 sits in the series

ISA's own series diagram, reproduced in 62443-3-3's introduction, groups the series into four layers:

Group	Parts
General	1-1 Terminology, concepts and models · 1-2 Master glossary of terms and abbreviations (TR) · 1-3 System security compliance metrics · 1-4 IACS security lifecycle and use-case (TR)
Policies & procedures	2-1 Requirements for an IACS security management system · 2-2 Implementation guidance for an IACS security management system (TR) · 2-3 Patch management in the IACS environment (TR) · 2-4 Installation and maintenance requirements for IACS suppliers
System	3-1 Security technologies for IACS (TR) · 3-2 Security levels for zones and conduits · 3-3 System security requirements and security levels
Component	4-1 Product development requirements · 4-2 Technical security requirements for IACS components

The standard's own clause 1.3 describes how the adjacent parts consume it: ISA-62443-3-2 "uses the SRs and REs as a checklist" — after a system under consideration is divided into zones and conduits with assigned target SLs, the SRs and REs from 62443-3-3 "are used to compile a list of requirements which the control system design needs to meet," and a completed design "can then be checked for completeness, thereby providing the SL-As." ISA-62443-4-1 "addresses the overall requirements during the development of products," deriving its product security requirements "from the list of baseline requirements and REs specified in" 62443-3-3. ISA-62443-4-2 "contains sets of derived requirements that provide a detailed mapping of the SRs specified in" 62443-3-3 "to subsystems and components of the SuC" — embedded devices, host devices, network devices and applications. See IEC 62443-4-2 vs the Cyber Resilience Act and EN 18031 for how that component-level mapping plays against EU device law, and IEC 62443-4-1: secure development lifecycle for the process side.

The four security levels, in general terms

The standard's publicly available scope and introduction clauses don't reproduce the numeric SL1-4 definitions themselves (that detail sits further into the paywalled text). Independent technical overviews of the standard, including a Cisco engineering white paper on ISA/IEC 62443-3-3, describe the four capability levels consistently as a progression in attacker sophistication and resourcing:

Level	General description (per Cisco's public 62443-3-3 overview)
SL 1	Protection against casual or coincidental misuse
SL 2	Protection against intentional misuse "using simple means, low resources, generic skills, and low motivation"
SL 3	Protection against intentional misuse "using sophisticated means, moderate resources, specific skills, and moderate motivation"
SL 4	Protection against intentional misuse "using sophisticated means, extensive resources, specific skills, and high motivation"

Treat the exact wording of these four levels as a secondary-source paraphrase rather than a verbatim standard quote — to confirm the official text, check it against the purchased ISA-62443-3-3 or IEC 62443-3-3 document.

Certification: ISASecure SSA

IEC 62443-3-3 is not self-certifying; an accredited body has to test and attest to it. The ISA Security Compliance Institute's System Security Assurance (SSA) program states its "FSA-S requirements for certification include all requirements in ISA/IEC 62443-3-3" together with the process requirements of ISA/IEC 62443-4-1, and that "the capability security levels for the FSA-S evaluation of a security zone within a system align with the ISA/IEC 62443-3-3 capability security levels and associated requirements." A system is submitted for SSA certification as one or more security zones, with a declared target capability level per zone; the resulting certificate states the SL-C the certifier confirmed for each zone — it does not, by itself, prove the SL-T an asset owner needs has been met across a whole installed plant.

Practical use for machine and system builders

1. Don't conflate SL-C with SL-T. A product supplier can honestly claim SL-C 2 for a component; that says nothing about whether SL-T 2 is actually the right target for the zone it will sit in — that call belongs to the asset owner's own risk assessment under 62443-3-2.
2. Use the seven FRs as your evidence index, not a checklist to tick once. Authentication, use control, integrity, confidentiality, data-flow restriction, event response and availability map cleanly onto most existing security-engineering documentation; organize what you already have under these seven headings before buying a gap assessment.
3. Expect compensating countermeasures to need paperwork. If a control system can't meet an SR natively, the standard explicitly expects documented compensating measures, not a silent gap, to get from SL-C to a credible SL-A.
4. Treat SR/RE counts and clause-level text from blogs and vendor pages as unverified until checked against the standard you've actually purchased — this guide only states what ISA's own free preview and series overview confirm.

SoftWSP maps a control system's existing security evidence against the seven 62443-3-3 foundational requirements and flags where compensating countermeasures need documentation before a certification or CRA conformity assessment: see machine builders.

This guide quotes ISA's publicly available preview of ISA-62443-3-3 and ISA-62443-1-1; it is not a substitute for the purchased standard and does not constitute legal or compliance advice.