This article takes a closer look at the forthcoming (not yet cited in OJEU) EN IEC 62443-4-1:2018/A11:2026© harmonized standard.
The primary objective of the A11 amendment is to align the standard’s requirements and associated clauses with the CRA essential cybersecurity requirements.
DISCLAIMER: EN IEC 62443-4-1:2018/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. Time is ticking. The content in this article is not an accurate depiction of (the draft) EN IEC 62443-4-1:2018/A11:2026©, but rather my interpretation, chosen focus, rephrasing, comments, and structure.
In its quest to convey structure and provide an overview, this article uses interactive guides.
Where is EN IEC 62443-4-1/A11in the standards sandwich?
You may recall how the (not yet cited in OJEU) EN IEC 62443-4-2/A11© is situated in “the standards sandwich”. While EN IEC 62443-4-2/A11© covers technical requirements, EN IEC 62443-4-1/A11© covers processes.
As indicated to the right, EN 62443-4-1/A11© inherits from both (not yet cited in OJEU) EN 40000-1-2© and from (not yet cited in OJEU) EN 40000-1-3©. Note A11 Annexes F and G with mappings to EN 40000-1-2 and EN 40000-1-3.
The helicopter view - what is new
The transition from the 2018 version to the (not yet cited in OJEU) EN IEC 62443-4-1:2018/A11:2026 introduces a more rigorous, risk-driven approach specifically tailored to the CRA requirements. The most significant change is the addition of a completely new practice, Practice 2 – Security risk management. Also, significant changes are found in the annexes.
Infographic #1 aims, with examples, to summarize the key changes with A11.
Harmonized EN IEC 62443-4-1 Evolution
Key Changes with the A11 amendment
Table of requirements
InformativeA consolidated summary mapping all normative requirements of the standard.
Product security context category
NormativeParameters to identify the intended operational environment and security profile.
Applicability of security requirements and risk workflow
NormativeThe technical workflow for integrated risk management and requirement applicability.
Identification and documentation of security test modules
NormativeActivities required for verification and validation based on Security Profile.
Statement of applicability – Documentation template
InformativeRecommended format for documenting the SoA for conformity assessment.
Mapping of EN 40000-1-2 to EN IEC 62443-4-1
InformativeAlignment with horizontal cyber resilience standards at a granular level.
Mapping of EN 40000-1-3 to EN IEC 62443-4-1
InformativeMapping between standard requirements and 'EN 40000-1-3' to ensure coherence.
Infographic #1
A step deeper into the nine A11 practices
As outlined above, one new practice (P2) is introduced with A11, but the existing practices have been modified. Here we’ll take a closer look.
Practice 1: Security Management
EN IEC 62443-4-1:A11 transitions Practice 1 from internal governance to a regime of supply chain accountability. While the 2018 edition focused on establishing foundational processes, the harmonized amendment mandates transparency aligned with the CRA.
A critical evolution is the formalization of the new ‘Component Inventory’ requirement. Previously treated as an informal development task, it is now a normative requirement providing the baseline for all subsequent risk assessments. This inventory underpins the mandatory delivery of a machine-readable SBOM. See e.g., CRA recital 22. By requiring standardized formats such as CycloneDX or SPDX, the standard ensures that vendors provide the granular visibility that asset owners need to monitor third-party vulnerabilities independently.
Practice 1 now includes a management process for mandatory reporting in alignment with the CRA. See e.g., CRA article 14. Beginning SEP 11 2026, reporting of actively exploited vulnerabilities and significant security incidents must happen to ENISA (European Union Agency for Cybersecurity) and national authorities.
The Security Management process is now responsible for overseeing the creation and maintenance of the technical documentation. See e.g., CRA article 31. This includes ensuring that all other practices (from Practice 2’s risk assessment to Practice 9’s guidelines) are documented in a way that establishes “presumption of conformity” for regulatory auditors.
Alignment with the CRA is evident in the refined requirements for the security support lifespan. The A11 amendment replaces private vendor-customer agreements with a mandate for public transparency. Manufacturers must now explicitly state the minimum duration of security updates, enabling asset owners to assess product longevity during procurement. CRA article 13(8) links support to the expected product lifetime, which must be at least 5 years unless the product’s life is shorter.
Organizational maturity also receives stricter focus. Personnel expertise now requires verified, role-specific skills rather than general security awareness. Furthermore, the standard enforces continuous maturity improvement, requiring manufacturers to use security incident data and internal audits to iteratively refine their Secure Development Lifecycle (SDL).
Ultimately, Practice 1 has shifted from a management policy to a verifiable chain of trust. By codifying component visibility and public support commitments, the A11 amendment ensures that a product’s security DNA is transparent to all stakeholders in the industrial ecosystem.
Infographic #2 aims to illustrate the revised Practice 1 with examples.
EN IEC 62443-4-1 Evolution
Practice 1: Security Management
Infographic #2
Practice 2: Security Risk Management (NEW)
The elevation of Security Risk Management to a standalone Practice is the most disruptive structural change in the EN IEC 62443-4-1:A11 amendment. While the 2018 version treated risk as a distributed concern integrated across design and requirements, A11 centralizes it into a dedicated engine that dictates the entire development strategy. This transition reflects the risk-centricity required by the CRA, moving beyond generic security features toward a product-specific threat posture.
A primary evolution is the normative requirement for defining Intended Use. See e.g., CRA article 13(3). Previously, scoping was often an informal prerequisite. Under A11, it is a formal mandatory input that establishes the product’s operational boundaries and environmental assumptions before technical work begins. This definition directly feeds the Threat Modeling process, which has transitioned from a recommended best practice to a core normative requirement. Manufacturers must now systematically identify potential attack vectors based on the product’s specific functionality and deployment context.
The most critical change within this practice is the introduction of Threat Model Verification. Unlike the 2018 standard, which focused on identifying threats at the design stage, the A11 amendment closes the loop by requiring manufacturers to verify that the final implementation actually mitigates the risks identified in the model. This ensures that the security architecture is not merely a theoretical exercise but a validated defense against real-world attack scenarios.
While Practice 2 defines the risk posture and required mitigations, Practice 6 (Security verification and validation testing) is the clause in which the supplier verifies, through testing, that the product meets those specific requirements.
Infographic #3 aims to illustrate the new Practice 2 with examples.
EN IEC 62443-4-1 Evolution
Practice 2: Security Risk Management
Infographic #3
Practice 3: Specification of Security Requirements
Practice 3 transitions Security Requirements from a static checklist to a risk-justified scoping process. While the 2018 version treated the applicability of requirements as a general management task, EN IEC 62443-4-1:A11 formalizes the Applicability Assessment as the critical junction between initial risk analysis and technical implementation.
This assessment now mandates a direct downstream link to the Practice 2 risk ratings, ensuring every selected requirement is a documented response to a verified threat. The centerpiece of this evolution is the Statement of Applicability (SoA), supported by the standardized template in the new Annex E. This document is a normative prerequisite for certification, requiring manufacturers to provide a transparent, auditable rationale for the inclusion or exclusion of specific requirements.
By adopting this formalized SoA model, the harmonized standard replaces informal scoping with a rigorous record that justifies a product’s security capabilities. This ensures that the final technical requirements are precisely tailored to the product’s intended use and operational context, rather than relying on generic security assumptions.
Infographic #4 aims to illustrate the revised Practice 3 with examples.
EN IEC 62443-4-1 Evolution
Practice 3: Requirements Specification
Infographic #4
Practice 4: Secure by Design
Practice 4 in EN IEC 62443-4-1:A11 evolves from traditional architectural planning to a normative implementation of risk-based design principles. While the 2018 version emphasized foundational security concepts, the A11 amendment mandates a direct, traceable relationship between the system architecture and the Practice 2 threat model. This shift ensures that every design decision—such as the application of Defense in Depth or Least Privilege—is a documented mitigation of a specific, rated risk.
A significant pivot in the new standard is the prioritization of Secure-by-Default configurations, aligning with the CRA’s requirements for inherent security. See e.g., CRA annex I part I (1). The design process must now demonstrably minimize the attack surface and utilize validated cryptographic modules, moving beyond general suggestions toward strict design modules. By integrating the workflow mapping from the new Annex C, Practice 4 ensures that the system architecture is not merely a technical layout but a verified defense structure that justifies the security capabilities defined in Practice 3.
Infographic #5 aims to illustrate the revised Practice 4 with examples.
EN IEC 62443-4-1 Evolution
Practice 4: Secure Design
Infographic #5
Practice 5: Secure Coding & Implementation
Practice 5 transitions from a general adherence to coding standards to a rigorous, tool-driven verification process. While the 2018 version encouraged secure coding as a best practice, the A11 amendment mandates specific technical measures to ensure the implementation is objectively free of common weaknesses and logic flaws.
The most significant change in this practice is the formal requirement for Static Application Security Testing (SAST). In the previous edition, automated static analysis was a recommended methodology. Under the harmonized standard, it is an explicit normative mandate. This ensures that source code is systematically scanned for vulnerabilities—such as buffer overflows, memory leaks, or injection points—at the earliest possible stage. By codifying the use of these tools, the standard moves beyond the variability of manual code reviews toward a consistent, auditable baseline for code quality.
Furthermore, EN IEC 62443-4-1/A11 emphasizes the enforceable application of secure coding standards (such as MISRA, OWASP, or SEI CERT). Practice 5 now requires documented proof of compliance, with any deviations formally justified and risk-assessed. This structured approach prevents implementation-level vulnerabilities from reaching the testing phases, directly supporting the “secure-by-default” objectives of the CRA.
Infographic #6 aims to illustrate the revised Practice 5 with examples.
EN IEC 62443-4-1 Evolution
Practice 5: Secure Implementation
Infographics #6
Practice 6: Security Verification and Validation
Practice 6 transitions from general technical testing to a rigorous, profile-driven validation framework. While the 2018 version required “independent” testers, the A11 amendment provides significantly more granular definitions of independence to facilitate third-party certification and CRA conformity assessments. This shift ensures that the verification process remains objective and isolated from the development team’s internal pressures.
A fundamental change in the new standard is the introduction of Annex D (Security Test Modules). This normative annex formalizes the testing scope by specifying mandatory modules—such as vulnerability scanning, robustness testing (fuzzing), and penetration testing—based on the product’s security profile. This replaces the previous standard’s more flexible testing approach with a standardized matrix, ensuring consistent test coverage across all industrial products under the same profile.
Furthermore, the harmonized standard enforces a direct feedback loop between testing results and the Practice 2 threat model. Verification is no longer an isolated phase but a mandatory validation of the risk mitigations identified earlier in the lifecycle. By requiring documented proof that technical tests successfully address the rated threats, Practice 6 serves as the final evidence-based gate for a product’s security posture before release.
Infographic #7 aims to illustrate the revised Practice 6 with examples.
EN IEC 62443-4-1 Evolution
Practice 6: Verification & Validation
Infographics #7
Practice 7: Security Issue Handling
Practice 7 transitions from private bug-fixing to a regime of structured, public-facing accountability. While the 2018 standard focused on internal defect handling and direct customer notifications, the A11 amendment mandates a Coordinated Vulnerability Disclosure (CVD) policy. This normative shift requires manufacturers to maintain a public channel for receiving and processing vulnerability reports from external researchers, thereby aligning industrial practices with the transparency requirements of the CRA.
A pivotal change in the harmonized standard is the adoption of machine-readable advisory formats. The new version moves beyond traditional PDF release notes, requiring the use of the Common Security Advisory Framework (CSAF) and Vulnerability Exploitability eXchange (VEX). This ensures that vulnerability data can be ingested automatically by asset owners, closing the loop between the manufacturer’s disclosure and the user’s risk monitoring.
Furthermore, Practice 7 is now intrinsically linked to the Practice 1 SBOM. Manufacturers must not only identify defects in their own code but also monitor and report vulnerabilities in the third-party components listed in their bill of materials throughout the defined support lifespan. This evolution transforms vulnerability management from a reactive maintenance task into a proactive, transparent security service that maintains the product’s integrity in the field.
Infographic #8 aims to illustrate the revised Practice 7 with examples.
EN IEC 62443-4-1 Evolution
Practice 7: Issue Management
Infographics #8
Practice 8: Security Updates and Patching
Practice 8 transitions from discretionary patching to a regulated maintenance lifecycle. While the 2018 standard focused on the general capability to provide updates, the A11 amendment introduces specific mandates for delivery and transparency that align industrial products with CRA.
The most critical change is the requirement for decoupled security updates. In the 2018 version, security fixes were frequently bundled with functional upgrades, forcing asset owners to accept operational changes to obtain a security patch. The harmonized version now requires manufacturers to provide separate, security-only patches. This ensures that critical vulnerabilities can be remediated instantly, without the downtime or extensive revalidation required for functional system changes.
Furthermore, the standard now mandates automatic update notifications. Manufacturers must establish proactive systems to alert users of available security updates, moving away from reactive, manual notification models. These updates must also undergo rigorous qualification before release to ensure they do not compromise the established security profile or introduce regressions in existing mitigations. By codifying these delivery mechanisms, Practice 8 ensures that the product’s security posture remains resilient and verifiable throughout its entire support lifespan.
Infographic #9 aims to illustrate the revised Practice 8 with examples.
EN IEC 62443-4-1 Evolution
Practice 8: Security Update Management
Infographics #9
Practice 9: Security Guidelines
Practice 9 transitions user documentation from an administrative byproduct to a normative requirement for secure integration and operation. While the 2018 version treated guidelines as a subset of general management tasks, the A11 amendment establishes them as a standalone practice, ensuring the “human interface” of security is as rigorously validated as the software itself.
The most significant change is the introduction of documentation review. This new requirement mandates a formal verification process to ensure that all security guidelines are accurate, complete, and technically consistent with the final product implementation. This shift aligns with the CRA’s focus on providing clear, actionable instructions, preventing the common failure point where a product’s security is compromised by incorrect user configuration.
Furthermore, Practice 9 serves as the primary vehicle for communicating the Intended Use and residual risks identified in Practice 2. Guidelines must now explicitly cover hardening procedures, secure decommissioning, and the management of administrative credentials. By elevating these instructions to a dedicated practice, the standard ensures that the asset owner possesses the verified knowledge necessary to maintain the product’s security posture throughout its operational life.
Infographic #10 aims to illustrate the revised Practice 9 with examples.
EN IEC 62443-4-1 Evolution
Practice 9: Product Security Information
Infographics #10
The Maturity Model
A11 uses a refined maturity model to measure a developer’s adherence to these practices. For a manufacturer to claim a presumption of conformity under the CRA using EN IEC 62443-4-1, the demanded level is Maturity Level 3 (ML3).
NOTE: If your product is categorized as an “Important” (Class I or II) or “Critical” product under the CRA, ML3 is non-negotiable. For unclassified (“Default”) products, although the law is slightly more flexible, following ML3 remains the safest legal harbor for avoiding liability.
To meet the “Presumption of Conformity” at ML3, your development lifecycle must, in essence, demonstrate:
Security by Design
Evidence that security requirements were defined at the start of the product lifecycle, not bolted on at the end.
Vulnerability Management
A formal process for receiving, reviewing, and remediating vulnerabilities (matching the CRA’s strict reporting timelines).
Secure Coding Standards
Mandatory use of analyzed and vetted coding practices.
Integrity of Delivery
Ensuring the software/firmware cannot be tampered with during the distribution process (e.g., code signing).
Artifact Persistence
Maintaining documentation for the duration of the product’s expected lifetime (or 10 years, as per CRA). See e.g., CRA article 13(9).
Infographic #11 aims to illustrate the maturity model.
Process Capability Evolution
EN IEC 62443-4-1/A11 Maturity Model
Level 3: Defined
The primary baseline for product certification. The SDL is integrated into the organization's standard workflow and practiced across all projects. Verifiable evidence (artifacts) must exist to prove that these standardized processes are followed by all personnel without exception.
Organizational standard integrated into the unified development workflow with mandatory artifact generation.
Infographics #11
Wrap-up
The evolution of the standard to (still in draft and not yet cited in OJEU) EN IEC 62443-4-1:2018/A11:2026 represents a fundamental maturation of the secure product development lifecycle by elevating risk management from a technical subtask to a primary governing practice. This structural overhaul is most visible in the insertion of the Security risk management practice as the new Practice 2, which has subsequently re-indexed all technical specifications and design practices. This change ensures that security controls are no longer applied in a vacuum but are instead strictly derived from a formalized Product security context and a rigorous Requirements applicability assessment. By establishing this clear bridge between the operational environment and technical requirements, the standard now necessitates a risk-proportionate justification for every security decision made throughout the development process.
Furthermore, the updated standard moves away from the “point-in-time” compliance mindset that often characterized the 2018 version. The introduction of the Monitoring and review of security risks requirement and the Regular product security reviews requirement forces organizations to treat security as a continuous lifecycle activity rather than a one-off certification milestone. This operational shift is reinforced by the inclusion of modern supply chain transparency controls, most notably the Software Bill of Materials (SBOM) and a mandatory Policy on vulnerability handling. These additions effectively transform the standard from a design-focused guideline into a robust operational framework capable of meeting the rigorous transparency and long-term maintenance demands found in CRA.
Finally, the increased normative weighting of the new annexes provides the technical foundation required for this risk-driven model. Specifically, the mandatory workflows in Annex B and Annex C standardize how product categories are determined and how the security risk management process must be executed, leaving significantly less room for subjective interpretation during audits. In essence, the evolution to EN IEC 62443-4-1:2018/A11:2026 signifies a transition to a more integrated and transparent development model, in which compliance is defined by an ongoing “duty of care” rather than by the implementation of a static set of security features.
Though still a scratch on the surface of the forthcoming harmonized EN IEC 62443-4-1/A11©, you’ve hopefully by now developed the motivation to act and prepare for the final standard once it’s cited in the OJEU. Time is ticking.
Graphics created with AI support