Security test grades, test modules and pentests — how the new drafts of IEC 62443-4-1 and -4-2 regulate testing and what the Cyber Resilience Act requires.
Test grades pentests and CRA
Here the two drafts come in that CLC/TC 65X put up for consultation in March 2026. 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 explicit PASS and FAIL conditions. EN IEC 62443-4-1:2018/prAA:2026 anchors the procedure in the development process, EN IEC 62443-4-2:2019/prAA:2026 provides three grades and 21 associated modules for components.
The Cyber Resilience Act requires in Annex I part II number 3 that the product’s security be tested and reviewed “regularly and effectively.” Annex VII number 6 requires the test reports as part of the technical documentation. What “effective” means, how deep tests must go and how an assessor can tell are not specified in the regulation.
This gap is filled by the standardization route. Annex ZZ of 4-2 flags the standard as a means of presumed conformity once its citation appears in the EU Official Journal, for the normative sections listed in table ZZ.1 within its scope. Until then it is a draft that can be used for planning, nothing more.
Nine requirements classify what testing covers
4-1 replaces its practice for verification and validation completely. Five requirements become nine, and numbering shifts throughout.
| Anforderung | Inhalt | Herkunft |
|---|---|---|
| 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 tests, including attack surface analysis and Software Composition Analysis | previously SVV-3 |
| SVV-5 | Robustness tests for load, scaling and fuzzing | newly recomposed |
| 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 will need to 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 letter a), performance, scaling and stress tests under SVV-1 letters b) and c).
The test grade only affects SVV-3 to SVV-6. The functional verification of security requirements under SVV-2 is unaffected. Whether a role management function does what it should does not depend on the chosen test grade.
Three grades define how deep testing goes
The grades build on each other. STG-2 includes all modules from STG-1, STG-3 includes all from both.
One detail decides enforceability: Annex G is marked informative, yet the normative clause 4.4 of 4-2 requires applying it and meeting the acceptance criteria of all applicable modules. Those who only glance at the “(informative)” in the annex title underestimate its effect.
STG-1 mainly covers tool-assisted tests that do not require product authentication: 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 outside. STG-3 adds manual testing: risk-oriented pentesting, tailored fuzzing, application-specific load tests and a binary Software Composition Analysis.
Security testing under IEC 62443 the three security test grades and the number of their test modules at a glance
The same test type in 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 sits outside the grades and is optional. More interesting than the list is how the same test type scales across the grades. Five examples:
| 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 over all executables |
| Undocumented accounts | unauthenticated search with standard tools | authenticated search | manual search for what the tools don’t find |
There are also modules that occur only once: port scan, malware scan and the check 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 could be made objective it is defined in the module
So far the tester decided what is an acceptable outcome and the assessor later decided again. For the technically unambiguous modules this ends:
- STM-2: No undocumented open TCP or UDP port. A single one is enough for a FAIL.
- STM-8 and STM-17: No persistent critical findings, and the specified minimum function of the product remains. Crashes and reboots are unacceptable. Sporadic findings that do not recur across five repeats do not count as a vulnerability.
- 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: those who previously wrote “fuzzing ran through, a few reconnects” must in future demonstrate that there were no reboots and that minimum function remained.
For the majority of modules there is still leeway. Their PASS criteria tie to the acceptable residual risk in the product context, which the manufacturer still assesses. The grades therefore create a common scope, not a common yardstick for every single finding.
Testing is only one of several practices in IEC 62443-4-1
We assess in 15 questions how your entire development process is set up according to IEC 62443-4-1 — free, with immediate results and recommendations.
The test grade follows the risk
SVV-7 requires a process that derives the grade from the threat model and risk assessment, explicitly taking the assumed attacker into account. The intensity and coverage of tests should match the actors the threat model assumes.
If your attacker model includes targeted manual attacks, tool-assisted modules alone are insufficient. You know the same logic from the Security Levels of IEC 62443.
This is followed by the applicability check according to Annex D of 4-1, and that 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, resulting set.
This third stage removes the basis for dispute with the assessor. Previously the argument was whether a test had been necessary. In future there will be a justified omission or not, and the assessor evaluates the justification rather than gut feeling.
Pentest means manual everything else is a scan
The standard knows three variants of penetration testing: pure tool-assisted, manual, and a combination. The tool-assisted variant is merely a bundling of modules from STG-1 and STG-2, for which additionally the higher independence of testers must be met. Manual testing is covered in STM-18 in STG-3, where experienced testers walk through the product’s specific features and attack scenarios and may use accepted frameworks such as the OWASP Testing Framework.
In our view only the manual variant deserves the name. The term is used so fuzzily that it says almost nothing, and anyone who sells a tool run as a pentest exploits that vagueness. Penetration test means manual work supported by tools.
When it is due is easy to delineate. Significant changes must be tested, i.e., new or completely reworked security-relevant functions such as a new update mechanism, secure boot, or a newly integrated authentication through Keycloak. Also every major release that by definition has changed a lot. That costs money but finds things your own tests missed. In safety this approach is long established. For major changes you have the notified body look over it even when not mandatory because you want to rule out risks.
For fuzzing the method decides
Annex G gives eight hours per interface and protocol as a guideline for minimum duration, unless other reasons call for shorter or longer runs.
The number fits because these standards are written by experienced practitioners. Longer-running fuzzers of course find more, but the hours are the smaller control. More important is how the fuzzer operates. If set up wrong 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 real parsing logic never saw an invalid byte.
The standard maps the 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 recorded 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 tiers 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 tier ends up in procurement. Only the very large corporations keep in-house pentesters; everyone else buys them on the market. Caution is needed there because everyone markets the term and a lot of junk exists. Two touchstones help. If a provider mainly tests phishing, classic IT and web applications, they are typically unsuitable for devices and machines. And a suitable tester can show their method. Those who cannot will glance cursorily and chalk up an outdated cipher suite rather than find real device problems. How a pentest runs in an industrial environment is described in Penetrationstests im Maschinenbau.
The assessor separates methodology and result
4-2 brings a normative evaluation methodology with Annex B. Its block EA-9 breaks testing into 15 verification activities. Four of them carry the weight:
- Independence of testers per SVV-1.
- Chosen test grade: is it documented, does it match the risk assessment result, was the applicability check per Annex D applied?
- Completeness of test artifacts against the content SVV-8 requires.
- Then per test type two separate activities: once the methodology, once the result.
The last point explains why a test report without documented procedure fails even if nothing was found. “No findings” without the associated methodology leaves open whether the right place was searched. SVV-8 therefore requires test plans and reports to include at least objectives, coverage, methodology, resources including tools, deliverables, the chosen grade with applicable modules, acceptance criteria and the results.
What manufacturers can prepare now
The draft is not yet a standard, but the structure behind it is stable enough to work with. Four steps can be taken without the final version.
First map your existing test capabilities to the modules. Usually the current state covers STG-1 largely, STG-2 patchy 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 becomes the audit subject. Document every removed module with a reason — tedious but time-saving in audits. And align test plans and reports to the content SVV-8 requires instead of collecting tool exports.
Those who are setting up the secure development process anyway should think about the test structure at the same time. Integrating test grades into an ongoing process later is more expensive than carrying them from the start.
Set the test strategy for your product
We assess which test grade suits your product and risk posture, which modules you can cover internally and where external testers are needed.
