Security Test Grades in IEC 62443-4-1 and IEC 62443-4-2

Almost every manufacturer tests. Software composition analysis (SCA) runs in the build, alongside a static analysis (SAST) tool. A few in-house test cases run before release, and a procedure somewhere says who does what and when. What is missing is the mapping. Which of these capabilities covers which requirement, and to what depth? Within the same company, the answer often differs from product to product. You cannot compare it, auditing it is tedious, and in IEC 62443 certifications it regularly costs discussion time with the assessors.

Two draft amendments address this, one to IEC 62443-4-1 and one to IEC 62443-4-2. Both are available as prAA drafts. A security test grade (STG) is a defined set of security test modules (STM). Each module describes a single test activity with an objective, a requirement, an applicability criterion, and conditions for PASS and FAIL. The amendment to IEC 62443-4-1 anchors the approach in the development process. The amendment to IEC 62443-4-2 provides three grades and 21 assigned modules for components.

Contents

1. What the CRA says about testing
2. Nine requirements define what testing covers
3. Three grades set the depth of testing
   1. The same type of test at three depths
4. Where results could be made objective, the module says so
5. The test grade follows the risk
6. A pentest means manual testing; everything else is a scan
7. In fuzzing, the method matters most
8. Independence is mandatory; suitability is a selection question
9. The assessor separates method and result
10. What manufacturers can prepare now

What the CRA says about testing

The Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA, addresses testing in Annex I, Part II, point 3. Manufacturers must “apply effective and regular tests and reviews of the security of the product with digital elements”. Annex VII, point 6 requires the test reports as part of the technical documentation. The regulation does not say what “effective” means, how deep testing must go, or how an assessor recognizes it.

Only the standard closes this gap. It describes which tests to run and to what depth. A presumption of conformity does not follow automatically, though. Annex ZZ of EN IEC 62443-4-2 maps the normative clauses of the standard to the essential cybersecurity requirements in Annex I, Part I. This mapping takes effect once the reference is published in the Official Journal of the EU. The testing obligation from Part II, point 3 is not in that table. Until then, you can use the standard for planning, but no more.

Nine requirements define what testing covers

The amendment replaces the verification and validation practice of IEC 62443-4-1 completely. Five requirements become nine, and the numbering shifts throughout.

Requirement	Content	Origin
SVV-1	Independence of testers	previously SVV-5
SVV-2	Testing of functional security requirements	previously SVV-1
SVV-3	Testing 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 testing for load, scaling, and fuzzing	newly assembled
SVV-6	Penetration testing	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 work to the 2018 edition today, 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 testing used to sit under SVV-3 a), while performance, scalability, and stress testing sat under SVV-1 b) and c).

The test grade only affects SVV-3 to SVV-6. Functional testing of the security requirements under SVV-2 is not affected. Whether a role management feature does what it should does not depend on the chosen test grade.

Three grades set the depth of testing

The grades build on each other. STG-2 contains all modules from STG-1, and STG-3 contains all modules from both.

One detail decides how binding this is. Annex G is marked as informative, but the normative clause 4.4 of IEC 62443-4-2 requires you to apply it and to meet the acceptance criteria of all applicable modules. If you only look at the “(informative)” in the annex heading, you underestimate its effect.

STG-1 consists mostly of tool-based tests without logging in to the product: port scan, vulnerability scan, check of the cryptographic protocols, basic fuzzing, and a basic load test. STG-2 repeats the same techniques with a login, because an authenticated scanner sees patch levels and accounts that remain invisible from outside. STG-3 adds manual work: risk-based penetration testing, tailored fuzzing, application-specific load tests, and binary software composition analysis.

The same type of test at three depths

Annex G assigns 21 modules to the three grades: 11 in STG-1, 6 more in STG-2, and 4 in STG-3. A 22nd module sits outside the grades and is optional. The same type of test grows with the grades:

Type of test	STG-1	STG-2	STG-3
Vulnerability scan	unauthenticated; general, web, or OT, depending on the product	the same scans, authenticated	part of the manual pentest
Fuzzing	standardized protocols for which test suites exist	also proprietary protocols and protocols without a ready-made suite	tailored to the threat scenarios of the product
Load test	generic network load across OSI layers 2 to 4	no additional module	manual and application-specific
Components and patch level	validate the SBOM and match it against vulnerability databases	authenticated scan of the patch level	binary software composition analysis across all executables
Undocumented accounts	unauthenticated search with standard tools	authenticated search	manual search for what the tools do not find

Some modules exist only once: the port scan, the malware scan, and the check of the cryptographic communication protocols all sit in STG-1. The optional module for dynamic runtime resource management applies when suitable tools are available.

Where results could be made objective, the module says so

Until now, the tester decided what counts as an acceptable result, and the assessor decided it again later. For the technically unambiguous modules, this ends:

• STM-2: No undocumented open TCP or UDP port. A single one means FAIL.
• STM-8 and STM-17: No persistent critical findings, and the specified minimum function of the product is maintained. Crashes and restarts are not allowed. Sporadic findings that do not recur in five repetitions do not count as vulnerabilities.
• STM-9: Under load, the product keeps its minimum function and recovers afterward without intervention. If no recovery time is specified, a default of 120 seconds applies.

Take a machine controller with a web interface. If you used to document “fuzzing completed, a few reconnects”, you will have to show that there were no restarts and that the minimum function was maintained.

For most modules, however, there is still room for judgment. Their PASS criterion depends on the residual risk that is acceptable in the product context, and the manufacturer still assesses that. Two manufacturers can therefore run the same test grade and still rate the same finding differently.

The test grade follows the risk

SVV-7 requires a process that derives the grade from the threat model and the risk assessment. It explicitly requires you to consider the assumed attackers.

If your attacker model includes targeted manual attacks, tool-based modules are not enough. You know the same logic from the security levels of IEC 62443.

Next comes the applicability check under Annex D of IEC 62443-4-1, and this annex is normative:

1. ASTM-1 checks the technical criteria of the module. A product without a web interface does not need STM-6.
2. ASTM-2 checks applicability based on the risk assessment.
3. ASTM-3 requires documentation: the initial set of modules, a justification for each module removed, and the resulting set.

This third step removes the basis for the usual debate with the assessor. Until now, the argument was about whether a test would have been necessary. In the future, either there is a justified removal or there is not, and the assessor evaluates a justification they can read.

A pentest means manual testing; everything else is a scan

The standard knows three kinds of penetration testing (pentest): purely tool-based, manual, and a combination of both. The tool-based kind is nothing more than a bundle of modules from STG-1 and STG-2, with the added condition that the higher level of tester independence is met. Manual testing is STM-18 in STG-3. Experienced testers work through the specific functions and attack scenarios of the product and can draw on recognized frameworks, such as the OWASP Testing Framework.

In our view, only the manual kind deserves the name. The term is used so loosely that it hardly means anything anymore, and anyone who sells a tool run as a pentest is exploiting exactly that vagueness.

When a pentest is due is fairly easy to define. Major functional changes with a security impact should be tested, for example a new update mechanism, secure boot, or a newly connected authentication service such as Keycloak. So should every major release, which by definition has changed a lot. This costs money, but it finds things your own tests missed. In functional safety, this approach has long been normal. For major changes, manufacturers bring in an independent testing and certification body even without an obligation, to rule out residual risks.

In fuzzing, the method matters most

Annex G gives eight hours per interface and protocol as a guideline for the minimum duration, unless there are reasons for a shorter or longer run.

Eight hours is a useful starting point. Fuzzers that run longer will find more, of course, but the number of hours is the smaller lever. What matters more is how the fuzzer works. With the wrong approach, you fuzz the CRC32 checksum and never the data processing behind it. The product discards every packet immediately, the test report is clean, and the actual parsing logic has never seen an invalid byte.

The standard reflects this progression. STM-8 covers standardized protocols with existing test suites. STM-17 adds proprietary protocols and protocols without ready-made suites, and names three ways to test them:

• tests generated from captured traffic,
• in-house tests built from combined fuzzing modules or on fuzzing SDKs, or
• manual fuzzing by experienced testers.

STM-19 goes further and adapts the tests to the threat scenarios of the product.

Independence is mandatory; suitability is a selection question

SVV-1 sets how far the tester must be removed from the developer.

Type of test	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
Testing of security requirements, testing of threat mitigations	independent department
Penetration tests	independent department or organization

In practice, the top level means buying the service. Only very large groups keep their own pentesters; everyone else buys on the market. Look closely there, because everyone advertises the term and much of what is offered is poor. A provider that mainly tests phishing, classic IT, and web applications is typically not suited to devices and machines. A suitable tester can also show you their method. A tester who cannot will take a cursory look and flag an outdated cipher suite instead of finding real problems in the device. We describe how a pentest works in an industrial setting in penetration testing for machine builders.

The assessor separates method and result

IEC 62443-4-2 brings a normative evaluation methodology in Annex B. Its block EA-9 divides testing into 15 evaluation activities. Four of them are decisive:

1. Independence of the testers under SVV-1.
2. The selected test grade: Is it documented, does it match the result of the risk assessment, and was the applicability check under Annex D applied?
3. Completeness of the test artifacts against the content that SVV-8 specifies.
4. Then, for each type of test, two separate activities: one for the method and one for the result.

A test report without a documented approach therefore fails, even if nothing was found. Without the method behind it, “no findings” leaves open whether anyone looked in the right place. This is why SVV-8 sets minimum content for test plans and test reports: objectives, coverage, method, resources including tools, deliverables, the selected grade with the applicable modules, acceptance criteria, and results.

What manufacturers can prepare now

You can already work on the test structure.

1. Map your existing test capabilities to the modules. Usually the current state covers most of STG-1, parts of STG-2, and none of STG-3.
2. Derive a grade for each product from the threat model and risk assessment, with a written justification. This justification is what the assessor will evaluate.
3. Document every removed module with a reason. It is diligent work, and it saves time in the audit.
4. Align test plans and reports with the content that SVV-8 specifies, instead of collecting tool exports.

If you are setting up your secure development lifecycle right now, plan the test structure as part of it.