We’ll take a closer look at the technical and structural changes introduced in the coming EN IEC 62443-4-2/A11. The A11 amendment represents the transition of the IEC 62443 series, a technical best-practice standard, to a harmonized standard (hEN) designed for legal compliance in the EU and aligned with the CRA.
DISCLAIMER: EN IEC 62443-4-2/A11 is not cited yet. This article is based on draft insights and should not be seen as legal or technical advice.
Structural consolidation: Deletion of device-specific clauses
In the original IEC 62443-4-2 version, these clauses provided differentiated requirements for
- Software applications (clause 12)
- Embedded devices (clause 13)
- Host devices (clause 14)
- Network devices (clause 15)
The A11 amendment replaces these fixed categories with a more dynamic Statement of Applicability (SoA) approach. It represents the move from “static device silos” to a “risk-based, evidence-driven” compliance model. This allows the standard to cover the wide variety of “products with digital elements” required by the CRA without needing a new category for every emerging technology.
Getting to the Statement of Applicability (SoA)
The process, governed by requirement SR-2 (Requirements applicability assessment) in EN IEC 62443-4-1/A11, for creating a Statement of Applicability (SoA) is a structured assessment of applicability that identifies and documents which security requirements apply to a product in a transparent and reproducible manner.
For the Manufacturer, it provides a clear, defensible list of which security controls were implemented and why. For the Evaluator/Notified Body, it serves as the primary “map” for the audit.
The evaluator will verify that your SoA is consistent. If your SoA correctly maps the standard’s requirements to the CRA’s Essential Requirements (via Annex ZZ), your product is legally presumed to be secure.
Requirements in an "audit-ready" format
The A11 amendment moves away from purely descriptive requirements. Every modified Component Requirement (CR) and Requirement Enhancement (RE) now follows a standardized, four-part structure designed for conformity assessment:
- Requirement: A direct statement of the technical capability the component must provide (e.g., “The component shall provide the capability to manage accounts directly…“).
- Rationale and Supplemental Guidance: Explains why the requirement exists and provides additional context.
- Applicability: Defines the specific conditions under which the requirement must be applied to a component (e.g., “Applicable for all components that support more than one fixed administrative account“)
- Recommended requirement-specific evaluation artifacts (& Acceptance Criteria): Lists the evidence (documentation, design files, etc.) an evaluator should check to verify compliance (e.g., a description of the account management capability or a list of configurable network settings).
The annexes
The amendment adds several informative and normative annexes.
Annex ZZ (Informative) Relationship between this standard and the ECRs in the CRA
It is an “informative” annex that provides a formal mapping demonstrating how a manufacturer, by following this standard, satisfies the CRA and grants the presumption of Conformity. While using the standard is technically voluntary, Annex ZZ ensures that if a manufacturer complies with the normative clauses listed in the annex, they are legally presumed to have met the cybersecurity requirements of the CRA.
The core of Annex ZZ is Table ZZ.1, which links specific paragraphs of the CRA Annex I requirements to the technical clauses in EN IEC 62443-4-2/A11. Note that Annex ZZ works in tandem with the equivalent Annex ZZ in EN IEC 62443-4-1/A1.
Annex H (Informative) Threats mapping to CRA ECRs
Provides a “three-way mapping” between legal mandates, technical threats, and specific security controls. Also provides the technical justification by showing exactly which threats are mitigated by which requirements to satisfy the CRA.
The core of Annex H is Table H.1, which organizes information into three interconnected columns:
- ECR: The specific legal clause from Annex I of the CRA.
- EN IEC 62443-4-2/A11 Requirements: The technical Component Requirements (CRs) and Requirement Enhancements (REs) that address the ECR.
- Threats: Specific cybersecurity threats (identified by the CEN/CLC TJ13/WG9 working group) that these requirements are designed to prevent or mitigate.
Annex G (Informative) Security test grades and security test modules
Introduces two core concepts: Security Test Grades (STG) and Security Test Modules (STM), which provide a standardized menu of testing activities to verify that a component actually meets its security requirements.
Security Test Grades (STG)
The methodology defines the depth and rigor of the testing effort required for a component. They are typically mapped to the component’s target Security Level (SL).
STG 1 (Basic)
Focuses on basic vulnerability scanning and functional testing of security requirements.
STG 2 (Standard)
Adds more comprehensive automated testing, such as basic protocol fuzzing and authenticated vulnerability scans.
STG 3 (Advanced)
Requires manual testing and more sophisticated automated tools, including advanced fuzzing for proprietary protocols.
STG 4 (High)
The most rigorous level, involving deep manual penetration testing and comprehensive analysis of all attack vectors.
Security Test Modules (STM)
Standardized “test cases.” Each STM provides a repeatable procedure for verifying a specific requirement in the 4-2 standard.
Annex G STM examples:
- STM-5 (Unauthenticated Vulnerability Scanning): Assessing the component for known vulnerabilities via its network interfaces without using login credentials.
- STM-10 (Malware Scanning): Using state-of-the-art tools to ensure the component’s firmware or software does not contain known malicious code.
- STM-11 (Vulnerability Scanning of Cryptographic Protocols): Assessing implementations like SSL/TLS, SSH, or OPC-UA for configuration errors, weak ciphers, or known bugs like “Heartbleed”.
- STM-15 (Advanced Protocol Fuzzing): Testing proprietary or extended protocols by injecting semi-random data to identify “crashes” or “restarts,” which are strictly prohibited.
- STM-20 (Advanced Manual Application-Specific Load Tests): Manually stressing the component’s applications to test their resilience under heavy load.
Annex B (Normative) Security evaluation methodology
Defines the security evaluation methodology with Evaluation Activities (EA). It transforms the standard from a list of technical requirements into a formal audit framework for verifying that a “Target of Evaluation” (ToE)—the component—actually meets its security claims.
The Evaluation Activities are built on two distinct but complementary principles. First, the Secure Development Lifecycle: The evaluator verifies whether the ToE was developed in accordance with the secure processes specified in EN IEC 62443-4-1/A11 (e.g., threat modeling, secure coding). Second, the Component Requirements: The evaluator examines the technical fulfillment of the specific Component Requirements (CRs) and Requirement Enhancements (REs) defined in EN IEC 62443-4-2/A11.
Annex D (Informative) Mapping of requirement artefacts in 4-1 to evaluation activities
Provides a “lookup table” for auditors and manufacturers between 4-1 requirements and Annex B Evaluation Activities.
Identifies exactly what “paperwork” or evidence (artefacts) from the development process should be used to satisfy the technical steps of an evaluation in Annex B. It prevents manufacturers from having to “reinvent the wheel” for an audit. If they have already followed IEC 62443-4-1, Annex D specifies which existing documents (such as a threat model or an SBOM) they should provide to the evaluator. Also, it ensures that every technical evaluation activity has a clear source in the development lifecycle.
Acts as a roadmap for the Technical Documentation file. By organising their internal 4-1 lifecycle artifacts according to the mappings in Annex D, a manufacturer can present a pre-structured compliance package to a Notified Body, significantly reducing the time and cost of certification.
The core of Annex D is the mapping Table D.1. It links 4-1 requirements to 4-2 evaluation activities. Examples:
4-1 Requirement/artifact: SRM-4 (Threat Model)
4-2 Evaluation Activity: EA-3-2 (Threat Model) and EA-6-1 (Consistency)
4-1 Requirement/artifact: SR-2 (Statement of Applicability)
4-2 Evaluation Activity: EA-4-1 (Applicable Security Requirements), EA-2-9 (Statement of Applicability), EA-4-2 (Non-applicable security requirements), and EA-6-1 (Consistency)
4-1 Requirement/artifact: SVV-6 (Penetration Testing)
4-2 Evaluation Activity: EA-9-13 (Testing methodology) and EA-9-14 (Testing results)
Wrap-up
Here are a few key takeaways:
- From Guidance to Law: The amendment transitions IEC 62443-4-2 from a voluntary “best practice” technical standard into a Harmonized European Standard (hEN). Once cited in the OJEU, it becomes the primary legal mechanism for manufacturers to achieve a “Presumption of Conformity” with the Cyber Resilience Act (CRA).
- Dynamic Applicability: The deletion of device-specific silos (Embedded, Host, Network, Software) marks the end of “one-size-fits-all” compliance. Manufacturers must now use a Statement of Applicability (SoA) to map requirements based on the actual functions and interfaces of their product.
- The Burden of Proof: Compliance is now evidence-driven. It is no longer enough to claim a requirement is met; the standard now explicitly mandates Evaluation Artifacts (design documents, SBOMs, test logs) that must be reviewed by an auditor.
- Standardized Testing (STG/STM): The introduction of Annex G and Annex B removes subjectivity from the certification process. By defining explicit Security Test Grades and Acceptance Criteria, the standard ensures that a “PASS” verdict is consistent regardless of which Notified Body performs the audit.
- Direct Legal Mapping (Annex ZZ): This annex is the “Master Key” for the European market. It provides the definitive link between technical controls and the CRA’s Essential Requirements, allowing the standard to serve as the blueprint for the mandatory EU Declaration of Conformity.
You might think, “This looks very administrative and manual,” which is entirely possible. However, in a modern development environment, we want to automate as much as possible (e.g., in your CI/CD pipelines) and the compliance documentation as well.
In an upcoming article, we’ll also have a closer look at EN IEC 62443-4-1/A11.
See also the next article CRA and internet-connected toys.