Security test grades, test modules and pentests: how IEC 62443-4-1 and IEC 62443-4-2 regulate testing and what the Cyber Resilience Act requires.
Two draft amendments address this, one to IEC 62443-4-1 and one to IEC 62443-4-2. Both are available as prAA. A Security Test Grade (STG) is a defined set of Security Test Modules (STM). Each module describes a single test activity with objective, requirement, applicability criteria and conditions for PASS and FAIL. The addition to IEC 62443-4-1 anchors the procedure in the development process; the addition to IEC 62443-4-2 provides three grades and 21 assigned modules for components.
The Cyber Resilience Act requires in Annex I Part II number 3 that the product’s security be tested and verified “regularly and effectively.” Annex VII number 6 requires test reports as part of the technical documentation. The regulation does not define what “effectively” means, how deep the testing must be, or how an assessor can tell.
That gap is closed only by the standard: it describes which tests must be run and to what depth. However, a presumption of conformity does not automatically follow. Annex ZZ of IEC 62443-4-2 maps the normative sections of the standard to the fundamental requirements in Annex I Part I once its reference appears in the EU Official Journal. The testing obligation from Part II number 3 is not included in that table. Until then it can be used for planning, but no more.
Nine requirements define what testing covers
IEC 62443-4-1 completely replaces its practice for verification and validation. Five requirements become nine, and the numbering shifts throughout.
| Requirement | Content | Origin |
|---|---|---|
| SVV-1 | Independence of testers | previously SVV-5 |
| SVV-2 | Test of functional security requirements | previously SVV-1 |
| SVV-3 | Test of the effectiveness of threat mitigations | previously SVV-2 |
| SVV-4 | Vulnerability testing, including attack surface analysis and software composition analysis | previously SVV-3 |
| SVV-5 | Robustness tests for load, scaling and fuzzing | newly composed |
| SVV-6 | Penetration tests | previously SVV-4 |
| SVV-7 | Derivation of the security test grade | new |
| SVV-8 | Test plans and test reports | new |
| SVV-9 | Recurring testing over the support period | new |
If you still work to the 2018 version, you must update the references in your process documentation. The new robustness tests are the most awkward case because they merge two old requirements: fuzzing and network load tests were previously under SVV-3(a), while performance, scaling and stress tests were under SVV-1(b) and (c).
The test grade affects only SVV-3 through SVV-6. Functional testing of security requirements under SVV-2 is unaffected. Whether an access control does what it should does not depend on the chosen test grade.
Three grades determine test depth
The grades build on each other. STG-2 contains all modules from STG-1; STG-3 contains all from both.
One detail decides on bindingness: Annex G is marked informative, but the normative clause 4.4 of IEC 62443-4-2 requires its application and the fulfillment of the acceptance criteria of all applicable modules. Anyone who only notices the “(informative)” in the annex title underestimates the effect.
STG-1 mostly comprises tool-assisted tests without logging into the product: port scan, vulnerability scan, checking crypto protocols, basic fuzzing, basic load testing. STG-2 repeats the same techniques with authentication, because an authenticated scanner sees patch levels and accounts invisible from the outside. STG-3 adds the manual: risk-oriented pentesting, custom fuzzing, application-specific load tests and a binary software composition analysis.
Security testing according to IEC 62443 the three security test grades and the number of their test modules at a glance
The same test type at three depths
Annex G assigns 21 modules to the three grades: eleven in STG-1, six more in STG-2, four in STG-3. A 22nd module is outside the grades and optional. The same test type increases in scope across the grades:
| Test type | STG-1 | STG-2 | STG-3 |
|---|---|---|---|
| Vulnerability scan | unauthenticated, depending on the product general, web or OT | same scans authenticated | part of the manual pentest |
| Fuzzing | standardized protocols for which test suites exist | additionally proprietary protocols and those without ready-made suites | tailored to the product’s threat scenarios |
| Load test | generic network load across OSI layers 2 to 4 | no additional module | manual and application-specific |
| Components and patch level | validate SBOM and compare against vulnerability databases | authenticated scan of patch level | binary software composition analysis across all executables |
| Undocumented accounts | unauthenticated search with standard tools | authenticated search | manual search for what tools do not find |
There are also modules that occur only once: port scan, malware scan and verification of cryptographic communication protocols are all in STG-1. The optional module for dynamic resource management at runtime is applied when suitable tools are available.
Where results can be objectified, the module says so
Until now the tester decided what constitutes an acceptable result and the assessor later decided again. For the technically unambiguous modules that ends:
- STM-2: No undocumented open TCP or UDP port. One is enough for a FAIL.
- STM-8 and STM-17: No persistent critical findings, and the product’s specified minimum function is preserved. Crashes and reboots are unacceptable. Sporadic findings that do not recur in five repetitions do not count as vulnerabilities.
- STM-9: The product maintains its minimum function under load and recovers afterwards without intervention. If no recovery time is specified, a default of 120 seconds applies.
For a machine controller with a web interface this means: if you used to document “fuzzing ran, a few reconnects,” you must now prove there were no restarts and the minimum function was maintained.
For the majority of modules there remains room for interpretation. Their PASS criterion ties to the acceptable residual risk in the product context, and that is still assessed by the manufacturer. Two manufacturers can therefore run the same test grade and nevertheless evaluate the same finding differently.
The test grade follows the risk
SVV-7 requires a process that derives the grade from the threat model and risk assessment, explicitly taking into account the assumed attacker.
If you work with an attacker model that includes targeted manual attacks, tool-assisted modules are not sufficient. You know the same logic from the security levels of IEC 62443.
This is followed by the applicability check according to Annex D of IEC 62443-4-1, and this annex is normative:
- ASTM-1 checks the factual criteria of the module. A product without a web interface does not need STM-6.
- ASTM-2 checks applicability based on the risk assessment.
- ASTM-3 requires documentation: the initial set of modules, justification for each removed module, and the resulting set.
This third stage removes the basis for disputes with the assessor. Previously the argument was whether a test should have been performed. In future there will be either a justified removal or not, and the assessor evaluates a justification that can be reviewed.
Pentest means manual, everything else is a scan
The standard knows three variants of the penetration test (pen testing): purely tool-assisted, manual, and a combination. The tool-assisted variant is essentially a bundle of modules from STG-1 and STG-2 for which the higher independence of testers must also be met. Manual testing is captured in STM-18 in STG-3, where experienced testers go through product-specific functions and attack scenarios and may use recognized frameworks such as the OWASP testing framework.
In our view only the manual variant deserves the name. The term is used so loosely that it says almost nothing, and anyone who sells a tool run as a pentest exploits that vagueness.
When it is due can be clearly delineated. Major function changes with security relevance should be tested, e.g. a new update mechanism, secure boot or a newly integrated authentication via Keycloak. Also any major release that by definition changes a lot. This costs money, but it finds things your own tests missed. In safety engineering this approach is already common. For larger changes manufacturers already engage a notified body even without obligation to rule out residual risks.
For fuzzing the method decides
Annex G gives eight hours per interface and protocol as a guideline for minimum duration unless other reasons argue for shorter or longer runs.
Eight hours are a reasonable starting point. Longer running fuzzers naturally find more, but the number of hours is the smaller control knob. More important is how the fuzzer works. If implemented wrongly, you fuzz the CRC32 checksum and never the data processing behind it: the product drops every packet immediately, the test report looks clean, and the actual parsing logic never saw an invalid byte.
The standard reflects escalation. STM-8 covers standardized protocols with existing test suites. STM-17 additionally requires proprietary protocols and those without ready-made suites, and names three approaches: tests derived from captured traffic, self-developed tests from combined fuzzing modules or based on fuzzing SDKs, or manual fuzzing by experienced testers. STM-19 goes further and adapts tests to the product’s threat scenarios.
Independence is mandatory, suitability is a choice
SVV-1 grades how far the tester must be removed from the developer.
| Test type | Required independence |
|---|---|
| Static code analysis (SAST) | none |
| Software composition analysis | none |
| Attack surface analysis, vulnerability scan, abuse-case tests | independent person |
| Robustness tests | independent person |
| Test of security requirements, test of threat mitigations | independent department |
| Penetration tests | independent department or organization |
In practice the top level comes down to procurement. Only the very largest corporations maintain their own pentesters; everyone else buys them on the market. That market requires careful scrutiny because everyone advertises the term and there is a lot of rubbish. If a provider mainly tests phishing, classic IT and web applications, they are typically unsuitable for devices and machines. A suitable tester can also demonstrate their method. If they cannot, they will glance cursorily and flag an outdated cipher suite instead of finding real device problems. How a pentest in an industrial environment proceeds is described in Penetration tests in mechanical engineering.
The assessor separates methodology and result
IEC 62443-4-2 brings a normative evaluation methodology with Annex B. Its block EA-9 divides testing into 15 audit activities. Four are decisive:
- Independence of testers according to SVV-1.
- Chosen test grade: is it documented, does it match the result of the risk assessment, was the applicability check according to Annex D applied?
- Completeness of test artifacts against the content required by SVV-8.
- For each test type two separate activities: once the methodology, once the result.
A test report without a documented procedure therefore fails even if nothing was found. “No findings” leaves open, without the corresponding methodology, whether the right places were even searched. SVV-8 therefore requires at minimum for test plans and test reports the objectives, coverage, methodology, resources including tools, deliverables, the chosen grade with the applicable modules, the acceptance criteria and the results.
What manufacturers can prepare now
You can already work on the test structure.
First map your existing testing capabilities against the modules. The current state usually covers STG-1 largely, STG-2 patchily and STG-3 not at all. Then derive a grade per product from the threat model and risk assessment, justified in writing, because that justification will be the subject of assessment. Document every removed module with reasons — it’s tedious but saves time in audits. And align test plans and reports to the content required by SVV-8 instead of collecting tool exports.
If you are already setting up the secure development process, you should consider the test structure at the same time.
Decide a test strategy for your product
We assess which test grade fits your product and risk situation, which modules you can cover in-house and where external testers are needed.
