IEC 62443-3-3 defines system security requirements for an integrated IACS, while IEC 62443-4-2 defines technical security requirements for individual components.
The practical distinction is scope: 3-3 controls the architecture and operation of the whole system, whereas 4-2 evaluates what a controller, I/O module, gateway, or other component must provide.
System Requirements and Component Requirements Compared
IEC 62443-3-3 covers system security requirements and security levels, while IEC 62443-4-2 covers technical security requirements for IACS components [S1][S3][S4]. A compliant product under 4-2 does not establish that the completed plant is secure, and system compliance under 3-3 does not prove that every purchased component meets the required capability.
The comparison is straightforward: use 3-3 to define and verify the integrated system, and use 4-2 to define and verify product capabilities. IEC 62443-3-3 organizes system security requirements into 7 Foundational Requirements, with each Foundational Requirement containing 1–4 security requirements per Security Level and the catalog totaling more than 100 technical controls [S4].
Scope Boundaries for Engineering Teams
IEC 62443-3-3 addresses the system that the asset owner operates, including its architecture, risk context, security functions, and operational behavior. IEC 62443-4-2 addresses the capabilities of an individual IACS component, including its identification and authentication, use control, system integrity, confidentiality, restricted data flow, timely response, and resource availability functions [S1][S2][S3].
Asset owners and system integrators should use 3-3 to establish the target system Security Level and verify the delivered architecture. Product suppliers should use 4-2 to document component capabilities and support qualification against the target SL. IEC 62443-2-1 separately addresses the IACS cybersecurity management system, so selecting controls does not replace the organizational processes required to operate them [S1].
This division does not fit every purchase decision. A standalone device with a narrow function may still need a system-level review of connectivity, remote access, network exposure, maintenance paths, and neighboring systems. A component certificate or capability statement cannot answer those plant-specific questions.
Security Levels and Applicability
IEC 62443-3-3 defines target Security Levels SL1 through SL4 for the system, with requirement enhancements determining which additional controls apply at higher levels [S4]. The ISA Security Compliance Institute recommends that components based on ISA/IEC 62443-4-2 target at least SL2, even though the standard defines SL1 with fewer requirements [S2].
SL2 requires unique identification and authentication at the applicable system requirement level, while multifactor authentication from untrusted networks appears as a higher-level enhancement in the 3-3 catalog [S4]. The component paper groups 4-2 capabilities into eight functional areas: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, resource availability, and security capability-level conformance [S2].
Do not treat SL2 as a universal plant-wide default. The target SL must reflect the assessed risk, required protections, and system design. The ISCI recommendation is a minimum for components used in this domain, not proof that every integrated system must use the same target level [S2].
System Controls Across Seven Requirement Areas
IEC 62443-3-3 organizes system controls into FR1 through FR7: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability [S4]. These categories map directly to plant engineering decisions.
FR1 addresses human, device, and software identification and authentication. FR2 governs authorization and privilege. FR3 covers protection against unauthorized changes to firmware, operating systems, applications, or data. FR4 addresses encryption and sensitive-information protection. FR5 addresses segmentation and controlled communications between zones. FR6 covers logging, monitoring, alerting, and incident detection. FR7 covers backup, recovery, restoration, and protection against denial-of-service conditions [S4].
A component may implement the local control needed for one of these functions, but the system integrator must verify that the functions work together. Authentication can pass at the device while authorization is inconsistent across shared services; encryption can exist while network paths still bypass zones; audit records can be generated while they are not collected or reviewed. The 3-3 assessment must therefore test the integrated behavior rather than collect isolated feature claims.
Component Evidence for Procurement and Qualification
IEC 62443-4-2 supplies the technical requirement set for evaluating an individual IACS component [S3]. The excerpt from S2 identifies five foundational requirements—identification and authentication control, use control, system integrity, data confidentiality, and restricted data flow—and their associated functional areas [S2].
For procurement, request the exact component model, firmware baseline, applicable standard edition, assessed Security Level, claimed requirement coverage, and supporting certification or test report. A statement covering only a product family can conceal differences between models, variants, optional communications modules, or installed firmware configurations.
Also define the evidence required from the supplier. The research supports four functional capability groupings suitable for evaluation: identification and authentication across FR1 to FR3, confidentiality and restricted data flow across FR4 and FR5, event and resource assurance across FR6 and FR7, and conformance at the claimed security capability level [S2]. The supplier must show which capabilities apply to the offered configuration rather than merely list the standard number.
Zoned Architectures and Verification Boundaries
IEC 62443 uses zones and conduits as core architecture concepts: zones group assets with similar security requirements, while conduits control communication flows between those zones [S1]. IEC 62443-3-3 is therefore needed where a firewall, DMZ, conduit policy, jump host, or cross-zone authentication decision determines the security of the integrated plant.
Component review remains necessary inside each zone. A component that cannot authenticate software, reject unauthorized use, protect its integrity, or restrict data flow may weaken a correctly segmented design. Verification must cover the actual communications path, network service configuration, credential handling, update process, logging path, and recovery procedure [S1][S4].
The IEC 62443 zones and conduits guide provides plant-side implementation context, but it does not replace the normative 3-3 system assessment or 4-2 component evidence. Zone boundaries cannot substitute for a product's own security capabilities.
Common Failure Modes in Certification and Integration
Four failure modes recur in industrial security programs: treating a 4-2 component claim as system certification, selecting a 3-3 target without connecting it to the risk assessment, allowing different Security Levels across critical dependencies, and accepting supplier evidence without configuration control. [S4]
System integration also creates gaps when components are individually acceptable but their interfaces are not. A complete path from an engineering workstation to a controller must be assessed for authentication, authorization, segmentation, logging, and availability. Maintenance access, remote support, temporary vendor connections, and software update paths require the same treatment as normal operations [S1][S4].
Component qualification can also fail through evidence quality. A generic compliance claim, an outdated assessment, or a certificate for the wrong model or firmware does not prove the delivered configuration conforms to the requested target level. Preserve the model identification, firmware version, assessment scope, Security Level, and report status with the procurement record.
Procurement and Assurance Workflow
Use 3-3 and 4-2 together in three stages: define the system target with 3-3, qualify each component with 4-2, then verify the integrated implementation against the 3-3 requirement set. For a brownfield asset, begin with the risk and architecture work associated with IEC 62443-3-2 before setting target Security Levels [S1].
Record the target SL, system design, zones and conduits, applicable 3-3 requirements, component models and firmware, each 4-2 claim, interface responsibilities, residual risks, and test results. The ISA/IEC 62443-4-2 paper expressly supports a minimum SL2 target for components, while 3-3 requires the plant assessment to determine the system target [S2][S4].
For a system procurement, require the integrator to demonstrate the 3-3 solution rather than relying only on compliant components. For a component purchase, require the supplier to provide model-specific 4-2 evidence and identify any features, interfaces, or firmware restrictions. For assurance, track two signals: unresolved requirements in the final 3-3 assessment and mismatches between approved component configurations and the equipment installed at site.