I’ve created an online tool to help my customers get an overview of and apply the Security Evaluation Methodology in EN IEC 62443-4-2:2019/A11:2026©.
I aim to get as close as possible to the actual (to come) EN IEC 62443-4-2:2019/A11:2026© standard. For that reason, I cannot share a link to the tool. I will, however, share screenshots from the tool to illustrate its structure.
The rationale for the tool is the same as that for the EN IEC 62443-4-1:2018/A11:2026 audit tool: Enable my customers with a guiding star and transparency.
DISCLAIMER: EN IEC 62443-4-2:2019/A11:2026© has not yet been cited in OJEU and is still in the works. This article is based on draft insights and my interpretation and should not be considered legal advice or technical recommendations.
Annex B
Annex B (Normative) in EN IEC 62443-4-2:2019/A11:2026 establishes the formal Security Evaluation Methodology used by auditors and independent testing bodies to assess whether an industrial automation and control system (IACS) component complies with the technical security requirements defined in the core text of the harmonized standard (not yet cited in OJEU) EN IEC 62443-4-2:2019/A11:2026©.
While the main body of the standard dictates what a component must do to achieve a specific Security Level (SL-1 through SL-4), Annex B provides the operational blueprint for how an evaluator must verify those capabilities. Its primary purpose is to transform subjective engineering assessments into a reproducible, standardized compliance framework.
Annex B enforces a strict, multi-phased methodology that categorizes the 47 Evaluation Activities (EAs) into three distinct steps. This structured progression ensures that structural lifecycle validity and technical specifications are verified before deeper physical or dynamic testing occurs.
Step 1: Secure development lifecycle and ACS component specification (EA-1 to EA-6): Verifies that the component was engineered using secure-by-design principles (fully aligned with EN IEC 62443-4-1 process parameters), establishes the Target Security Level, defines the security context/intended use boundaries, and treats native design risks.
Step 2: Security requirements (EA-7): Audits the engineering team’s internal testing artifacts, structural review methodology, and test cases to ensure full validation coverage over all applicable capabilities.
Step 3: Component protection and security guidelines (EA-8 to EA-9): Focuses on user-facing documentation (hardening, operational, account management, and disposal guidance) alongside hands-on validation. This phase mandates evaluating the independence of testers and conducting specialized testing techniques, including Static Application Security Testing (SAST), Vulnerability Scanning, Penetration Testing, and Robustness/Fuzz testing.
A core purpose of Annex B is to bind EN IEC 62443-4-2 (component-level technical features) directly to EN IEC 62443-4-1 (secure product development lifecycle processes). In the “References” section of every Evaluation Activity, Annex B links to the explicit 4-1 process elements.
This approach ensures that a technical feature is not merely ticked off as “present” in the software, but that its inclusion is backed by verified, sustainable engineering practices.
To achieve global mutual recognition of certifications, the methodology eliminates ambiguity among evaluators by organizing all assessment criteria into four strict, unalterable subsections.
(1) Requirement: Precise directions framing what the evaluator must investigate (e.g., “The evaluator shall examine…” or “The evaluator shall check if…”).
(2) Rationale & Guidance: The baseline intent of the evaluation activity and the technical parameters that the auditor should understand.
(3) Acceptance Criteria: The objective line of demarcation defining compliance. It dictates that the final verdict PASS is assigned only if specific source artifacts are available and meet the minimum standards.
(4) References: The definitive sub-clauses from EN IEC 62443-4-1 or the technical profile requirements that provide legal and technical justification for the activity.
For product suppliers, Annex B removes the guesswork from audit preparation. For asset owners and system integrators, Annex B serves as an assurance mechanism. It guarantees that an ecosystem component certified under EN IEC 62443-4-2 has undergone a rigorous, non-arbitrary evaluation, confirming that its operational defensive capabilities are stable, thoroughly tested, and resilient against modern adversarial threats.
The overall tool design approach
The main features of the tool MVP version (I’ll probably post a new article with an enhanced version at a later time) are
- Detailed audit cards for each of the 47 Evaluation Activities
- Overall progress indicator
- Search
- A 62443-4-1 reference explorer
- Summary report with Markdown export
- Session export and load (JSON)
- Randomized example population of the tool with hypothetical data
The 62443-4-1 reference matrix
The three steps
An example shown for each of the three steps.
Wrap-up
In accordance with EN IEC 62443-4-2:2019/A11:2025 Annex B, the tool is intended to proactively guide IACS component development over time with an auditor mindset. It is currently at an MVP level but has the potential to expand. It must pass the audit of an auditor.
Graphics and tools created with AI support