ISA/IEC 62443 defines four security levels, SL1 through SL4, based on the attacker capability each system, zone, or conduit is expected to withstand [S1][S2].
The levels progress from accidental or casual misuse at SL1 to intentional attacks by sophisticated adversaries with extended resources and high motivation at SL4 [S2][S4].
What IEC 62443 Security Levels Measure
An ISA/IEC 62443 Security Level is a measure of confidence that a system, zone, or conduit is free from vulnerabilities and performs the required security functions as specified [S2]. The series covers industrial automation and control systems, or IACS, across hardware, software, processes, preventive measures, personnel, and the system lifecycle [S1][S3].
The structure has four principal parts: general concepts, policies and procedures, system requirements, and component requirements [S5]. System requirements include security-level concepts and assessment methods, while component requirements address the security capabilities of devices, firmware, and software [S5].
Security levels are not a substitute for risk assessment. Asset owners select applicable requirements according to system risk and operational requirements, using zones and conduits to group assets with common cybersecurity needs and manage their communications [S3].
SL1 Protection Against Casual and Accidental Misuse
SL1 targets protection against casual or coincidental violations, including unintentional or accidental misuse by personnel, such as sending sensitive information to the wrong recipient [S3][S7]. The threat profile is non-malicious human error rather than a deliberate attack campaign [S6].
SL1 is appropriate where users and operators are generally trusted, mistakes are possible, and an attacker has no meaningful intent to bypass system controls. It does not provide the capability expected from a deliberately malicious insider or an external intruder using simple attack methods [S6][S7].
This level is not suitable as the sole control for exposed commercial-off-the-shelf industrial components. The ISA Security Compliance Institute recommends that such components target at least SL2, even though the standard defines SL1 with fewer requirements [S4].
SL2 Protection Against Simple Intentional Attacks
SL2 requires protection against intentional violation by a malicious attacker using simple means, few resources, and low motivation [S6][S8]. This is the first level that treats deliberate interference as the design threat, rather than assuming violations are accidental [S6].
For COTS industrial components, the ISCI analysis identifies SL2 as the minimum recommended target because it supplies capabilities needed for adequate security in that product class [S4]. Its foundational capability areas include identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability [S4].
SL2 therefore suits connected industrial equipment, remote administration paths, and shared IT and OT environments where low-effort attacks, credential misuse, unauthorized software, or manipulation of control information must be resisted. It is still not a match for adversaries with sophisticated tools, substantial resources, or sustained intent [S2][S4].
SL3 and SL4 Protection Against Sophisticated Attackers
SL3 addresses intentional attacks by sophisticated adversaries using sophisticated means and high motivation [S8]. The engineering distinction is the attacker’s capability, not the number of controls or the assurance evidence alone. A system claiming SL3 must meet the corresponding system security requirements and demonstrate the capabilities defined for that level [S1].
SL4 prescribes capabilities to protect components against attackers with extended resources and high motivation [S4]. It addresses the highest threat profile in the four-level scale, including adversaries capable of sustained, technically sophisticated intrusion rather than opportunistic abuse [S2][S4].
Neither SL3 nor SL4 should be selected merely because an asset is labeled critical. The appropriate target depends on the risk assessment, architecture, exposure, consequence, and the capabilities that can be sustained throughout the lifecycle [S3][S5].
Security-Level Comparison by Decision Criteria
SL1 addresses accidental human error, while SL2 adds resistance to deliberate attackers using simple means. SL3 assumes sophisticated means and high motivation, and SL4 adds attackers with extended resources and high motivation [S2][S6][S8].
The comparison also exposes a procurement mistake: a security level label does not establish that every zone, conduit, component, and supporting procedure satisfies the intended risk. The system, zone, conduit, and component scopes must be defined before conformance is assessed [S1][S2].
Choosing a Level for Industrial Control Systems
IEC 62443 is suitable for asset owners, system integrators, product suppliers, and certification bodies that need a common OT cybersecurity method [S3][S4]. Its zone-and-conduit model separates assets with common security requirements, while monitored conduits govern communication between those zones [S5].
It is not a complete operational safety case. IEC 62443 addresses cybersecurity for IACS, but cybersecurity controls do not replace functional-safety analysis, process-hazard assessment, or equipment-specific safety certification. Asset owners retain responsibility for system operation, security, and maintenance [S3].
SL2 is a defensible minimum for widely used COTS industrial control components, based on the ISCI recommendation for ISA/IEC 62443-4-2 product capability [S4]. Higher levels require a risk-based case showing why the adversary capabilities justify the additional implementation and lifecycle burden.
Implementation Limits and Failure Modes
A security-level target can fail operationally when authentication is shared, remote access is unrestricted, monitoring is absent, or security measures interfere with maintenance and safe operation. Layered defense requires technical controls, operating procedures, trained personnel, and continued risk review rather than a procurement label alone [S3][S5].
Legacy and proprietary equipment can limit the feasible target because component capabilities may not support modern authentication, integrity, or access-control requirements [S5]. For mixed plants, owners can assign different levels by zone and conduit, document the rationale, and define how weaker interfaces are monitored or isolated.
Security-level conformance also needs traceable evidence across identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response, and resource availability [S4]. Claims should identify the exact ISA/IEC 62443 part, target security level, assessed system scope, and any exclusions.
Verifying Claims and Budget Scope
A defensible IEC 62443 specification identifies the applicable standard part, security-level target, asset owner, asset owner’s requirements, implementation, and operational requirements. That structure connects the selected level to documented risk and prevents a generic statement such as “IEC 62443 compliant” from substituting for scope and evidence [S1][S3].
Budget decisions can then be tied to measurable work: zone identification, conduit assessment, component capability review, authentication design, logging, event response, resource availability, and periodic reassessment. For machine builders and integrators, the related analysis of IEC 62443 certification costs helps separate certification preparation from broader OT security investment.
The next trackable signals are the documented target level for each zone and conduit, the identified capability gaps by ISA/IEC 62443 part, and the evidence package used for assessment. Any increase in scope, exposure, or attack capability should trigger a documented risk review rather than an automatic assumption that every asset belongs at SL4 [S1][S5].