This page is part of the IEC 62443 compliance hub.
IEC 62443 compliance testing is where the gap between policy and proof is closed. Regulators, customers and certification bodies are no longer satisfied with documented intentions. They want empirical evidence that industrial systems and components behave securely under real conditions.
This guide explains what IEC 62443 compliance testing involves, which parts of the standard drive testing obligations, and how ProtoCrawler helps UK industrial organisations generate the structured, audit-ready evidence they need.
In This Guide
- What Is IEC 62443 Compliance Testing?
- Who Needs to Carry Out Compliance Testing?
- What the Standard Actually Requires
- Why Protocol Testing Is Central to Compliance
- What IEC 62443 Compliance Testing Covers
- How ProtoCrawler Delivers Compliance Testing
- What Audit-Ready Evidence Looks Like
- Maintaining Compliance Over Time
What Is IEC 62443 Compliance Testing?
IEC 62443 compliance testing is the process of verifying that industrial systems, components and development processes meet the security requirements set out in the relevant parts of the standard. It goes beyond architecture review and risk assessment to produce empirical evidence that devices and systems behave as required under adverse conditions.
The standard covers multiple roles within the industrial ecosystem. Asset owners, system integrators and product vendors each face different testing obligations depending on which parts of IEC 62443 apply to their situation. What they share is the need to demonstrate, not just assert, that security requirements are met.
Who Needs to Carry Out Compliance Testing?
Three groups of organisations have direct compliance testing obligations under IEC 62443.
Product vendors and device manufacturers working to IEC 62443-4-1 and IEC 62443-4-2 must demonstrate that products are developed securely and meet component-level technical security requirements. This includes robustness testing of protocol implementations as part of a secure development lifecycle.
System integrators working to IEC 62443-2-4 must demonstrate that integrated IACS environments are designed and commissioned securely. Validation testing of communication interfaces is a core expectation.
Asset owners and operators working to IEC 62443-3-3 must demonstrate that deployed systems meet system-level security requirements for their target security level. This includes evidence that systems maintain availability and reject malformed inputs under adverse conditions.
In practice, compliance testing obligations are also driven by customer contracts, procurement tenders and supply chain security requirements. If you supply products or services into regulated critical infrastructure sectors in the UK, your customers may be asking for IEC 62443 testing evidence regardless of your direct regulatory obligations.
What the Standard Actually Requires
IEC 62443 places security requirements across several parts of the standard, each with direct implications for testing.
IEC 62443-3-3 defines system security requirements at security levels 1 through 4. SR 7.1 requires denial-of-service protection, meaning systems must maintain availability when subjected to unexpected or excessive inputs. SR 7.2 requires resource management and availability under adverse conditions. Both requirements call for empirical evidence that systems behave correctly, not just that controls exist on paper.
IEC 62443-4-2 defines component-level technical security requirements. CR 3.5 requires input validation, meaning devices must safely handle malformed, out-of-range or unexpected inputs without entering unsafe states. CR 7.2 requires backup integrity and availability. These requirements apply directly to the protocol stacks implemented in industrial devices.
IEC 62443-4-1 defines requirements for a secure product development lifecycle. Practice 6 (Security Verification and Validation) requires that products are tested against their security requirements before release, including robustness and boundary testing of interfaces. It also requires that testing is repeated when the product changes.
IEC 62443-2-4 defines requirements for IACS service providers and includes validation testing obligations for system integrators during commissioning and acceptance.
For a detailed clause-by-clause breakdown of how fuzz testing satisfies these requirements, see the IEC 62443 fuzz testing guide.
Why Protocol Testing Is Central to Compliance
Industrial systems communicate through protocols. Modbus, DNP3, IEC 61850, IEC 60870-5-104 and others carry the commands, data and status information that keep operational technology environments running. The security of those communications is where IEC 62443’s technical requirements are focused, and it is where most compliance gaps are found.
Traditional IT security testing tools do not understand industrial protocols. Generic network scanners and vulnerability assessment tools operate at the IP and TCP layer and cannot exercise the application-layer behaviour that IEC 62443 is concerned with. A device that responds safely to standard inputs may behave entirely differently when it receives malformed, out-of-sequence or deliberately crafted protocol messages.
Protocol fuzz testing is the method that closes this gap. It systematically generates thousands of variant inputs across the full range of protocol fields and sequences, exercises the device under test against each one, and records exactly how the device responds. The result is empirical evidence of protocol robustness that maps directly to the IEC 62443 clause requirements that auditors and certification bodies look for.
What IEC 62443 Compliance Testing Covers
A well-structured IEC 62443 compliance testing programme covers the following areas.
Protocol robustness testing verifies that devices and systems handle malformed, out-of-range and unexpected protocol inputs safely. This addresses SR 7.1, SR 7.2 and CR 3.5 directly and is the most consistently required form of testing across all IEC 62443 roles.
Input validation testing verifies that components reject invalid inputs without entering unsafe or undefined states. Buffer overflows, state machine failures and unexpected data type handling are the typical findings. These map to CR 3.5 and the SVV practices in IEC 62443-4-1.
Denial-of-service resilience testing verifies that systems maintain availability and recover correctly when subjected to high volumes of unexpected traffic or repeated malformed inputs. This addresses SR 7.1 directly and is particularly important for asset owners targeting SL 2 and above.
Authentication and authorisation testing verifies that devices correctly enforce authentication requirements and reject commands where authentication is missing, malformed or replayed. Findings in this area map to SR 1.1 through SR 1.3 and equivalent component requirements in IEC 62443-4-2.
State machine testing verifies that devices transition correctly between protocol states and do not accept out-of-sequence commands or enter undefined states. This addresses the indeterminate state vulnerabilities that are commonly found in industrial protocol implementations.
Management plane testing covers the non-control protocols used to manage and monitor industrial devices, including SNMP, SSH, HTTPS and proprietary management interfaces. These are frequently overlooked in compliance testing programmes and consistently produce findings when tested.
How ProtoCrawler Delivers Compliance Testing
ProtoCrawler is Cytal’s automated protocol fuzz testing platform, built specifically for OT and industrial environments. It is designed around the evidence requirements that IEC 62443 compliance demands.
Generation. ProtoCrawler automatically generates test configurations based on your target protocol and testing scope. You define the interface, the depth of testing and the time available. ProtoCrawler does the rest, producing thousands of structured test cases without manual effort. Test configurations can be saved and reused for regression testing, which means the investment in test design carries forward across the product lifecycle.
Execution. Tests execute automatically and continuously, with real-time monitoring through an intuitive interface. Testing can be paused, modified and resumed mid-run, which is essential in operational technology environments where device availability cannot be compromised. ProtoCrawler supports safe testing on live and near-live industrial systems.
Analysis. A pre-configured scoring matrix, developed from years of industrial testing experience, automatically prioritises findings by risk. Higher risk findings are surfaced first so engineering and development teams can focus effort where it matters most. The scoring matrix can be customised to match your specific security level targets and risk appetite.
Reporting. ProtoCrawler produces structured reports that are directly usable as audit evidence. Reports include scope documentation, test configurations, scored findings and coverage traceability. They can be customised and branded for sharing with certification bodies, customer procurement teams, regulatory assessors and internal governance stakeholders.
ProtoCrawler supports the full range of industrial protocols encountered in IEC 62443 assessments, including Modbus, DNP3, IEC 61850, IEC 60870-5-104, MQTT and SNMPv3. For the complete list see the protocol models page.
What Audit-Ready Evidence Looks Like
Compliance testing evidence that satisfies IEC 62443 auditors and certification bodies consistently contains the same components.
A scope document that clearly defines what was tested, which protocols and interfaces were included, which security level was targeted, and which IEC 62443 clauses the testing was designed to address.
Test configuration records showing the specific inputs applied, the depth and structure of malformations used, and the coverage achieved across the protocol under test.
Scored findings showing which inputs produced anomalous responses, the severity assigned to each finding, and the basis for that severity score.
Remediation records showing which findings were addressed, what changes were made, and how remediation was verified through retesting.
Regression records demonstrating that testing has been repeated when the product or system changed, with traceability back to the original test configurations.
ProtoCrawler produces all of these outputs as part of its standard reporting capability. Organisations using ProtoCrawler as part of their IEC 62443 compliance programme can assemble a complete evidence package without significant additional documentation effort.
Maintaining Compliance Over Time
IEC 62443 compliance is not achieved once and held indefinitely. Systems evolve, firmware is updated, new protocol functionality is added, and regulatory expectations increase. IEC 62443-4-1 is explicit that security testing must be repeated as part of the development lifecycle whenever significant changes are made.
For asset owners and system operators, retesting should occur when new devices are introduced, when firmware is updated, or when network configuration changes extend the attack surface. For product vendors, embedding protocol fuzz testing into a CI/CD pipeline means compliance evidence is generated automatically with each new build, maintaining assurance without manual overhead.
ProtoCrawler’s reusable test configurations make regression testing efficient. Rather than designing new test programmes from scratch after each change, engineers re-execute optimised configurations against the updated target and compare results with previous runs. This approach keeps compliance evidence current and makes it straightforward to demonstrate continuous improvement to auditors over time.
Ready to build your IEC 62443 compliance testing programme? Book a demo to see how ProtoCrawler generates structured, audit-ready evidence for IEC 62443 compliance in OT and industrial environments.
Explore related resources in the IEC 62443 compliance hub or read the IEC 62443 certification UK guide for guidance on the certification process.