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.
For those of us balancing the technical “how-to” of engineering with the “must-do” of compliance, the A11 amendment is the missing link to the CRA. It doesn’t just update security levels; it defines the technical “state-of-the-art” required to legally place industrial components on the European market.
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 should not be considered legal advice or technical recommendations. The main objective is to inspire early action and get ready for the standard’s release, because time is ticking. The content in this article is not an accurate depiction of (the draft) EN IEC 62443-4-2:2019/A11:2026© standard, but rather my interpretation, chosen focus, rephrasing, comments, and structure.
In its quest to convey structure and overview of the Functional Requirements, this article makes extensive use of interactive guides.
Where is EN IEC 62443-4-2/A11in the standards sandwich?
The (not yet cited in OJEU) EN IEC 62443-4-2/A11© inherits from (also not yet cited in OJEU) EN 40000-1-4©.
See also CRA harmonized standards sandwich and EN IEC 62443/A11.
Structural consolidation: Deletion of device-specific clauses
In the 2019 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 the requirement “Requirements applicability assessment” in (not yet in OJEU cited) 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 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“)
- Requirement-specific evaluation artifacts: 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).
- Acceptance criteria: Graduated from SL-C 1 to 4.
The Foundational Requirements
In the 2019 version, the Foundational Requirements focused on whether a security feature existed. With A11, the focus is on how hard it is to break that feature. The requirements are now explicitly designed to withstand “sophisticated entities with significant resources”—a direct reference to the threat actors the CRA targets.
The Foundational Requirements are no longer just technical suggestions. Under Annex H and Annex ZZ, these requirements now constitute legal proof that a product complies with the CRA Essential Requirements.
Below you’ll find my comments and interpretation of the revised Foundational Requirements.
FR 1 - Identification and Authentication Control
The core mission of Foundational Requirement 1 is to ensure that the component can verify the identity of any human user, software process, or device attempting to interact with it. It acts as the “gatekeeper,” ensuring that access is granted only to legitimate entities, thereby preventing unauthorized entry and spoofing.
In the 2019 version, FR 1 was largely about functional hygiene. The A11:2026 amendment transforms this into a requirement for structural resistance.
For the engineering lead, FR 1 is no longer just about adding a login screen. Under the A11 amendment, the “Identification” phase is inextricably linked to the State-of-the-Art (SOTA) benchmarks required for European market access.
If you are targeting Security Level 3 or 4, software-based authentication is likely insufficient. The evaluation methodology (Annex B) now mandates testing against Credential Replay and Brute-Force Resilience. Evaluators will verify that your authentication stack isn’t just “functional” but is technically capable of defending itself against automated, high-velocity attack tools.
By aligning FR 1 with the CRA essential requirements (via Annex H), the amendment ensures that your identity management isn’t just a security feature—it’s a verified legal defense of your product’s integrity.
Key Differences and Strategic Shifts
| Feature | 2019 Baseline | A11:2026 Evolution |
|---|---|---|
| Threat Context | Protection against unauthorized access by generic actors. | Sophisticated resistance: Explicitly designed to withstand targeted harvesting and credential replay by well-resourced entities. |
| Authentication Strength | Standard MFA for untrusted networks. | Hardened MFA: Mandatory phishing-resistant MFA (e.g., FIDO2/Hardware keys) for high-assurance levels (SL-3/4). |
| Default Credentials | Encouraged removal or change of default passwords. | Strict prohibition: Universal default passwords are forbidden to align with the CRA "Secure by Default" mandate. |
| Identity Binding | Basic association of identity to actions. | Forensic binding: Hardened link between authentication and non-repudiable audit trails (FR 6) to support incident reconstruction. |
| Machine Identities | Basic certificate/key management. | Automated lifecycle: Emphasis on secure, automated management of service accounts and machine-to-machine identities to prevent long-lived static secrets. |
EN IEC 62443-4-2/A11:2026
FR 1: Identification & Authentication
FR 2 - Use Control
The objective of Foundational Requirement 2 is to ensure that once an identity is verified (via FR 1), the component strictly enforces the assigned privileges. It is the technical implementation of the principle of least privilege, ensuring that users, processes, and devices can access only the resources and perform only the actions necessary for their specific roles.
In the 2019 version, Use Control was largely centered on the existence of Role-Based Access Control (RBAC). The A11:2026 amendment elevates this by requiring that these controls not only be present but also resilient enough to withstand a “determined entity with sophisticated means.”
For the technical architect, the A11 update means the “Security Kernel” of your component is under much more scrutiny. In the 2019 version, simple user-group mapping might have passed an SL-2 assessment. In A11, the evaluation now focuses on privilege escalation resistance. Evaluators are mandated (via Annex B) to test if a low-privilege service or user can exploit the component’s internal logic to gain administrative rights—simulating the behavior of a well-resourced threat actor.
The introduction of the requirement “Information Security Policy” in A11 means that your Use Control settings can no longer be “floating” configurations; they must be mapped to a machine-readable policy that the component can enforce out of the box. This aligns directly with the CRA’s “Secure by Default” mandates.
| Feature | 2019 Baseline | A11:2026 Evolution |
|---|---|---|
| Privilege Model | Standard RBAC/ABAC implementation. | Hardened least privilege: Permissions must be granular enough to prevent lateral movement by sophisticated actors. |
| Session Security | Basic session timeout and locking. | Resilient session management: Enhanced protection against session hijacking and replay, even when the network environment is partially compromised. |
| Execution Control | Focus on preventing unauthorized software. | Dynamic integrity: Direct link to Clause 4 requirements for preventing the execution of unauthorized code via sophisticated exploitation. |
| Default State | Encouraged "secure by default" settings. | Mandatory policy enforcement: The component must technically enforce a specific "Information Security Policy" that dictates the use-control baseline. |
| Supervisor Override | General requirements for emergency access. | Forensic accountability: Any bypass or supervisor action must be non-repudiable and resistant to audit trail tampering (FR 6). |
EN IEC 62443-4-2/A11:2026
FR 2: Use Control
FR 3 - System Integrity
The goal of Foundational Requirement 3 is to protect the component’s hardware and software from unauthorized modification. It ensures that the device maintains its “operational truth”—verifying that the firmware, OS, and applications running are exactly what the manufacturer intended, without silent tampering or malicious injection.
In the 2019 version, System Integrity was often treated as a detection exercise (e.g., “tell me if a file changed”). The A11:2026 amendment shifts the paradigm to hardened resistance. It assumes a threat landscape in which sophisticated actors attempt to subvert the boot process or compromise the supply chain, thereby necessitating that the component be physically and logically resilient.
For the engineering team, FR 3 is no longer a “check the hash” task. The A11 update brings the SBOM to the forefront of integrity. You cannot claim a system is integral if you cannot prove the provenance of its sub-components.
The evaluation methodology in Annex B now focuses on boot-chain resistance. Evaluators are mandated to verify that the integrity checks begin at the hardware level and cannot be bypassed by an attacker with physical access or sophisticated debugging tools. If your boot sequence isn’t anchored in a hardware-protected secret, achieving higher Security Levels is now structurally difficult.
The alignment with the CRA also means that “System Integrity” now extends to the update mechanism. The component must not only protect its current state but also ensure that any future software updates are cryptographically tied to the manufacturer’s identity, preventing “downgrade attacks” or malicious patching.
Key Differences and Strategic Shifts
| Feature | 2019 Baseline | A11:2026 Evolution |
|---|---|---|
| Threat Profile | General protection against unauthorized software/malware. | Targeted resilience: Specifically designed to resist "sophisticated entities" with the means to bypass standard OS checks. |
| Hardware Anchoring | Suggested but often treated as an optional enhancement. | Mandatory roots of trust: Hardware-backed secure boot (TPM/HSM) is effectively required for SL-3 and SL-4 to meet "state-of-the-art" benchmarks. |
| Integrity Scope | Focused on the presence of unauthorized code. | Supply chain integrity: Directly linked to "System Inventory"; integrity is verified against the machine-readable SBOM. |
| Tamper Resistance | Basic physical and software integrity checks. | Forensic resilience: Protection against tampering with the "Security Kernel" and the logs required for post-incident reconstruction. |
| Code Execution | Focus on signature-based verification. | Advanced anti-exploitation: Mandates protections (like DEP/ASLR and control-flow integrity) to prevent memory-based tampering. |
EN IEC 62443-4-2/A11:2026
FR 3: System Integrity
FR 4 - Data Confidentiality
The core objective of Data Confidentiality is to protect sensitive information—such as process setpoints, proprietary logic, and user credentials—from unauthorized disclosure. It ensures that even if an attacker intercepts communication or gains physical access to storage, the data remains unreadable and useless to them.
In the 2019 version, confidentiality was often treated as a “checkbox” item: if you had encryption, you were largely compliant. The A11:2026 amendment changes the game by introducing the concept of State-of-the-Art (SOTA). It moves away from generic encryption and mandates specific cryptographic strengths designed to resist “sophisticated entities with significant resources.”
For the engineering team, FR 4 is no longer just about choosing a library. The A11 amendment requires a deep dive into your Entropy and Key Lifecycle. Because the threat actor profile now includes entities with extended resources, “standard” implementations are scrutinized for weaknesses in how keys are generated, stored, and rotated.
If you are targeting SL-3 or above, software-only encryption is effectively dead. The evaluation methodology (Annex B) now looks for side-channel attack resistance. Evaluators will verify that your hardware-backed keys cannot be extracted through power analysis or timing attacks—methods commonly used by the “sophisticated entities”.
Furthermore, the requirement for 128-bit effective strength means you need to account for the weakest link in your crypto chain. If your key exchange is weak, it doesn’t matter how strong your AES-256 cipher is; the A11 amendment requires the entire process to meet the 128-bit threshold.
Key Differences and Strategic Shifts
| Feature | 2019 Baseline | A11:2026 Evolution |
|---|---|---|
| Crypto Standard | General industry standard algorithms. | Mandatory SOTA: Must align with latest EU standards (e.g., ENISA/SOG-IS) to meet CRA requirements. |
| Security Strength | Recommended for high SLs. | Strictly mandated: 128-bit effective security strength is the hard floor for SL-3 and SL-4. |
| Key Protection | Secure software-based storage. | Hardware-anchored: Cryptographic keys must be protected by hardware roots of trust (TPM/HSM) at higher levels. |
| Data at Rest | Focused on high-sensitivity data. | Forensic focus: Protection of configuration and log data is prioritized to prevent "track-erasing" by advanced actors. |
| Regulatory Link | General best practice. | CRA presumption: Directly satisfies the legal requirement for confidentiality in the CRA. |
EN IEC 62443-4-2/A11:2026
FR 4: Data Confidentiality
FR 5 - Restricted Data Flow
The core objective of Restricted Data Flow is to segment the network into logical and physical zones, ensuring that communication only occurs through defined conduits. It is the primary defense against the “blast radius” of a breach—ensuring that if one zone is compromised, the threat cannot propagate across the entire industrial control system.
In the 2019 version, FR 5 was often seen as a “network infrastructure problem” rather than a component requirement. The A11:2026 amendment pulls this responsibility squarely into the component’s architecture. It shifts from simple Access Control Lists (ACLs) to a model of active resistance, assuming the attacker is a “sophisticated entity” capable of protocol-level manipulation.
For the network and systems architects, the A11 update means the component can no longer be a “dumb” endpoint. It must actively participate in the security of its own conduits. In the 2019 version, you might have relied entirely on a perimeter firewall to handle data flow.
The evaluation now focuses on protocol hardening. Evaluators are mandated (via Annexes B and G) to perform fuzzing and malformed-packet testing on the communication interfaces. They are looking to see whether your component can maintain its restricted data-flow state even when bombarded with sophisticated, non-standard traffic designed to bypass traditional filters.
Key Differences and Strategic Shifts
| Feature | 2019 Baseline | A11:2026 Evolution |
|---|---|---|
| Segmentation Goal | Prevent unauthorized communication. | Inhibit lateral movement: Specifically designed to stop "sophisticated entities" from traversing the network. |
| Filtering Depth | Port and IP-based filtering (L3/L4). | Deep Packet Inspection (DPI): Mandates application-layer and protocol-aware filtering for high-assurance levels (SL-3/4). |
| Isolation Level | Logical segmentation (VLANs/VPNs). | Physical vs. logical isolation: Stricter mandates for physical isolation or hardware-enforced separation for critical safety/security functions. |
| Conduit Enforcement | General traffic management. | Dynamic policy alignment: Must technically enforce the "Information Security Policy" regarding allowed data paths. |
| Regulatory Context | Internal network hygiene. | CRA Essential Requirement: Provides the technical proof of "network protection" mandated by the CRA. |
EN IEC 62443-4-2/A11:2026
FR 5: Restricted Data Flow
FR 6 - Timely Response to Events
The objective of Foundational Requirement 6 is to ensure that the component provides the necessary visibility into security-relevant events. It’s the “black box” recorder for industrial systems—generating, protecting, and reporting audit trails that allow security teams to detect violations in real-time and reconstruct high-stakes incidents after the fact.
In the 2019 version, FR 6 was often treated as a passive storage requirement. The A11:2026 amendment transforms this into a requirement for forensic readiness. It specifically demands that the logging system is resilient enough to capture the movements of “sophisticated entities” who actively try to disable monitoring or erase their tracks.
For the developer and compliance engineer, FR 6 moves from “just saving a text file” to a security kernel function. If you are targeting Security Level 3 or 4, your logging mechanism must survive even if other parts of the system are compromised.
The evaluation methodology in Annex B now prioritizes audit processing failure scenarios. The evaluator will test whether your component can be “blinded” by flooding it with traffic, or whether it enters a secure state (or halts) when the log buffer is full.
Under the A11 amendment, the logs are also expected to support the “System Inventory“. This means your events shouldn’t just say “Unauthorized Access,” but should provide the machine-readable context (who, what, which sub-component) needed for automated risk management in a modern SOC.
Key Differences and Strategic Shifts
| Feature | 2019 Baseline | A11:2026 Evolution |
|---|---|---|
| Audit Objective | General recording of security events. | Forensic reconstruction: Logs must be granular enough to reconstruct the actions of highly skilled actors. |
| Log Protection | Basic access control to log files. | Non-repudiation: Mandates that log entries are protected against modification/deletion by entities with "significant resources." |
| Time Sync | Requirement to sync internal clocks. | Secure time integrity: Uses secure protocols to prevent time-skew attacks designed to confuse forensic timelines. |
| Timestamping | Standard resolution. | High granularity: Specifies minimum resolution requirements to capture high-speed automated attack sequences. |
| Alerting Speed | Notification of security violations. | CRA-aligned real-time alerting: Direct link to EU reporting mandates for rapid incident notification (e.g., within 24 hours). |
EN IEC 62443-4-2/A11:2026
FR 6: Timely Response to Events
FR 7 - Resource Availability
The primary objective of Foundational Requirement 7 is to ensure the continuous operation of the component’s security and functional capabilities, even during a security event. It focuses on mitigating Denial of Service (DoS) attacks, managing internal resource exhaustion, and providing the redundancy necessary for high-availability industrial environments.
In the 2019 version, FR 7 was a relatively narrow technical requirement focused on network and processing limits. The A11:2026 amendment transforms FR 7 into a cornerstone of supply chain transparency and policy enforcement. By adding entirely new requirements for inventories and security policies, the amendment ensures that availability is supported by a clear understanding of the component’s internal makeup and its intended security baseline.
The inclusion of “System Inventory” is the most significant technical hurdle for many engineering teams. It moves the component from a “black box” to a transparent entity. You are now required to provide a machine-readable SBOM, such as CycloneDX or SPDX, to allow for automated vulnerability management.
FR 7 now bridges the gap between hardware/software engineering and vulnerability management. The evaluation methodology (Annex B) will verify not only whether the system stays “up,” but also whether the manufacturer can provide the granular data necessary to protect the system throughout its lifecycle.
Additionally, “Information Security Policy” requires that the component not only be “configurable” but also be locked down to a technical policy defined by the manufacturer. This supports the CRA mandate for Secure Default Configurations, ensuring the device arrives out of the box in a state that resists common exploits.
Key Differences and Strategic Shifts
| Feature | 2019 Baseline | A11:2026 Evolution |
|---|---|---|
| Availability Goal | Prevent service interruption from DoS. | Resilient continuity: Protection of the security kernel and critical functions against "sophisticated entities." |
| System Inventory | Not explicitly required as a technical control. | Mandatory SBOM/HBOM: New requirement for machine-readable lists of all software/hardware sub-components. |
| Policy Control | Manual or configuration-based settings. | Technical policy enforcement: New requirement for the component to technically enforce a manufacturer-defined security policy. |
| Resource Limits | Focus on network and memory exhaustion. | Prioritization of security: Mandates that resources for logging and monitoring are prioritized over non-critical tasks during an attack. |
| Regulatory Link | General availability best practices. | CRA presumption: Directly satisfies the CRA mandates for supply chain transparency and secure-by-default configurations. |
EN IEC 62443-4-2/A11:2026
FR 7: Resource Availability
Security Level Architecture
The Security Level (SL) architecture is a qualitative framework for defining a component’s resistance to specific threat actor profiles. It categorizes security into four distinct levels (SL-C 1–4), where each level represents a significant increase in the technical capability, resources, and motivation required for an attacker to successfully compromise the system.
In the 2019 version, Security Levels were largely descriptive and functional. The A11:2026 amendment retools the entire SL architecture to serve as a legal benchmark for “State-of-the-Art” security under the CRA. A11 shifts the focus from what a component has to what it can resist.
For engineers and compliance officers, the A11 amendment clarifies the “why” behind the “what.” In the 2019 version, achieving SL-3 was often seen as an aspirational goal for high-criticality assets.
The Security Level is now a hardened boundary. At higher levels, the amendment mandates that the “Security Kernel”—the core code responsible for enforcing FRs—must be isolated and protected from the rest of the application. The evaluation methodology now requires evidence that even if a non-critical part of the component is breached, the SL-rated security functions remain intact.
By making the evaluation methodology (Annex B) normative and the regulatory mapping (Annex ZZ) explicit, the SL architecture is no longer just a technical rating—it is a legal certification of a product’s resilience within the European market.
Key Differences and Strategic Shifts
| Feature | 2019 Baseline | A11:2026 Evolution |
|---|---|---|
| Threat Actor Focus | Defined by general skill levels (e.g., "IACS-specific skills"). | Resource-centric: Specifically redefines SL-3 and SL-4 based on the attacker's "sophisticated means" and "extended resources." |
| SL-3 & SL-4 Threshold | High-level protection against professional hackers. | Sovereign/APT defense: Redefined to target the resilience needed against state-sponsored actors and advanced persistent threats (APTs). |
| Evaluation Impact | Informative mapping of activities. | Normative methodology: The new Annex B makes the evaluation of these levels mandatory and structured, focusing on technical verification. |
| Resistance Descriptors | Focused on the "intent" of the actor. | Capability-based: Focuses on the "means" of the actor, requiring components to prove they can withstand specific, targeted attack vectors. |
| Compliance Link | Voluntary industry best practice. | Presumption of conformity: Directly bridges technical SLs to the legal essential requirements of the CRA (via Annex ZZ). |
EN IEC 62443-4-2/A11:2026
Security Level Architecture CRA Alignment
Annexes
The shift in the Annexes is a significant part of the A11:2026 amendment. In the 2019 version, the Annexes were largely “educational” guides. They are no longer “extra reading”—they are the core instructions for how your product is tested, judged, and legally cleared for sale in the EU.
- Annex A [Informative]: Mapping of CRs to SL-Cs. Which component requirements apply to which FRs for a given capability security level
- Annex B [Normative]: Evaluation methodology. Mandatory evaluation activities performed by the evaluator.
- Annex C [Informative]: Component specification. A bundle of component artifacts resulting from the SDL.
- Annex D [Informative]: EN IEC 62443-4-1 requirements mapped to evaluation activities in Annex B.
- Annex E [Informative]: Evaluation overview. Activity type check or examine from Annex B.
- Annex F [Informative]: Evaluation activities (Annex B) related to TS 62443-6-2:2025 (standardized methodology for evaluating the security of IACS components against requirements defined in IEC 62443-4-2)
- Annex G [Informative]: Security Test Grades & Security Test Modules. Supporting SVV requirements in EN IEC 62443-4-1.
- Annex H [Informative]: Threats related to CRA ECRs.
- Annex ZZ [Informative, but in practice mandatory]: Relationship between this standard and the CRA ECRs.
Wrap-up
We have essentially watched the EN IEC 62443-4-2 standard grow up from a technical “best practice” manual into a high-stakes legal enforcement tool.
The A11:2026 amendment isn’t just a patch; it’s a structural re-engineering designed to align industrial automation with the reality of modern threat actors and the mandates of the CRA.
The most profound shift is the transition from voluntary compliance to the presumption of conformity. By mapping technical controls directly to the CRA’s essential requirements via Annex ZZ, the standard now serves as a legal passport for the European market. If you meet the SL-rating, you’ve legally proven “state-of-the-art” security.
The Foundational Requirements (FR 1–7) have been retooled to resist “sophisticated entities with significant resources.” The introduction of “SBOM” and “Policy Enforcement” turns the component from a black box into a transparent, policy-governed entity. We now have a hard 128-bit cryptographic floor for high-assurance levels and a heavy push toward hardware roots of trust.
Testing is no longer a suggestion. The promotion of Annex B to normative status means that the way you evaluate a product is now as mandatory as the requirements themselves. In Annex G, we now have 11 specific Security Test Modules (STMs) and three Security Test Grades (STGs) that dictate exactly how much “pain” an evaluator must inflict on your component to verify its SL rating.
In 2019, security was often an add-on to a product. In the 2026 reality defined by the A11 amendment, security is a property of the product’s existence. For the technical team with a compliance eye, this means:
- Evidence is everything: If you can’t produce the machine-readable SBOM or the forensic audit trail, the feature might as well not exist.
- Supply chain is the new frontline: Vulnerability management now requires a deep, automated understanding of every sub-component.
- Resistance over functionality: It’s not enough that the MFA “works”; it must be proven to resist a sophisticated harvester.
You’re no longer just building a controller or a switch; you’re building a certified secure asset. It’s a heavier lift, but the roadmap is finally clear.
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 the (not yet cited in OJEU) EN IEC 62443-4-1/A11©.
See also the next article CRA and internet-connected toys.