Most organisations pursuing IEC 62443 certification conduct some form of security testing. The problem is not usually the absence of testing. It is the absence of evidence. Testing that is not documented in a way that maps to the standard’s requirements does not satisfy the standard’s requirements, regardless of how thorough the testing was.
This guide explains what IEC 62443 compliance testing requires, what audit-ready evidence looks like in practice, and where protocol fuzz testing fits into the evidence picture.
In This Guide
What IEC 62443 Requires From Testing
IEC 62443 places testing obligations at two levels. At the process level, IEC 62443-4-1 defines what the vendor’s development lifecycle must include in terms of security testing practices. At the component level, IEC 62443-4-2 defines the technical security requirements that a specific product must meet and that testing must demonstrate.
The distinction matters because it changes what the evidence needs to show. Process-level compliance means demonstrating that testing activities are defined, repeatable, and applied consistently across development projects. Component-level compliance means demonstrating that a specific product meets specific requirements under test conditions.
Both require documentation. An assessor reviewing IEC 62443-4-1 compliance is not asking whether testing happened. They are asking whether the organisation has a defined, documented testing process and whether there is evidence that the process was applied. An assessor reviewing IEC 62443-4-2 compliance is not asking whether the product is secure in a general sense. They are asking whether specific requirements, CR 3.5 input validation or CR 7.1 denial-of-service protection, are demonstrably met, with test evidence that traces directly to those requirements.
Organisations that treat IEC 62443 as a documentation exercise without empirical testing fail the second check. Organisations that conduct thorough testing but produce generic reports without requirement traceability fail both.
Practice 6 and the SVV Requirements
IEC 62443-4-1 Practice 6 is titled Security Verification and Validation Testing. It defines five security testing activities, SVV-1 through SVV-5, that product vendors must conduct and document as part of their secure development lifecycle.
SVV-1 requires security requirements testing: verifying that the security requirements defined earlier in the development process have been correctly implemented. The evidence is a test plan that maps each security requirement to one or more test cases, and test results that confirm each requirement has been verified.
SVV-2 requires threat mitigation testing: verifying that the mitigations defined in the product’s threat model are effective. This connects directly to the threat modelling work required earlier in the process and requires evidence that each identified threat has been addressed and that the mitigation works as intended.
SVV-3 is where protocol fuzz testing becomes directly relevant. It requires vulnerability testing: systematic testing to identify vulnerabilities that were not anticipated during design. The standard specifically references robustness testing and fuzzing as applicable methods. At higher security levels, SVV-3 requires that testers have a defined level of independence from the development team.
SVV-4 requires penetration testing at SL 3 and above. It specifies scope, independence requirements, and documentation expectations, and requires that findings are tracked through to resolution.
SVV-5 requires that all testing activities are documented and that the evidence is maintained as part of the product’s security record. This is the requirement that makes evidence format and structure a compliance issue, not just a quality preference.
The practical implication is that a single penetration test report does not satisfy Practice 6. SVV-1, SVV-2, SVV-3, and SVV-5 are separate requirements, each with distinct evidence expectations. An organisation that conducts one type of testing and assumes it covers all of Practice 6 will have gaps that an assessor will find.
What Audit-Ready Evidence Actually Looks Like
Audit-ready evidence has four components, each of which an assessor will look for independently. Missing any one of them weakens the compliance record even if the others are strong.
Scope documentation defines what was tested. For protocol testing this means the specific product version, the protocols tested, the interfaces assessed, the security level target, and the requirements being verified. Scope documentation without this specificity cannot be used as compliance evidence because it is impossible to determine what the testing actually covered.
Methodology documentation defines how testing was conducted. This includes the tools used, the categories of test cases generated, the monitoring approach, and the criteria used to classify findings. Methodology documentation is what allows an assessor to evaluate the rigour of the testing rather than simply accepting that it was done. A methodology section that says vulnerability testing was conducted without explaining how is not sufficient.
Findings documentation records what the testing found. Each finding needs the exact input that triggered it, the observed behaviour, the severity classification, and the remediation status. A finding logged as crash on malformed input without the specific input and the specific crash behaviour cannot be verified, reproduced, or used to confirm that a fix is effective.
Coverage documentation demonstrates that the testing reached the code and inputs that matter. For protocol testing this means showing which message types were tested, which field variations were generated, and which parts of the state machine were exercised. Coverage documentation is the evidence that distinguishes thorough testing from superficial testing that touched the right protocols without meaningfully exercising them.
These four components need to appear in a structured, traceable format. A narrative report that discusses the testing programme in general terms without providing the specific detail that each component requires does not satisfy IEC 62443-4-1 Practice 6, regardless of how professionally it is written.
The Most Common Evidence Gaps
The evidence gaps that assessors find most consistently fall into predictable categories. Understanding them before a compliance programme is planned is more useful than discovering them during an assessment.
The most common gap is SVV-3 coverage. Organisations typically have requirements testing and some form of penetration testing. They rarely have systematic, documented vulnerability testing with the robustness and fuzzing coverage that SVV-3 requires. A penetration test report covers SVV-4 at SL 3 and above. It does not cover SVV-3, which requires a different methodology and a different evidence format.
The second most common gap is requirement traceability. Testing evidence that does not map findings and test results to specific IEC 62443-4-2 component requirements cannot demonstrate component-level compliance. An assessor reviewing CR 3.5 input validation compliance needs to see test cases that specifically address input validation across the component’s external interfaces, and results that confirm validation is effective. Generic testing evidence that does not reference CR 3.5 does not satisfy the requirement.
The third gap is remediation tracking. IEC 62443-4-1 requires that findings from testing are tracked through to resolution. A test report that lists findings without a corresponding record of remediation status, fix verification, and closure leaves the compliance record incomplete.
Where Protocol Fuzz Testing Fits
Protocol fuzz testing is the primary method for satisfying SVV-3 for components that communicate over industrial or telecoms protocols. It is the systematic, automated approach to vulnerability testing that the requirement points toward, and it produces evidence in a form that the other SVV activities do not replicate.
The specific requirements it addresses most directly are CR 3.5 input validation and CR 7.1 denial-of-service protection. CR 3.5 requires that the component validates inputs from all external interfaces before processing them. Demonstrating this requires testing with invalid inputs across those interfaces and showing that validation is effective. CR 7.1 requires that the component is protected against denial-of-service conditions. Demonstrating this requires testing with the input conditions that cause resource exhaustion, processing failures, or availability degradation.
Both of these requirements can only be demonstrated empirically. Documentation that the requirements have been designed for does not satisfy them. Test results showing that the component handles invalid inputs correctly and remains available under adverse load do satisfy them, provided the evidence is structured with the scope, methodology, findings, and coverage documentation that an assessor needs to verify the claim.
Protocol fuzz testing fits alongside, not instead of, the other Practice 6 activities. SVV-1 requirements testing and SVV-2 threat mitigation testing address different questions from SVV-3 and require different evidence. A complete Practice 6 compliance record contains evidence for each SVV activity, with protocol fuzz testing forming the SVV-3 component.
How ProtoCrawler Produces IEC 62443 Evidence
ProtoCrawler is CyTAL’s automated protocol fuzz testing platform and is built to produce the SVV-3 evidence that IEC 62443-4-1 Practice 6 requires.
For each test run, ProtoCrawler produces a structured evidence record that contains all four components an assessor looks for. The scope is documented automatically: the protocol tested, the product version, the interfaces assessed, and the security requirements being addressed. The methodology is recorded: the protocol model used, the test case generation strategy, and the monitoring approach. Each finding is logged with the exact reproducing input, the observed behaviour, and a severity classification. Coverage is documented showing which message types, field variations, and state machine paths were exercised.
The reporting output maps findings directly to IEC 62443-4-2 requirements. A finding in DHCP option handling maps to CR 3.5. A finding that causes a denial-of-service condition maps to CR 7.1. This traceability is built into the report structure rather than added manually after the fact, which means the evidence format matches what assessors are looking for rather than requiring translation.
The protocols supported by ProtoCrawler that are most commonly assessed in IEC 62443-4-2 evaluations include Modbus, DNP3, IEC 61850, DLMS, and MQTT. For the full protocol list, see the protocol models page.
- Modbus → https://cytal.co.uk/protocols/modbus-server/
- DNP3 → https://cytal.co.uk/protocols/distributed-network-protocol-3-dnp3/
- IEC 61850 → https://cytal.co.uk/protocols/iec61850-client-server-mms/
- DLMS → https://cytal.co.uk/protocols/dlms-server/
- MQTT → https://cytal.co.uk/protocols/mqtt-client/
- protocol models page → https://cytal.co.uk/protocols/
- IEC 62443 compliance hub → https://cytal.co.uk/iec-62443/
Common Questions
Does a penetration test satisfy IEC 62443-4-1 Practice 6?
Not on its own. A penetration test satisfies SVV-4 at SL 3 and above. Practice 6 also requires SVV-1 security requirements testing, SVV-2 threat mitigation testing, and SVV-3 vulnerability testing including robustness and fuzzing. Each activity has distinct evidence requirements. A penetration test report covers one of them.
Can existing test documentation be adapted for IEC 62443 compliance?
Sometimes. Existing test documentation that covers the right activities can often be restructured to meet IEC 62443 evidence requirements. The most common problem is that existing documentation lacks the requirement traceability that IEC 62443-4-2 needs. Adding that traceability retrospectively is possible but requires that the original testing actually covered the relevant requirements, not just that it can be argued to have done so.
How frequently does compliance testing need to be repeated?
Practice 6 requires that testing evidence is maintained and updated when products change. A material change to the product, particularly to the protocol implementations or security functions that were tested, requires reassessment of the affected areas. The compliance record needs to reflect the current product version, not the version that was originally certified.
What is the difference between SVV-3 and SVV-4?
SVV-3 requires systematic vulnerability testing including robustness testing and fuzzing, conducted to find vulnerabilities that were not anticipated during design. SVV-4 requires penetration testing conducted by a tester with a defined level of independence from the development team, focused on verifying that identified vulnerabilities cannot be exploited in combination to achieve a security objective. SVV-3 is about finding vulnerabilities at scale. SVV-4 is about verifying that the most significant ones cannot be exploited.
Ready to produce the SVV-3 evidence your IEC 62443 certification requires? Book a demo to see how ProtoCrawler generates audit-ready protocol testing documentation that maps directly to IEC 62443-4-1 Practice 6.