This page is part of the IEC 62443 compliance hub.
IEC 62443 is not a single document with a checklist to follow. It is a framework, a structured series of standards that address industrial cyber security from multiple angles simultaneously. Understanding how the framework is organised, what each part covers and how the parts relate to each other is essential before any compliance programme can be scoped and planned effectively.
This guide explains the IEC 62443 framework in full: its structure, its core concepts, how different roles use different parts, and how ProtoCrawler supports the technical testing requirements that run through the framework at every level.
In This Guide
- What Makes IEC 62443 a Framework
- The Four Groups of Standards
- Group 1: General
- Group 2: Policies and Procedures
- Group 3: System
- Group 4: Components
- How Different Roles Use the Framework
- Core Concepts That Run Through the Framework
- Where Testing Fits in the Framework
- How ProtoCrawler Supports the Framework
What Makes IEC 62443 a Framework
A framework in the standards sense is a structured set of requirements organised around a common model, where different parts address different roles, responsibilities and lifecycle stages but share a consistent set of concepts, terminology and measurement criteria.
IEC 62443 works this way deliberately. Industrial cyber security involves multiple stakeholders with different responsibilities and different technical domains. A single monolithic standard cannot adequately address the needs of a PLC manufacturer, a system integrator building a substation automation system, and a water utility managing its operational technology estate. The framework structure allows each stakeholder to work with the parts that apply to them while operating within a shared conceptual model.
The practical consequence is that IEC 62443 compliance means different things depending on your role. An asset owner demonstrating IEC 62443 alignment is working to different parts of the standard than a product vendor pursuing component certification. Both are operating within the same framework but with different obligations, different evidence requirements and different testing priorities.
The Four Groups of Standards
The IEC 62443 series is organised into four groups, each covering a distinct domain within the overall framework. The groups are numbered as parts of the series, with individual standards identified by a two-part number such as IEC 62443-3-3, where the first number identifies the group and the second identifies the specific standard within that group.
Group 1 covers general concepts, terminology and models. Group 2 covers policies and procedures. Group 3 covers system-level requirements. Group 4 covers component-level requirements. Together they address the full supply chain from the individual device through to the complete operational system and the organisation that runs it.
Group 1: General
The General group provides the conceptual foundation for the entire framework. It defines the terminology, models and metrics that all other parts of the series build on, ensuring that asset owners, integrators and vendors working to different parts of the standard share a common language and reference model.
IEC 62443-1-1 defines the core concepts and models including zones, conduits, security levels, the lifecycle model and the roles within the industrial supply chain. It is the starting point for anyone new to the framework and the reference document for understanding how the rest of the series fits together.
IEC 62443-1-2 is the master glossary, defining the terminology used consistently across the series.
IEC 62443-1-3 defines the system security compliance metrics used to measure security level achievement across the framework.
IEC 62443-1-4 covers the IACS security lifecycle and use cases, providing practical guidance on how the framework applies across the full operational lifecycle from design through decommissioning.
Group 2: Policies and Procedures
The Policies and Procedures group addresses the governance and management requirements for asset owners and service providers. It covers the organisational and procedural aspects of industrial cyber security that sit above the technical requirements addressed in Groups 3 and 4.
IEC 62443-2-1 defines the requirements for an IACS cyber security management system. It is the asset owner’s governance standard, covering risk management, security policy, organisational roles and responsibilities, and the processes for managing security across the operational lifecycle. It is broadly comparable in structure to ISO 27001 but adapted for OT environments and IACS-specific concerns.
IEC 62443-2-2 covers the operational security requirements for IACS environments, addressing the policies and procedures needed to maintain security in day-to-day operations.
IEC 62443-2-3 covers patch management in IACS environments, a particularly challenging topic given the long lifecycles and limited patching windows common in operational technology.
IEC 62443-2-4 defines security requirements for IACS service providers, primarily system integrators and managed service providers. It covers the security practices that service providers must apply during integration, commissioning and maintenance activities and is the standard most directly relevant to system integrators working in UK critical infrastructure sectors.
Group 3: System
The System group addresses security at the level of the complete IACS environment. It covers risk assessment, secure architecture design and the system-level security requirements that integrated IACS environments must meet.
IEC 62443-3-2 defines the process for conducting a cyber security risk assessment for system design. It covers how to identify and scope IACS assets, define zones and conduits, assess threats and vulnerabilities, and determine the target security levels for each zone. The outputs of an IEC 62443-3-2 risk assessment are the inputs that drive system design and testing decisions under IEC 62443-3-3.
IEC 62443-3-3 defines system security requirements and security levels. It is the most widely cited part of the standard in regulatory and procurement contexts and the reference point for system-level compliance evidence. IEC 62443-3-3 organises its requirements under seven Foundational Requirements, with System Requirements numbered SR followed by the FR number. SR 7.1 denial-of-service protection and SR 7.2 resource availability are the system-level requirements most directly addressed by protocol security testing.
IEC 62443-3-3 also defines how security levels apply at the system level, establishing the link between the threat model outputs from IEC 62443-3-2 and the technical requirements that must be met to achieve a target security level.
Group 4: Components
The Component group addresses security at the level of individual IACS devices, software applications and firmware. It is the group most directly relevant to product vendors and device manufacturers and the group that drives the most specific technical testing obligations.
IEC 62443-4-1 defines the requirements for a secure product development lifecycle. It covers the eight practices that a vendor’s development process must implement, from security management and requirements specification through to secure implementation, testing, vulnerability management and security update delivery. Practice 6, Security Verification and Validation, is the practice that drives direct testing obligations and explicitly names fuzzing as a required method for SVV-3 vulnerability testing.
IEC 62443-4-2 defines the technical security requirements for IACS components. It covers four component types: embedded devices, host devices, network devices and software applications. It defines Component Requirements that must be met at each security level. CR 3.5 input validation and CR 7.1 denial-of-service protection are the requirements most directly addressed by protocol fuzz testing.
For detailed guidance on IEC 62443-4-1, see the secure development lifecycle guide. For detailed guidance on IEC 62443-4-2, see the component security requirements guide.
How Different Roles Use the Framework
The IEC 62443 framework is designed so that different stakeholders work with the parts that apply to their role while contributing to a shared security outcome across the supply chain.
Asset owners work primarily with Group 2 and Group 3. IEC 62443-2-1 governs their cyber security management system. IEC 62443-3-2 drives their risk assessment and zone definition. IEC 62443-3-3 defines the system security requirements they must meet and the security level targets they must demonstrate. Asset owners also have obligations around the components they deploy, requiring evidence from their suppliers that products meet IEC 62443-4-2 requirements at the appropriate security level.
System integrators work primarily with Group 2 and Group 3. IEC 62443-2-4 governs their service provider practices. IEC 62443-3-3 defines the system security requirements for the environments they design and commission. Integrators are responsible for ensuring that the components they integrate are appropriate for the security level targets of the zones they are deployed in.
Product vendors work primarily with Group 4. IEC 62443-4-1 governs their development processes. IEC 62443-4-2 defines the technical requirements their products must meet. Vendors are responsible for generating the component-level compliance evidence that asset owners and integrators rely on when making deployment decisions.
The supply chain dimension of the framework is important. Asset owners cannot meet their IEC 62443-3-3 obligations without components that meet IEC 62443-4-2 requirements. This dependency is what drives IEC 62443 certification requirements into procurement contracts and supplier qualification processes across UK industrial sectors.
For a detailed comparison of how IEC 62443 relates to the NIST Cybersecurity Framework and how organisations operating across UK and US markets use both together, see the IEC 62443 vs NIST guide
Core Concepts That Run Through the Framework
Several concepts are defined in Group 1 and used consistently across all other parts of the framework. Understanding them is essential for working with any part of the standard.
Security Levels define the degree of protection against progressively more capable threat actors, from casual unintentional violations at SL 1 through to state-sponsored attacks at SL 4. Security Levels apply at the zone level in system assessments and at the component level in product assessments. They provide the common measurement scale that links Group 3 and Group 4 requirements and allows system integrators and asset owners to specify and verify what level of protection components must provide.
Zones and Conduits provide the architectural model for segmenting IACS environments. Every IACS asset belongs to a zone with a defined security level target. Every communication path between zones passes through a conduit with defined security controls. The zone and conduit model drives network segmentation decisions and identifies the communication paths that require the most rigorous security testing.
The Lifecycle Model addresses security across the full operational lifecycle of an IACS environment, from concept and design through integration, operation, maintenance and decommissioning. The framework applies at every stage, not just during initial development or deployment.
Foundational Requirements are the seven security domains used to organise requirements at both the system level in IEC 62443-3-3 and the component level in IEC 62443-4-2. They cover identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events and resource availability.
For a full explanation of how security levels work in practice, what testing each level requires and what evidence supports a credible security level claim, see the IEC 62443 security levels guide
Where Testing Fits in the Framework
Security testing is embedded throughout the IEC 62443 framework rather than being a single activity at a single point in the lifecycle.
At the component level, IEC 62443-4-1 Practice 6 defines testing as a core development lifecycle activity with four distinct testing types. IEC 62443-4-2 defines the technical requirements that testing must demonstrate are met, including input validation, denial-of-service protection and authentication enforcement.
At the system level, IEC 62443-3-3 defines system security requirements that must be validated through testing during integration and commissioning. IEC 62443-2-4 places testing obligations on system integrators as part of their service delivery practices.
Across all levels, the framework requires that testing evidence is documented, traceable to specific requirements, and repeated when systems or components change. This is not a one-time compliance exercise. It is a continuous assurance obligation that scales with the security level being claimed.
Protocol fuzz testing sits at the intersection of the component-level SVV requirements in IEC 62443-4-1 and the technical requirements in IEC 62443-4-2 and IEC 62443-3-3. It is the primary method for generating empirical evidence of the robustness, input validation and denial-of-service protection requirements that appear at multiple levels of the framework.
For a detailed guide to what IEC 62443 compliance testing involves and what audit-ready evidence looks like, see the IEC 62443 compliance testing guide.
How ProtoCrawler Supports the Framework
ProtoCrawler supports IEC 62443 compliance across the framework by addressing the protocol security testing requirements that appear consistently at every level.
For product vendors working to IEC 62443-4-1 and 4-2, ProtoCrawler generates the SVV-3 vulnerability testing evidence required by Practice 6 and produces component-level compliance evidence for CR 3.5, CR 7.1 and related requirements in IEC 62443-4-2. Its reusable test configurations support the regression testing obligations that IEC 62443-4-1 places on vendors throughout the product lifecycle.
For system integrators and asset owners working to IEC 62443-3-3, ProtoCrawler generates system-level evidence of protocol robustness against SR 7.1 and SR 7.2 requirements. Testing at zone boundaries, where industrial protocols cross between zones with different security levels, is a direct application of the zone and conduit model that ProtoCrawler supports in practice.
ProtoCrawler produces structured, audit-ready reports that are directly usable as compliance evidence at both the component and system level. Reports include scope documentation, test configurations, scored findings and coverage traceability, providing the evidence base that the framework’s testing requirements demand at every level.
For the full list of industrial protocols supported, see the protocol models page. For the complete set of IEC 62443 guides, explore the IEC 62443 compliance hub.