How to approach CRA

You, as a manufacturer of Products with Digital Elements (PwDE) within the CRA scope, are fully aware that your PwDE must comply with the CRA by the end of 2027. But where do you start?

Here is a recommendation for approaching the challenge. I’m here to help.

DISCLAIMER: The Interactive CRA Compliance Checklist below is designed with AI support. AI can make mistakes. I’ve done my best to quality-assure the Checklist. Do not consider this legal or technical advice.

CRA recap

The CRA requirements are set out in the Annexes.

Annex I ESSENTIAL CYBERSECURITY REQUIREMENTS

- Part I: Cybersecurity requirements relating to the properties of products with digital elements.
  1. Secure Development
  2. Essential product requirements
- Part II: Vulnerability handling requirements.

defines what must be true about the product and its development

Annex II INFORMATION AND INSTRUCTIONS TO THE USER

defines what must be communicated once Annex I is met.

Annex V EU DECLARATION OF CONFORMITY

defines what must be declared once Annex I is met.

Annex VII TECHNICAL DOCUMENTATION

defines what must be documented to prove Annex I is met.

Approaching CRA

Overview → Gaps → Plan → Execute

Overview: Step 1 - your destination

The CRA cannot be viewed in isolation. Understanding how it integrates with and balances your other business initiatives is important. This is where you craft the balanced North Star your organization must navigate.

Overview: Step 2 - your inventory and prioritization

You’ll establish a complete inventory of your (connected) Products with Digital Elements within the scope of CRA. Depending on the size of this inventory, you may benefit from affinity clustering of your products. Each product or cluster must be assigned a CRA classification (Default, Important Class I, Important Class II, or Critical).

You’ll need to make a business decision about which products/clusters must be CRA-conform and which to discontinue.

Gaps: Step 3.1 - gap analysis on your Secure Development Process - Annex I, Part I (1)

Manufacturers of Products with Digital Elements that rely on harmonized standards (such as EN IEC 62443-4-1) to claim a presumption of conformity under the CRA cannot realistically achieve or sustain compliance at a process maturity level below CMMI Level 3 (ML3). My recommendation is to obtain a draft of EN IEC 62443-4-1:2018/A11:2026.

Although the CRA text does not explicitly mandate “CMMI-3,” its regulatory enforcement mechanisms, harmonized standard requirements, and post-market obligations establish an operational threshold that only an ML3-equivalent process framework can meet.

TO CONCLUDE: Attempting to claim a presumption of conformity below ML3 exposes the organization to severe market surveillance risk. During regulatory audits, inconsistent processes invalidate the presumption of conformity, potentially leading to sales bans, mandatory product recalls, and severe financial penalties. For executive leadership, ML3 is the baseline operational threshold required to safely absorb CRA liabilities.

Gaps: Step 3.2 - gap analysis on your products/clusters conformity with CRA's ECR - Annex I, Part I (2)

While step 3.1 focuses on the development process, step 3.2 addresses CRA’s product requirements.

You won’t achieve Presumption of Conformity (PoC) based solely on CRA’s Essential Cybersecurity Requirements (ECR). PoC must be based on relevant harmonized standards that, through their Annexes, map to CRA’s ECRs. In step 3.2, you’ll identify the harmonized standards to apply.

Correct. At this time, no harmonized standard has been cited in the OJEU (citations are a legal prerequisite for PoC of the requirements covered by the given standard). However, my strong recommendation is to obtain draft versions of the harmonized standards and use them. Some of the standards are still in very early stages (such as EN 40000-1-4), so even obtaining a draft can be a challenge. If you are operating in industrial OT, aim to obtain the draft version EN IEC 62443-4-2:2019/A11:2026.

The gap analysis will now follow a risk-based approach. A clear example is the new EN IEC 62443-4-1:2018/A11:2026, which introduces the Practice Security Risk Management (SRM). A discipline such as Threat Modeling is key here within a well-defined Security Context.

The outcome of step 3.2 is an understanding of the gaps that must be closed for the products/clusters to meet the requirements identified in the harmonized standard(s).

Gaps: Step 3.3 - gap analysis on your Vulnerability Handling process - Annex I, Part II

EN 40000-1-3 is the base standard. Are you operating in industrial OT? Also align with EN IEC 62443-4-1:2018/A11:2026 (note its Annexes map to EN 40000-1-2 and EN 40000-1-3).

The outcome of step 3.3 is an understanding of the gaps in your Vulnerability Handling.

NOTE: Make sure to align with your NIS2 initiatives.

Plan: Step 4 - plan gap-closure

Now that the three gap areas have been addressed, an assessment should be conducted to ensure that the investment remains viable for the business and that sufficient capacity (and competence) is allocated in a timely manner to close the gaps.

Organizations will typically define a CRA Program that includes a number of gap-closing projects.

Execute: Step 5 - close the gaps

During execution, maintain awareness of the development of the harmonized standards and be prepared to adjust accordingly.

NOTE: It is highly unlikely that the EU Commission will postpone the December 2027 deadline. If the harmonized standards are significantly delayed, Plan B is the Common Specifications.

Compliance Checklist

To help maintain a compliance overview, I’ve developed a self-explanatory CRA Compliance Checklist.

CRA Compliance Checklist

Assess product conformity against the essential cybersecurity requirements.

0% Addressed

Reference Diagram: Standardisation Request M/606 Architecture

Reference Diagram: EN IEC 62443 in the M/606 Architecture (The Sandwich)

Position in the M/606 CRA Architecture:

They have a “broad vertical” role, while horizontal standards (EN 40000-1-x) apply across all products with digital elements.
They sit within the Industrial Automation and Control Systems (IACS) sector track (primarily feeding into Item 35 under CENELEC).

Product Name

Product Version

Product Classification ? Determines which Annex III/IV rules apply and updates available Vertical Standards.

Vertical Standard ? Options depend on Product Classification. Affects your conformity assessment route.

Assessor Name / Owner

Date of Assessment

Important: Presumption of Conformity

According to the 'standards sandwich', presumption of conformity cannot be argued directly on the CRA text itself. At a minimum, conformity must be based on the product-agnostic harmonised horizontal standards (EN 40000-1-x series). If a specific Vertical Standard exists for your product, it must be used.

Wrap-up

Given the circumstances, you may have just secured your right to play from 2028 onward, but no more, and you won’t be alone. One thing is enough for legal compliance; another is achieving a strong competitive edge. My prediction is that many manufacturers will face a significant “CRA Catch-up” in 2028.

Also, some harmonized standards are not expected to be cited in the OJEU before the end of 2027, and possibly even later. If you’ve been following my recommendations based on the draft versions of the harmonized standards, you’ll be well positioned to catch up with the cited harmonized standards in 2028.

NOTE: In the short run, you need to comply with your reporting obligations as of September 11, 2026.

28. July 202617. August 2026

CRA and the Standardization Request M/606

The Standardization Request M/606 has been referenced several times in the blog. But what is it?

That is the topic for this article.

The Standardization Request M/606

The Standardization Request M/606 is the official mandate issued by the European Commission to the European Standardization Organizations (CEN, CENELEC, and ETSI). It directs these bodies to draft and deliver the set of European Harmonized Standards (hENs) required to support the implementation of the Cyber Resilience Act (CRA).

Key purpose & scope

The overarching objective of M/606 is to establish standards that manufacturers can use to demonstrate compliance with the CRA’s mandatory Essential Cybersecurity Requirements (Annex I, Parts I and II). Products that comply with these harmonized standards receive an automatic Presumption of Conformity.

M/606 divides the required technical deliverables into 41 standards split across two main structural tiers:

In CEN/CENELEC, work is primarily led by CEN-CLC/JTC 13 (Cybersecurity and Data Protection, particularly WG 9 for horizontal CRA standards and WG 6 for cryptography) and CLC/TC 65X (Industrial-process measurement, control, and automation).

In ETSI, technical work is driven via a dedicated group (ETSI EUSR) under ETSI TC CYBER.

Every standard delivered under M/606 intended for legal presumption of conformity must include an Annex ZA/ZZ mapping standard clauses directly to the corresponding provisions of CRA Annex I.

27. July 202617. August 2026

AI threat velocity vs. the (coming) EN IEC 62443/A11 Shield

Is the upcoming CRA-aligned EN IEC 62443/A11 harmonized standard up to the task of protecting against AI-driven attacks, or has it already been overtaken before it is cited in the OJEU?

That is what the article is about.

Today’s and definitely tomorrow’s cybersecurity threat is AI with accelerated vulnerability & exploit generation. The integration of AI into offensive cyber operations fundamentally alters the threat landscape.

AI-driven fuzzing and machine learning reverse-engineering tools continuously analyze firmware and codebases, discovering logic flaws and zero-day vulnerabilities in automated feedback loops. Where human researchers previously required days or weeks to move from vulnerability identification to a working exploit, generative AI tools condense payload generation and attack chaining into minutes. And traditional manual triage and patch development lifecycles cannot match the velocity of autonomous, AI-driven exploit distribution.

Is the upcoming EN IEC 62443/A11 family is already outdated?

The upcoming EN IEC 62443/A11 introduces several dynamic shields specifically designed to counter AI-empowered adversaries. Here are some.

Continuous risk management vs. point-in-time checklists

The old IEC 62443 treated threat modeling as a static, point-in-time task completed prior to initial product release.

As explained in EN IEC 62443-4-1/A11©: A closer look, the new Practice 2 “Security Risk Management (SRM)” is introduced. Manufacturers must continuously monitor and update threat models whenever exposure changes. Threat actors are modeled in capability tiers (up to SL 4 extended resources). As AI tools elevate the capabilities of lower-tier actors, the process automatically mandates higher mitigation severity.

The goal of the Security Level (SL) framework is to define the qualitative resistance of a component against specific threat actor profiles. The A11 amendment refines these levels to ensure components provide state-of-the-art protection against sophisticated entities as mandated by the CRA.

Resistance over functionality: It’s not enough that the MFA “works”; it must be proven to resist a sophisticated harvester.

EN IEC 62443-4-2/A11©: A closer look

Machine-readable triage vs. manual supply chain tracking

The old IEC 62443 relied on unstructured, static component documentation.

As explained in EN IEC 62443-4-1/A11©: A closer look, complete component inventories, and machine-readable S-BOMs in standardized formats such as SPDX or CycloneDX are mandated. This enables automated, real-time matching against vulnerability feeds, matching the speed of AI-driven supply-chain reconnaissance.

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.

EN IEC 62443-4-1/A11©: A closer look

Execution-layer neutralization vs. boundary-only defense

The old IEC 62443 focused primarily on software-level access controls and perimeter network boundary security.

As explained in EN IEC 62443-4-2/A11©: A closer look, it establishes immutable, hardware-backed constraints that stop AI-crafted payloads from executing, regardless of how quickly they were generated. Examples:

- Hardware Root of Trust secures cryptographic anchors at the manufacturing layer.
- Cryptographic Boot Authenticity mandates verifying image authenticity prior to booting, denying execution to AI-manipulated or corrupted bootloaders.
- Strict Input Validation enforces syntax and semantic validation across external interfaces, blocking automated malformed injections.
- Least Functionality requires restricting or disabling unused interfaces, ports, and protocols, dramatically reducing the total attack surface exposed to AI scanners.
- And much more.

The CRA and the EU AI Act

Both the CRA and the AI Act (see also the article EU AI Act and Digital Omnibus on AI) explicitly acknowledge and mandate protections against adversaries who leverage AI or target AI systems using malicious techniques.

Offensive cyber capabilities & malicious exploitation

AI enabling cyber offense

Systemic risks should be understood to increase with model capabilities and model reach… In particular, international approaches have so far identified the need to pay attention to risks from potential intentional misuse or unintended issues of control… offensive cyber capabilities, such as the ways in vulnerability discovery, exploitation, or operational use can be enabled…

EU AI Act, Recital 110

Defense against AI-driven attacks & malicious use

Cybersecurity protection related to systemic risks associated with malicious use or attacks should duly consider accidental model leakage, unauthorised releases, circumvention of safety measures, and defence against cyberattacks, unauthorised access or model theft.

EU AI Act, Recital 115

Specific attack vectors with data poisoning, model poisoning, and evasion

When adversaries use AI techniques to subvert digital systems, specific technical attack vectors emerge that legal frameworks explicitly identify.

Mandatory technical countermeasures

High-risk AI systems shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities… The technical solutions to address AI specific vulnerabilities shall include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws.

EU AI Act, Article 15(5)

CRA Assessment of Adversarial Exploitation

…the assessment of the cybersecurity risks associated with a product with digital elements classified as a high-risk AI system pursuant to Regulation (EU) 2024/1689… should take into account risks to the cyber resilience of an AI system as regards attempts by unauthorised third parties to alter its use, behaviour or performance, including AI specific vulnerabilities such as data poisoning or adversarial attacks…

CRA, Recital (51)

Wrap-up

The upcoming EN IEC 62443/A11 family is not outdated. While AI accelerates the discovery and creation of exploits, an AI-crafted payload still cannot override physical hardware boundaries. By combining continuous lifecycle risk management with strict, hardware-anchored execution safeguards, the A11 family provides the exact structural foundation required to withstand AI-driven attacks until it does not. That is why the new Security Risk Management mandates:

Continuous Threat Adaptation

A process shall be employed to ensure that the threat model and security risk assessment is monitored and reviewed whenever the product’s cyber security threat and risk exposure changes, incorporating relevant field defects and CVE disclosures.

EN IEC 62443-4-1:2018/A11:2025 Practice 2, SRM-8

21. July 202617. August 2026

CRA Presumption of Conformity and Common Specifications

CRA Article 27 establishes the legal framework and mechanisms by which products with digital elements (and their manufacturers’ processes) can obtain a Presumption of Conformity with the Regulation’s essential cybersecurity requirements (as set out in Annex I).

What you may not realize is the role of Common Specifications (CS).

In the CRA, Common Specifications (CS) and Harmonized Standards (HS) are two distinct legal pathways for demonstrating conformity, and they occupy different levels of the EU regulatory hierarchy. HS are the primary and preferred route; CS are a fallback issued by the Commission when HS are missing, insufficient, or delayed.

Key Mechanisms for Demonstrating Compliance

Harmonized Standards

Products and manufacturing processes aligned with EU harmonized standards (published in the Official Journal of the European Union) automatically enjoy a presumption of conformity with the requirements covered by those standards.

Common Specifications

If European standardization bodies fail to deliver appropriate harmonized standards, face delays, or reject standardization requests, the European Commission may adopt common specifications through implementing acts to set technical requirements. Compliance with these common specifications creates a presumption of conformity.

Cybersecurity Certification Schemes

Products certified or issued a statement of conformity under a European cybersecurity certification scheme (pursuant to Regulation (EU) 2019/881) are presumed to comply with the relevant essential cybersecurity requirements.

Procedural Rules & Special Provisions

Mandatory Standard Requests

The Commission is tasked with requesting that European standardization organizations draft harmonized standards, taking into account existing international cybersecurity standards.

Delegated Authority for Certification

The Commission is authorized to adopt delegated acts that specify which European cybersecurity certification schemes qualify as evidence of compliance.

Exemption from Third-Party Assessments

Obtaining a certificate under an approved scheme at the “substantial” assurance level (or higher) exempts manufacturers from additional third-party conformity assessments for those requirements.

Safeguards and Member State Feedback

If a Member State demonstrates that a common specification does not fully meet the essential cybersecurity requirements, the Commission will evaluate the feedback and may amend or repeal the relevant implementing act. Similarly, if a harmonized standard is published that covers the same scope, the Commission will repeal the corresponding common specifications.

Will we see Common Specifications from the Commission?

Your guess is as good as mine, but I would not be surprised as we approach 2027.

12. July 202617. August 2026

CRA – assistance – Guide

The (still-in-draft) Commission guidance on the Cyber Resilience Act assists economic operators (with a particular focus on microenterprises and SMEs) and market surveillance authorities in applying the CRA. It clarifies key provisions, regulatory boundaries, and practical compliance strategies without legally binding the actors.

Commission-guidance-on-the-application-of-CRA

Ref. Ares(2026)2319816 – 03/03/2026

Highlights from the Guidance

Below you’ll find an attempt to extract highlights from the Guide.

Scope and "Placing on the Market"

Digital distribution allows for a virtually infinite number of copies. Standalone software is considered “placed on the market” when its manufacturing phase is complete, and the version is first offered for distribution or use. Subsequent downloads of the identical version are repetitions of making it available, not new placements.

Software required for a hardware device to perform its intended functions (e.g., printer drivers or wearable companion apps) is part of a single product with digital elements, even if distributed via separate channels.

The CRA applies to compiled, uncompiled, or interpreted computer code shared as part of a commercial activity. Unfinished code (alphas/betas for testing) or sample tutorial code is excluded.

A product falls under the CRA if its capacity to exchange digital data involves sending or receiving deliberately encoded binary symbols.

Free and Open-Source Software (FOSS)

The CRA applies only to entities (“maintainers“) that publish FOSS and exercise primary control over development, releases, and governance. Individual contributors who submit code but do not control releases are excluded.

FOSS is considered placed on the market only if it is supplied in the course of commercial activity.

Commercial Indicators.

Direct monetization (charging a price), using the FOSS to monetize other services, or requiring personal data processing for reasons other than security or interoperability.

Non-Commercial Indicators.

Voluntary donations (that do not condition product access or act as a de facto price), commercial sponsorship/financing of a project, and strictly cost-recuperating support services packaged by natural persons.

Legal, not-for-profit entities that provide systematic, sustained support to ensure the viability of FOSS projects intended for commercial downstream integration are classified as “stewards.” They are subject to distinct, tailored cybersecurity obligations under CRA Article 24, based on the depth of their support (non-technical, infrastructural, or engineering).

Substantial Modifications and Spare Parts

Swapping worn or defective hardware components with equivalent or better-performing ones does not constitute a “substantial modification” unless it introduces unassessed risks or alters the product’s behavior in a way that conflicts with essential security requirements.

Identical components manufactured to the original specifications are fully exempt from the CRA. Non-identical replacements are treated as separate products under the CRA and require localized risk assessments.

Software updates are evaluated on a case-by-case basis:

Security updates or minor iterative features already factored into the original risk assessment are not substantial modifications.

Updates that introduce new threat vectors, enable new attack scenarios, modify the underlying trust model, or alter the product’s overarching intended purpose (e.g., turning a read-only dashboard into an operational device controller) constitute substantial modifications, treating the update as a completely new product placement requiring a new conformity assessment.

Support Periods

Manufacturers must formally define a support period for handling vulnerabilities. It must be at least five years unless the product’s expected lifecycle is demonstrably shorter. Longer lifecycles require proportionally longer support periods.

For rapidly changing software, manufacturers may remediate vulnerabilities only for the latest version, provided users can upgrade to it free of charge and without incurring disruptive hardware or environmental “additional costs.” See CRA Article 13 (10).

Important and Critical Products

See also the previous article CRA – assistance – Implementing Regulation.

Classification into Default, Important (Class I/II), or Critical tiers depends on whether the main features, without which the product cannot fulfill its purpose, align with the product categories in CRA Annex III or IV. Ancillary features or the mere integration of an important component (e.g., a smartphone incorporating an operating system) does not elevate the core classification of the entire product.

Conformity Assessments:

Default products permit self-assessment (Module A).

Important Class I products may rely on internal controls only if they use harmonized standards published in the OJEU that fully cover their core functional risks.

Important Class II and Critical products mandate strict third-party assessments.

Gaps between standard coverage and broader product scopes require distinct risk mitigations and lack a presumption of conformity for the unmapped features.

Risk Assessments & Remote Data Processing Solutions (RDPS)

Risk assessments must evaluate residual risks against objective regulatory thresholds rather than an organization’s internal risk appetite or commercial budgets. Shortcomings in product design cannot be offset by shifting responsibility to user instructions.

While manufacturers must secure product-level interactions against external environments, third-party integrated components require structured due diligence, including verification of supplier specifications, documentation, and functional testing.

Cloud, edge, or on-premises server software qualifies as a Remote Data Processing Solution (RDPS) if it is designed or developed by, or under the responsibility of, the manufacturer, and its absence prevents a product function (e.g., remote authentication or cloud-based computation). Traditional SaaS integrations (where the vendor designs the software) are treated as third-party components rather than as an RDPS.

Reporting Obligations and Interplay with Other Laws

The 24-hour early warning and 72-hour notification deadlines begin the moment a manufacturer, through a rapid initial assessment, reaches a “reasonable degree of certainty” that an incident has occurred or that a vulnerability is actively being exploited.

Manufacturers must report vulnerabilities found in integrated components to the original maintainers. If they create a custom patch (“security fix”) for a FOSS component, they must share it upstream in a verifiable, license-compatible format.

Components designed and constructed exclusively for automotive vehicles covered by Regulations (EU) 2019/2144 or No 168/2013 are exempt from the CRA. Furthermore, existing EU type-examination certificates issued under the Radio Equipment Directive (RED) or the Machinery Regulation remain partially valid under the CRA until 11 June 2028. However, manufacturers must still evaluate and address any remaining security gaps (such as vulnerability handling processes) to achieve full CRA compliance.

Wrap-up

Additional CRA assistance will be provided in the upcoming articles.

12. July 202617. August 2026

CRA – assistance – Implementing Regulation

CRA assistance implementation regulation_full_v2_1200x745

Various forms of CRA assistance are available. This article is the first in a series outlining the available help.

The biggest help, without question, would have been to have all the harmonized standards ready and cited in OJEU by now. Unfortunately, that is not the case. In fact, not a single harmonized standard has yet been cited in OJEU.

The first piece of assistance is the Commission’s Implementing Regulation.

COMMISSION IMPLEMENTING REGULATION(EU) 2025/2392

This Implementing Regulation (EU) 2025/2392 provides the official technical descriptions for all Important and Critical product categories listed in Annexes III and IV of the Cyber Resilience Act (CRA). These descriptions determine which products are subject to stricter conformity assessment procedures, including mandatory third‑party assessment or EU cybersecurity certification.

The regulation clarifies that a product’s classification is determined by its core functionality, rather than by the mere inclusion of specific components.

The Core Functionality Rule provides that if a product’s primary purpose aligns with a category in Annex III (Important) or Annex IV (Critical) of Regulation (EU) 2024/2847, it is subject to the applicable conformity assessment.

Regarding Component Integration, the regulation states that integrating a component, such as an embedded browser in a news app or firewall functionality in a router, does not automatically classify the entire product under that category unless that component is the product’s core function.

The regulation defines the “Common Criteria” and “Common Evaluation Methodology” in line with Implementing Regulation (EU) 2024/482. To ensure legal certainty for hardware (microprocessors, microcontrollers, and smartcards), resistance levels are specified by the “AVA_VAN” standard, allowing reference to both the latest and previous versions of these standards until the end of 2027.

Regardless of classification, manufacturers must conduct a comprehensive cybersecurity risk assessment and implement essential security requirements proportionate to the intended purpose and foreseeable use.

The Key Tables

The key tables from the regulation (November 28, 2025) are presented below.

Important Class I

Category of product	Technical description
1. Identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers	Identity management systems are products with digital elements that provide mechanisms for authentication or authorisation and that may also provide mechanisms for the lifecycle management of identity credentials of natural persons, legal persons, devices or systems, such as identity registration, provisioning, maintenance, deregistration. These systems include access management systems that control access of natural persons, legal persons, devices or systems to digital resources or physical locations. Privileged access management software is an access management system that controls and monitors access rights to IT or OT systems and sensitive information within an organisation, including systems enforcing differentiated access control policies for privileged users. This category includes but is not limited to authentication and access control readers, biometric readers, single sign-on software, federated identity management software, one-time password software, hardware authentication devices such as transaction authentication number (TAN) generators, authentication software and multi-factor authentication software.
2. Standalone and embedded browsers	Software products with digital elements that enable end users to access, render, and interact with web content and services hosted on servers that are connected to networks such as the Internet. They typically include a browser engine for interpreting and displaying content written in markup language (e.g. HTML), support for web protocols (e.g. HTTP, HTTPS), the ability to execute scripts and manage user inputs as well as storage of temporary or persistent data from websites (cookies). This category includes but is not limited to standalone applications that fulfil the functions of browsers, embedded browsers intended for integration into another system or application as well as browsers with AI agent integration.
3. Password managers	Products with digital elements that store passwords, locally on a device or on a remote server, including activities such as generation of passwords as well as password sharing and integration with local or third-party applications for usage of passwords. This category includes but is not limited to local password managers, password managers provided as browser extensions, enterprise password managers as well as hardware-based password managers.
4. Software that searches for, removes, or quarantines malicious software	Software products with digital elements, typically referred to as antivirus or antimalware, that detect or search for malicious software or code on devices, or remove or quarantine such software or code, in order to maintain the integrity, confidentiality, or availability of such devices. In the context of this category of products, malicious software means software containing malicious features or capabilities that can cause harm directly or indirectly to the user and/or the computer system, such as viruses, worms, ransomware, spyware and trojans. This category includes but is not limited to software that detects or searches for malicious software in real-time or manually, rootkit detection and rescue disks with the core functionality of searching, removing or quarantining malicious software.
5. Products with digital elements with the function of virtual private network (VPN)	Products with digital elements that establish an encrypted logical tunnel that is constructed from the system resources of a physical or virtual network. This category includes but is not limited to virtual private network clients, virtual private network servers and virtual private network gateways.
6. Network management systems	Products with digital elements that manage connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by monitoring them and controlling their network operations and configuration. This category includes but is not limited to end-to-end management systems and dedicated configuration management systems, such as controllers for software-defined networking.
7. Security information and event management (SIEM) systems	Products with digital elements that collect data from multiple sources, analyse and correlate that data and present it as actionable information for security-related purposes, such as threat and incident detection, forensic analysis or compliance purposes.
8. Boot managers	Software products with digital elements that manage the process of initial system startup after power on/restart by selecting boot options, initialising hardware, loading or transferring control to the operating system environment or system resources. This category includes but is not limited to UEFI firmware, single-stage and multi-stage boot loaders.
9. Public key infrastructure and digital certificate issuance software	Products with digital elements used as part of a public key infrastructure (PKI) that manage the validation, creation, issuance, distribution, status publication, renewal or revocation of digital certificates, or the generation, storage, escrow, exchange, destruction or rotation of cryptographic keys associated with such digital certificates. This category includes but is not limited to key management systems, digital certificate management systems, online certificate status protocol responders and all-in-one PKI solutions.
10. Physical and virtual network interfaces	Physical network interfaces are products with digital elements that directly connect a device to a network via an application programming interface (API) provided by the interface drivers, typically operating at the data link layer, and that feature hardware adapters to transmission media with corresponding firmware, typically operating at the physical and data link layer. Virtual network interfaces are products with digital elements that directly or indirectly connect a device to a network via an API that emulates that of drivers of physical network interfaces, typically operating at the data link layer. This category includes but is not limited to wired and wireless network interface cards, controllers and adapters, such as for Wi-Fi, Ethernet, IrDA, USB, Bluetooth, NearLink, Zigbee, or Fieldbus, as well as purely virtual standalone products, such as virtual network interface cards, container network interfaces and VPN interfaces.
11. Operating systems	Software products with digital elements that provide an abstract interface of the underlying hardware and control the execution of software, and that may provide services such as computing resource management and configuration, scheduling, input-output control, managing data, and providing an interface through which applications interact with system resources and peripherals. This category includes but is not limited to real-time operating systems, general-purpose and special-purpose operating systems.
12. Routers, modems intended for the connection to the internet, and switches	Routers are products with digital elements that establish and control the flow of data between different networks by selecting paths or routes using routing protocol mechanisms and algorithms, typically operating at the network layer. This category includes but is not limited to wired and wireless routers, virtual routers and routers with or without modems. Modems intended for the connection to the Internet are hardware products with digital elements that use digital modulation and demodulation techniques to convert analogue signals from and to digital signals for IP-based communication. This category includes but is not limited to fibre modems, Digital Subscriber Line (DSL) modems, cable (DOCSIS) modems, satellite modems and cellular modems. Switches are products with digital elements that provide connectivity between networked devices through packet forwarding mechanisms and that have a management plane, typically implemented at the data link or network layer. This category includes but is not limited to managed switches, smart switches, multilayer switches, virtual security switches, programmable switches for software-defined networking and bridges such as wireless access points.
13. Microprocessors with security-related functionalities	Products with digital elements that are integrated circuits that carry out central processing functions relying on external memory and peripherals, including microcode and other low-level firmware. They additionally provide security-related functionalities, such as encryption, authentication, secure key storage, random number generation, trusted execution environment, or other hardware-based protection mechanisms, that aim to secure other products, networks or services beyond the microprocessor itself, such as secure boot chain, virtualization or secure communication interfaces.
14. Microcontrollers with security-related functionalities	Products with digital elements that are integrated circuits that carry out central processing functions integrating memory allowing the microcontroller to be programmable and typically also other peripherals, including microcode and other low-level firmware. They additionally provide security-related functionalities, such as encryption, authentication, secure key storage, random number generation, trusted execution environment, or other hardware-based protection mechanisms, that aim to secure other products, networks or services beyond the microcontroller itself, such as secure boot chain, virtualization or secure communication interfaces.
15. Application specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) with security-related functionalities	Application specific integrated circuits (ASIC) with security-related functionalities are products with digital elements that are integrated circuits, fully or partially custom-designed to perform a specific function or implement a specific application, including microcode and other low-level firmware. They additionally provide security-related functionalities, such as encryption, authentication, secure key storage, random number generation, trusted execution environment, or other hardware-based protection mechanisms, that aim to secure other products, networks or services beyond the ASIC itself, such as secure boot chain, virtualization or secure communication interfaces. Field-programmable gate arrays (FPGA) with security-related functionalities are products with digital elements that are integrated circuits characterized by a matrix of configurable logic blocks designed to be reprogrammable after manufacturing to perform a specific function or implement a specific application, including microcode and other low-level firmware. They additionally provide security-related functionalities, such as encryption, authentication, secure key storage, random number generation, trusted execution environment, or other hardware-based protection mechanisms, that aim to secure other products, networks or services beyond the FPGA itself, such as secure boot chain, virtualization or secure communication interfaces.
16. Smart home general purpose virtual assistants	Products with digital elements that communicate on the public Internet, whether directly or via other equipment, that process demands, tasks or questions based on natural language prompts, such as through audio or written input, and that, based on those demands, tasks or questions, provide access to other services or control the functions of connected devices in residential settings. This category includes but is not limited to smart speakers with an integrated virtual assistant, and standalone virtual assistants that meet this description.
17. Smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems	Products with digital elements that protect the physical security of consumers in a residential setting and which can be controlled or managed remotely from other systems, as well as hardware and software that centrally control such products. This category includes but is not limited to smart door locking devices, baby monitoring systems, alarm systems and home security cameras.
18. Internet connected toys covered by Directive 2009/48/EC of the European Parliament and of the Council that have social interactive features (e.g. speaking or filming) or that have location tracking features	Internet connected toys that have social interactive features are products with digital elements that are covered by Directive 2009/48/EC, that communicate on the public Internet, whether directly or via any other equipment, and that have embedded technologies that enable inbound and outbound communication, such as keyboard, microphone, speaker or camera. Internet connected toys that have location tracking features are products with digital elements that are covered by Directive 2009/48/EC, that communicate on the public Internet, whether directly or via any other equipment, and that have technologies that enable tracking or inferring of the geographical location of the toy or its user. Where the toy merely detects the proximity of the user or of other toys by using sensing technologies, the toy is not to be considered to have location tracking features.
19. Personal wearable products to be worn or placed on a human body that have a health monitoring (such as tracking) purpose and to which Regulation (EU) 2017/745 or (EU) 2017/746 do not apply, or personal wearable products that are intended for the use by and for children	Personal wearable products to be worn or placed on a human body that have a health monitoring purpose are products with digital elements that are worn on the body directly or via clothing or accessories and that can, regularly or continuously, sense and further process information, including body metrics, relevant to the user's health, excluding products that fall within the scope of Regulation (EU) 2017/745 or of Regulation (EU) 2017/746. This category includes but is not limited to fitness trackers, smartwatches, smart jewellery, smart clothing and sports apparel that meet this description. Personal wearable products that are intended for the use by and for children are products with digital elements which can be worn or placed on the body, directly or via clothing or accessories, of individuals under the age of 14. This category includes but is not limited to child safety wearables.

Important Class II

Category of product	Technical description
1. Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments	Hypervisors are software products with digital elements that abstract and/or allocate computing resources and enable the execution, management and orchestration of virtual machines that are logically separated from each other and/or from the physical hardware. Hypervisors may run directly on hardware (bare metal), on top of an operating system, or within another virtual machine (nested virtualisation). In the context of this category of products, a virtual machine is a software-defined logical separation of a computing environment, which includes a virtualised set of hardware resources (e.g. CPU, memory, storage, network interfaces) and typically hosts its own operating system. This category includes but is not limited to type 1 hypervisors (bare metal), type 2 hypervisors (hosted on an operating system) and hybrid hypervisors. Container runtime systems are software products with digital elements that manage the execution and lifecycle of containers running on a single host operating system as isolated processes, allocating resources and allowing the management and orchestration of individual containers. In the context of this category of products, a container is a software-based execution environment that encapsulates one or more software components and their dependencies in a single package, enabling it to run independently and consistently.
2. Firewalls, intrusion detection and prevention systems	Firewalls are products with digital elements that protect a connected network or system from unauthorized access by monitoring and restricting data communication traffic to and from that network. This category includes but is not limited to network firewalls and application firewalls such as web application firewalls or filters and anti-spam gateways. Intrusion detection systems are products with digital elements that monitor traffic once it has entered the network environment for suspicious activity and detect or identify that an intrusion has been attempted, is occurring, or has occurred on a connected network or system. This category includes but is not limited to network-based intrusion detection systems and host-based intrusion detection systems. Intrusion prevention systems are products with digital elements composed of an intrusion detection system that actively responds to an intrusion to a connected network or system. This category includes but is not limited to network-based intrusion prevention systems and host-based intrusion prevention systems.
3. Tamper-resistant microprocessors	Products with digital elements that are microprocessors with security-related functionalities referred to in Table ‘Class I’, point 13, of this Annex, including tamper evidence, resistance or response, and which additionally are designed to provide protection of AVA_VAN level 2 or 3, as set out in the Common Criteria and the Common Evaluation Methodology.
4. Tamper-resistant microcontrollers	Products with digital elements that are microcontrollers with security-related functionalities referred to in Table ‘Class I’, point 14, of this Annex, including tamper evidence, resistance or response, and which additionally are designed to provide protection of AVA_VAN level 2 or 3, as set out in the Common Criteria and the Common Evaluation Methodology.

Critical

Category of product	Technical description
1. Hardware devices with security boxes	Products with digital elements that securely store, process or manage sensitive data or perform cryptographic operations and that consist of multiple discrete components, incorporating a hardware physical envelope providing tamper evidence, resistance or response as countermeasures against physical attacks. This category includes but is not limited to physical payment terminals, hardware security modules that generate and manage cryptographic elements, and tachographs that meet the above description.
2. Smart meter gateways and other devices for advanced security purposes, including secure cryptoprocessing	Smart meter gateways are products with digital elements that control communication between components in or connected to smart metering systems and authorised third parties, such as utility providers. They collect, process and store meter or personal data, protect data and information flows by supporting cryptographic needs (e.g., encryption/decryption), incorporate firewalling functionalities and provide means to control other devices. This category includes but is not limited to smart meter gateways related to smart metering systems measuring electricity as defined in relevant legislation. It may also include gateways used in smart metering systems for other energy sources (gas, heat) provided the gateway meets this description.
3. Smartcards or similar devices, including secure elements	Secure elements are microcontrollers or microprocessors with security-related functionalities, including tamper evidence, resistance or response. They typically store, process or manage cryptographic operations or sensitive data such as identity or payment credentials and are designed to provide high levels of assurance (e.g., AVA_VAN.4 as set out in the Common Criteria/Common Evaluation Methodology). Secure elements can be discrete silicon or integrated into systems on chip (SoC) and may incorporate an application environment or operating system with one or more applications. This category includes but is not limited to Trusted Platform Modules (TPMs) and embedded Universal Integrated Circuit Cards (UICC). Smartcards are secure elements integrated into a carrier material (e.g., plastic) in the shape of a card or into other carrier forms. This includes identity and travel documents, qualified signature cards, replaceable UICCs, physical payment cards, physical access cards, digital tachograph cards, and wearable devices (e.g., wrist bands) with integrated payment secure elements.

Wrap-up

Additional CRA assistance will be provided in the upcoming articles.

6. July 202617. August 2026

CRA Executive Summary

Here you’ll find a condensed executive summary of the Cyber Resilience Act, what it is, and the key criteria for compliance.

CRA-executive-summary_ProjektDK

You might also want to visit The Cyber Resilience Act (CRA) and the CRA quiz.

19. June 202617. August 2026

CRA – who is responsible?

A WTG (Wind Turbine Generator) manufacturer asks a supplier to design a sub-component in accordance with its specifications. How is the CRA responsibility split between the WTG manufacturer and the sub-component supplier?

The sub-component is here assumed to be a component/product with digital elements and network connectivity.

This is a typical CRA grey zone, but the Regulation is very clear once you apply the definitions of manufacturer, supplier, integrator, and product with digital elements (PwDE).

Scenario #1: The sub-component placed on the EU market as its own product

Examples could include

- A network-connected pitch controller sold to multiple turbine OEMs
- A digital sensor module with its own firmware and connectivity
- PLC-based subsystem with its own CE marking

Here, the supplier assumes the role of the Manufacturer under CRA. They must fulfill all obligations in Articles 13–20, including, e.g.,

- Secure by design & secure by default (Annex I Part I)
- Vulnerability handling & reporting (Annex I Part II + Art. 13(3))
- SBOM / component inventory
- Security updates for the declared support period
- Technical documentation (Art. 31)
- CE marking & DoC
- Incident reporting to ENISA (Art. 14)

The WTG manufacturer assumes the role of Integrator/downstream manufacturer and must

- Verify supplier conformity (Art. 13(2))
- Ensure integration does not break security
- Maintain system-level vulnerability handling
- Include the component in their own SBOM
- Ensure system-level documentation and CE marking for the turbine

Both parties have CRA obligations, but the supplier carries the full manufacturer burden for the subcomponent.

Scenario #2: The sub-component is custom made only for this WTG

Examples could include:

- A bespoke controller designed only for one turbine model
- A custom networked sensor with no independent market presence
- A firmware-driven module that only exists inside the turbine

The WTG manufacturer assumes the role of Manufacturer under CRA for the entire product. They must fulfill all CRA obligations, including for the subcomponent.

The sub-component Supplier serves as the Contracted design house / OEM supplier. They are not a CRA manufacturer, but they must:

- Provide all security-relevant design artifacts
- Support SBOM creation
- Support vulnerability handling
- Provide update mechanisms
- Provide evidence for conformity assessment

The WTG manufacturer carries the legal responsibility. The supplier carries the technical responsibility.

Scenario #3: The sub-component supplier does not develop and add software

The WTG manufacturer develops and loads the software, and the supplier provides only hardware, a preinstalled OS, and network device firmware. The WTG manufacturer here becomes the CRA Manufacturer for the entire sub‑component.

Thus, the supplier is not a CRA Manufacturer. They are a hardware supplier and contracted integrator.

Even if the WTG manufacturer provides the supplier with software for testing purposes, the WTG manufacturer remains the CRA Manufacturer.

To conclude

The CRA assigns responsibility based on who places the product on the market in their name (Art. 3(21)):

- If the supplier’s name is on the subcomponent → supplier = manufacturer
- If the WTG manufacturer’s name is on the final product → WTG manufacturer = manufacturer
- If the component is not marketed independently → only the WTG manufacturer is the manufacturer

Note: This is identical to the way the Machinery Regulation, RED, and EMC directives work.

CRA Obligation	Supplier (standalone PWDE)	Supplier (custom-only)	WTG Manufacturer
CE-marking	✔️	-	✔️
Declaration of Conformity	✔️	-	✔️
Annex I security requirements	✔️	Shared	✔️
Vulnerability handling	✔️	Shared	✔️
SBOM / component inventory	✔️	Shared	✔️
Security updates	✔️	Shared	✔️
Incident reporting (ENISA)	✔️	-	✔️
Technical documentation (Art. 31)	✔️	Shared	✔️
Integration security	-	-	✔️

The CRA establishes a shared responsibility model, but legal liability always follows the “placed on the market” rule.

19. June 20269. August 2026

Plenty of time to get CRA conformity – or?

The Cyber Resilience Act is just another expected-to-be-delayed NIS2 variant, right? No!

You may recall that NIS2 is a Directive, whereas CRA is a Regulation. Does it matter? Yes!

Aspect	Directive (e.g., NIS2)	Regulation (e.g., CRA)
Legal nature	Framework law — sets goals and minimum requirements for Member States.	Directly binding law — applies as written across all Member States.
Transposition	Must be implemented into national law (e.g., Denmark’s Lov nr. 434/2025).	No transposition — automatically becomes part of national law upon entry into force.
Flexibility	Allows national adaptation (terminology, authorities, penalties).	Uniform — identical text and obligations in all Member States.
Scope of variation	High — each country may tailor enforcement and sector coverage.	Low — only interpretation guidance; no national rewriting.
Legal hierarchy	Below regulations in direct effect; depends on national implementation.	Highest form of EU law after treaties; overrides conflicting national law.
Example in Denmark	NIS2 → Danish NIS2 Act (Lov nr. 434/2025).	CRA → Applies directly once published in the Official Journal; no Danish act needed.

In short, a Directive tells us what to achieve, not strictly when; just look at the delays in the Danish NIS2 implementation:

A Regulation, on the other hand, tells us exactly how to do it, with no room for national delay or reinterpretation.

The deadlines for the Regulation (here, CRA) are thus carved in stone.

If you got this wrong with CRA, expecting the hard deadlines from the Commission to be delayed the same way as with NIS2, then you are in for a surprise.

So what to do?

Knowing that the dates will not change, the only sensible approach, should you not already have done so, is to establish a top-priority project to ensure you’ll meet the deadlines.

If you do not have a valid CE sticker on your products after DEC 11, 2027, you are not permitted to place them on the EU market.

So no, CRA is not another NIS2 expected to be delayed. Dates are carved in stone.

A need to understand the CRA a little better? Have a look at this article and its CRA quiz.

25. May 20269. August 2026

EN IEC 62443-4-2:2019/A11:2026 Security Evaluation Methodology

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

21. May 20269. August 2026

Audit – start with the end

What does it, seen from an EN IEC 62443-4-1:2018/A11:2026 auditor’s point of view, take to cross the finishing line?

You know it from product and project management: Start with the end, and have that understanding guide your work in the right direction. It is the common North Star for teams in the organization to navigate towards. When it comes to auditing, the same principle applies.

Based on the (not yet cited in the OJEU) EN IEC 62443-4-1:2018/A11:2026© harmonized standard, I’m working on a tool to help guide my customers prepare for a coming audit (with a similar tool for 4-2 underway). The purpose of this article is to share my reflections on the tool.

Sure, it is lightweight (and still at the MVP level) compared to what a formal auditor (e.g., TÜV) would bring, but the point is not to be TÜV-like. The point is to gain a decent understanding of what an audit will expect, and for that understanding to provide direction, transparency, and alignment.

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 Standards Sandwich

You may recall where EN IEC 62443-4-1:2018/A11:2026© is placed in the Sandwich, see Infographics #1. 4-1 is about the process, where 4-2 is about the product.

4-1 is linked to (not yet cited in OJEU) EN 40000-1-2© (Cyber Resilience Principles) and to (not yet cited in OJEU) EN 40000-1-3© (Vulnerability Handling), which is evident in Annexes F (Mapping of EN 40000-1-2 to EN IEC 62443-4-1) and G (Mapping of EN 40000-1-3 to EN IEC 62443-4-1) in EN IEC 62443-4-1:2018/A11:2026.

Infographics #1.

The audit tool

Such a tool must be as close as possible to the actual standard, here EN IEC 62443-4-1:2018/A11:2026, with exact and valid references to Clauses and Requirements, which is why I cannot share a link to the tool itself. However, I’ll share some screenshots illustrating the intention.

In designing the tool, I’ve assumed the role of an auditor. The tool is based on draft material, but it can, of course, be updated once EN IEC 62443-4-1:2018/A11:2026 is final and cited in OJEU.

The tool header

You may wonder why I’ve also chosen to include the CRA product profile, here set to Important Class I (Standard Product, Important Class 1, Important Class II, Critical). The rationale is to guide consistency. In the example below, the organization aims for ML-2 while having an Important Class I product, which is inconsistent.

See the note in EN IEC 62443-4-1/A11©: A closer look at the Maturity Model: 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.

The audit cards - one per requirement

The core design idea is to track the audit workflow and the compliance findings for each requirement in audit cards, here for SM-1:

Flow and findings

The sandwich link

This is an informational field illustrating the link from the EN IEC 62443-4-1:2018/A11 requirement to CRA. Here is an example from Practice 1, SM-9 (Third-party components):

SM-9 is, via EN IEC 62443-4-1/A11 Annex F, linked to EN 40000‑1‑2 clause 7.11, which is linked to CRA Annex I, but in this case through functional alignment. There is no explicit clause 7.11 to ESR mapping inside the draft standard EN 40000-1-2 Annex C. Some explicit mappings are found in Annex C, but do not explicitly cover all EN 40000-1-2 clauses, at least in the draft version I have access to.

Rationale for the functional SM-9 alignment:

- EN IEC 62443-4-1:2018/A11:2026 SM-9: Third-party components
- EN 40000-1-2 clause 7.11: Third-party component cybersecurity management (shortened to Third-party components in the remaining clause)
- Annex I, Part II, Point (6): Take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements

Filled audit card examples

Administration header

The tool includes features like

- Search
- Grouping
- Views
- Export (to PDF)
- Reset
- Random example fill-out
- session persistence (JSON)

View: Executive Matrix (Heatmap)

Wrap-up

The purpose of the article was to share my thoughts on how to help an organization pass an audit against (not yet cited in OJEU) EN IEC 62443-4-1:2018/A11:2026 facilitated by a relatively simple online tool. And I hope you collected some inspiration.

Graphics and tools created with AI support

16. May 20269. August 2026

EN IEC 62443-4-1/A11©: A closer look

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

Consolidated view with examples of the transition to EN IEC 62443-4-1/A11

The Nine Practices: A11 Structural Shifts

Practice 1: Security Management

2018 Standard Process establishment, staff training, and security lead roles.

A11 ENHANCEMENT EXAMPLE Introduces the 'Vulnerability handling policy' and 'Software Bill of Material (SBOM)' as critical delivery requirements.

Practice 2: Security Risk Management New Practice

2018 Standard Contextual risk language used without a prescribed treatment method.

NEW WITH A11 A standalone practice formalizing mandatory threat modeling linked to the 'Product security context'.

Practice 3: Specification of Security Requirements

2018 Standard Product protection definitions based on intended use.

A11 ENHANCEMENT EXAMPLE Mandates 'Information Categorisation' and a formal 'Statement of Applicability (SoA)'.

Practice 4: Secure by Design

2018 Standard Defense-in-depth architecture and general threat modeling.

A11 ENHANCEMENT EXAMPLE Introduces specific requirements for 'Secure by Default' and 'Reset to a defined state'.

Practice 5: Secure Implementation

2018 Standard Coding standards, tool validation, and avoidance of common vulnerabilities.

A11 ENHANCEMENT EXAMPLE Mandates 'Automated Static Analysis (SAST)' and formal third-party component vetting.

Practice 6: Verification & Validation Testing

2018 Standard Functional, vulnerability, and penetration testing.

A11 ENHANCEMENT EXAMPLE Mandates specific 'Testing Modules' (Annex D), including Fuzzing and Independent Pentesting.

Practice 7: Management of Security Issues

2018 Standard Handling defects and vulnerabilities identified post-release.

A11 ENHANCEMENT EXAMPLE Mandates 'Coordinated Vulnerability Disclosure (CVD)' and machine-readable advisories (CSAF/VEX).

Practice 8: Security Update Management

2018 Standard Patching processes and communication of updates to users.

A11 ENHANCEMENT EXAMPLE Mandates 'Independent security patches' and automated user notification systems.

Practice 9: Security Guidelines

2018 Standard User documentation to maintain product security.

A11 ENHANCEMENT EXAMPLE Includes mandatory 'Secure decommissioning' and minimum product support guidelines.

The Seven Revised Annexes (A-G)

Table of requirements

Informative

A consolidated summary mapping all normative requirements of the standard.

Product security context category

Normative

Parameters to identify the intended operational environment and security profile.

Applicability of security requirements and risk workflow

Normative

The technical workflow for integrated risk management and requirement applicability.

Identification and documentation of security test modules

Normative

Activities required for verification and validation based on Security Profile.

Statement of applicability – Documentation template

Informative

Recommended format for documenting the SoA for conformity assessment.

Mapping of EN 40000-1-2 to EN IEC 62443-4-1

Informative

Alignment with horizontal cyber resilience standards at a granular level.

Mapping of EN 40000-1-3 to EN IEC 62443-4-1

Informative

Mapping 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.

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

In the Evolution of the standard, Practice 1 shifts to high-assurance delivery mandates, specifically requiring verified competency and proof of total supply chain transparency.

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

In the Evolution of the standard, Practice 2 acts as the mandatory engine that drives requirement selection, architecture boundaries, and data-centric protection strategies.

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

In the Evolution of the standard, Practice 3 translates the risk strategy into technical specifications that must align with Security Profiles and Data Categories.

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.

Infographic #5 aims to illustrate the revised Practice 4 with examples.

EN IEC 62443-4-1 Evolution

Practice 4: Secure Design

In the Evolution of the standard, Practice 4 translates the security profile into a resilient architecture, emphasizing out-of-the-box surface reduction and vetted third-party integrity.

Infographic #5

Practice 5: Secure 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

In the Evolution of the standard, Practice 5 ensures high-integrity code development through mandatory Automated Static Analysis.

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. See also Annex G [Informative] ‘Security Test Grades & Security Test Modules’ in EN IEC 62443-4-2/A11.

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

In the A11 amendment, Practice 6 shifts from general testing to a prescriptive transparency model, mandating explicit links to normative test modules and security profiles.

Infographics #7

Practice 7: Management of security-related issues

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

In the Evolution of the standard, Practice 7 establishes a proactive transparency model, mandating machine-readable CSAF/VEX advisories and strict alignment with Security Profiles.

Infographics #8

Practice 8: Security update management

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

In the Evolution of the standard, Practice 8 ensures long-term integrity through qualified regression testing against Security Profiles and mandatory flow-through of Third-Party Patches.

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

In the Evolution of the standard, Practice 9 shifts toward a proactive transparency model, mandating explicit Security Profile Mapping and structured Hardening Guidance to empower asset owners.

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

The maturity model measures the consistency and quality of the SDL. Level 3 is the mandatory normative baseline for harmonized EN IEC 62443-4-1/A11:2026 certification.

1 Initial

2 Managed

3 Defined

4 Optimizing

Standardized & Practiced

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.

Evolutionary Essence

Organizational standard integrated into the unified development workflow with mandatory artifact generation.

Certification Status Certification Baseline

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

30. April 20269. August 2026

CRA and internet-connected toys

This article explores the vertical standard ETSI EN 304 633© for internet-connected toys and the CRA presumption of conformity.

While currently in its draft stages, it serves as the definitive roadmap for manufacturers to ensure their playthings aren’t just fun, but CRA-compliant. As a hypothetical example illustrating EN 304 633©, we’ll use a toy robot below.

Should you not already have read the articles on

I recommend doing so.

Because ETSI EN 304 633 explicitly limits its scope to “internet-connected toys”, it is classified as a vertical standard tailored directly to the unique risks, physical operational environments, and asset types associated with toys (such as parental controls and data minimization for children). Considering the Standards sandwich, EN 304 633 is a product vertical.

DISCLAIMER: ETSI EN 304 633© has not yet been cited in OJEU as a harmonized standard. The article is based on collected draft insights and should not be seen as legal advice or technical recommendations.

Structure of EN 304 633

The primary goal of EN 304 633 is to establish harmonized cybersecurity requirements specifically for internet-connected toys. A toy falls within this scope if it has social interactive features (microphones, cameras, or speakers) or location-tracking features that communicate over the internet.

While the horizontal standard (also not yet cited in OJEU) EN 40000-1-2© provides the foundational risk management framework for all products with digital elements, EN 304 633 is a vertical standard that applies these principles specifically to internet-connected toys.

1. Determine the Product Context: EN 304 633 must define the “Intended Purpose and Reasonably Foreseeable Use” (IPRFU) for toys, including their operational environment. Also specify users and vulnerability as a key reflection point for toys.
2. Risk Acceptance Criteria: EN 304 633 must define the acceptable level of risk for toys, justified by the state of the art and regulatory factors.
3. Assets & Threats: Identifying assets (e.g., child’s voice data, location) and threats to those assets.
4. Risk treatment: EN 304 633 follows the EN 40000-1-2 priority order for risk treatment (the selection of Technical Requirements): Avoidance > Mitigation > Acceptance > Transfer. Risks inherent in the toy that cannot be mitigated must be clearly communicated to stakeholders (e.g., parents).

Infographic #1 aims to provide an overview of the standard, with examples.

To be harmonized EN 304 633 under CRA

Cybersecurity requirements for internet connected toys

Overview with examples

Section 4: Product Context

Product functions, architecture and interfaces

Requirement example Definition of functional assets, supporting systems, operational environment, and interfaces (e.g., IF.Human C for user interaction). This determines the toy's scope.

Assessment Criteria Detailed review of architecture documentation, use cases, and interfaces. Verification that all functional assets are mapped to impact classes according to Annex D.

Section 5: Technical requirements specifications

Vulnerability and Lifecycle

Known exploitable vulnerabilities & Updates

Requirement example The product shall be free of known exploitable vulnerabilities. Automatic security updates shall be enabled by default throughout the support period.

Assessment Criteria Execution of vulnerability analysis via scanning tools and verification that automatic update mechanisms are active and operational on the toy in its default state.

Default configuration and Reset

Requirement example Shipping with most secure settings and providing a functional reset to a defined secure state.

Assessment Criteria Physical and logical audit of the toy's out-of-the-box configuration and functional testing of the secure reset-to-defined-state command.

Authentication and Access

Authentication and access control mechanisms

Requirement example Use of unique credentials and restriction of functional assets (camera, mic, actuators) to authorized users to mitigate unauthorized access.

Assessment Criteria Testing protection against brute-force, token spoofing, and presentation attacks. Verification of strength levels (Basic to Strong) as specified in Annex E.

Integrity and Confidentiality

Integrity protection

Requirement example Verification of software package integrity and protection of communication for integrity-relevant data.

Assessment Criteria Cryptographic audit of software package digital signatures and analysis of communication streams to verify protection against unauthorized modification as per Annex E.

Confidentiality protection

Requirement example Protection of sensitive data (like captured audio or video) during communication and on persistent storage.

Assessment Criteria Forensic check of device persistent storage for encryption and TLS protocol analysis for confidential data in transit, matching normative levels in Annex E.

Privacy and Resilience

Data minimization and deletion

Requirement example Processing limited to essential data assets. Permanent and secure deletion mechanisms for user data.

Assessment Criteria Functional flow audit to confirm essential-only data processing and forensic verification that deletion commands permanently remove data.

Availability and Attack surface

Requirement example Resilience against network flooding (DoS) and hardening of physical and logical interfaces.

Assessment Criteria Network load testing against logical interfaces and hardware inspection to confirm the removal or disabling of physical debug headers (e.g., JTAG).

Logging and Monitoring

Requirement example Generating security logs for asset-relevant events with synchronized timestamps.

Assessment Criteria Triggering security events (e.g., failed logins) to verify automated log generation and auditing the accuracy of time synchronization (NTP).

Section 6: Vulnerability handling activities

Coordinated vulnerability handling requirements

Requirement example Establishment of requirements specifications for vulnerability handling as cited in the normative references.

Assessment Criteria Verification of manufacturer activities, inputs, and outputs against the referenced vulnerability handling standard based on documentation and record review.

Annex Summary

CRA Relationship (Informative)

Relationship between the present document and the essential requirements of EU Regulation 2024/2847 (Cyber Resilience Act).

Application Guidance (Informative)

Guidance for applying standard requirements to typical Internet Connected Toy architectures and categories.

Risk Assessment Methodology (Informative)

Information on the risk methodology used for asset impact classes and detailed threat scenarios mapping Threat Actors, Actions, and Assets.

Asset Impact Mapping (Normative)

Normative tables mapping data and function assets to their respective impact classes.

Protection Measures (Normative)

Normative strength levels (Basic to Strong) for authentication, integrity, and confidentiality mechanisms.

Risk Coverage Profiles (Informative)

Detailed view of cybersecurity risks covered or not covered by the current document.

Standard Integration (Informative)

Relationship between this document and horizontal standards ETSI EN 303 645 / ETSI TS 103 701.

Infographic #1

Meet the Robo-Pal 3000

To understand how the standard works in the real world, let’s look at a hypothetical Robo-Pal 3000, a toy robot that connects via Wi-Fi, features a camera and a mic for recognizing friends, and uses GPS so parents can find it if it’s left “somewhere”.

Determining the Scope and Profile

Under Scope, the Robo-Pal is an “internet-connected toy” because it has social interactive features (camera/mic), location tracking, and internet connection. Given that it processes video and location data, it is categorized as having a High-impact security profile.

Based on the feature set, Robo-Pal is CRA-classified as an Important Class I product. See CRA Annex III, Important products with digital elements, Class I, item 18: “Internet-connected toys … that have social interactive features (e.g. speaking or filming) or that have location tracking features.” To gain the CRA presumption of conformity, we must comply with the vertical product standard, here being EN 304 633.

Applying Technical Requirements

The manufacturer must implement specific cybersecurity controls defined in the product’s technical requirements specifications. For our Robo-Pal, these include, e.g.:

Requirement	Application to Robo-Pal
Default parental control	By default, the robot must deny the child access to security settings and restrict who can "call" the robot's speaker.
Automated updates	Since it connects to a public network, it must support and default to automated security updates to patch vulnerabilities without user intervention.
Authentication for harmful functions	The robot must verify an entity's identity (e.g., the parent's app) before allowing it to access the camera or GPS.
Secure storage	The robot must use "confidentiality-protecting secure storage" (encryption) for sensitive data like Wi-Fi passwords and user profiles.

Vulnerability Handling

The Robo-Pal must also comply with (also not yet cited in OJEU) EN 40000-1-3© for vulnerability management. This means the manufacturer must have a process for receiving, verifying, and remediating security flaws reported by researchers or discovered internally.

While ETSI EN 304 633 handles the toy’s internal security features, it delegates the “maintenance” duties to the EN 40000 series for vulnerability management.

Wrap-up

Here is a recap of some essential takeaways.

EN 304 633 is a vertical standard (not yet cited in OJEU and harmonized). It takes universal cybersecurity principles and “toys-ifies” them, focusing on the unique risks children face, such as unauthorized microphone access or location tracking.

Because Robo-Pal 3000 features social interaction (camera/mic) and tracking (GPS), a toy like the Robo-Pal is categorized as CRA Important Class I (Annex III, Pt 18). This allows manufacturers to use Module A (Internal Control) for conformity, provided they strictly adhere to this harmonized standard.

The standard’s strength lies in its modular Annex structure, which guides a product from design to the shelf on Legal & Risk, Execution, and Evidence.

By following the EN 304 633 prescriptive path, manufacturers gain a CRA presumption of conformity, legally signaling to regulators and parents alike that the toy is not just a gadget, but a secure companion for a child.

Graphics created with AI-support.

29. April 20269. August 2026

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?

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:

1. Requirement: A direct statement of the technical capability the component must provide (e.g., “The component shall provide the capability to manage accounts directly…“).
2. Rationale and Supplemental Guidance: Explains why the requirement exists and provides additional context.
3. 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“)
4. 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).
5. 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

The goal of FR 1 is to identify and authenticate all users (human, process, or device) before allowing access. The A11 Amendment updates the resistance capabilities for higher Security Levels to withstand sophisticated entities with significant resources.

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

The goal of FR 2 is to enforce assigned privileges to authenticated users (human, process, or device) and monitor their use. The A11 Amendment emphasizes resilience against entities with high levels of expertise and motivation.

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

The goal of FR 3 is to ensure the integrity of the component and protect against unauthorized changes. The A11 Amendment introduces higher assurance requirements to resist sophisticated entities attempting to subvert the boot sequence or system software.

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

The goal of FR 4 is to ensure the confidentiality of information at rest and in transit. The A11 Amendment mandates high-assurance cryptographic controls to protect sensitive IACS data against entities with sophisticated resources.

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

The goal of FR 5 is to segment the network into security zones and control the flow of data between them. The A11 Amendment updates resistance descriptors for higher Security Levels to withstand sophisticated entities with significant resources and motivation.

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

The goal of FR 6 is to respond to security violations by notifying appropriate entities and reporting as necessary. The A11 Amendment refines these requirements to ensure forensic readiness and effective log management against advanced persistent threats.

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

The goal of FR 7 is to ensure the availability of component resources against denial-of-service attacks and provide resilience through redundancy. The A11 Amendment introduces critical requirements for supply chain transparency and technical policy enforcement.

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

The goal of the Security Level (SL) framework is to define the qualitative resistance of a component against specific threat actor profiles. The A11 amendment refines these levels to ensure components provide state-of-the-art protection against sophisticated entities as mandated by the CRA.

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.

See also the next article CRA and internet-connected toys.

27. April 20269. August 2026

CRA harmonized standards sandwich and EN IEC 62443/A11

This article explores the CRA standards sandwich and specifically where EN IEC 62443/A11 fits.

The citation of EN IEC 62443/A11 in the OJEU is currently anticipated for late 2026 or early 2027.

The CRA standards sandwich

The CRA uses the principle called Lex Specialis, which means that more specific rules prevail over more general ones. Let’s illustrate this with Image #1:

Layer one of the sandwich, EN 40000-1-2 (and the vocabulary in EN 40000-1-1), provides the product-agnostic (horizontal) principles for cyber resilience that all PwDE must meet.

Layer two provides the product-agnostic (horizontal) catalog of technical security controls that all PwDE must meet.

With layer three, we’ve moved from being product-agnostic to, in this example, the broad group of OT industrial products, as defined by EN IEC 62443/A11. This is also often described as a “broad vertical” or “sector vertical“.

Finally, layer four contains harmonized, product-specific vertical standards. EN IEC 62443/A11 is being developed specifically for “Important class I/II” OT/ICS products under the CRA.

Presumption of conformity

Given this sandwich construction, how is the presumption of conformity achieved in various scenarios with an OT industry product?

The path to Presumption of Conformity follows the Lex Specialis principle. In our multi-layered sandwich, the law expects you to use the standard that is most tailored to your product to ensure the highest level of relevant security.

Here illustrated for the product, not the processes:

"Default"

You can technically claim presumption of conformity using only EN 40000-1-x. However, for OT IACS, you should include EN IEC 62443/A11 for two reasons:

- Annex ZZ in the A11 amendment: It includes a detailed mapping table that establishes a “presumption of conformity”
- Liability & Best Practice: If an incident occurs, “state‑of‑the‑art” (62443) is the yardstick by which your risk assessment will be judged. Using the horizontal standard alone for a complex OT device is often viewed as “doing the bare minimum,” which is a weak defense in IACS cybersecurity.

"Important C-I" but no product-vertical

The same as for “Default” because no relevant harmonized product-specific vertical is available.

"Important C-I" and a product vertical

The CRA follows the logic of the New Legislative Framework: If a vertical (product‑specific) harmonized standard exists and is cited in OJEU, it becomes the primary presumption path for that product category.

Note that the A11‑amended EN IEC 62443 standards also are being used as the foundational technical basis for multiple CRA vertical standards.

Wrap-up

EN IEC 62443/A11 covers a broad range of industrial products and is more specific than EN 40000-1-x but less specific than harmonized product verticals. It is thus not a pure “horizontal” standard, nor a pure “vertical” standard. It is often described as a “broad vertical” for OT IACS.

See also the next article EN IEC 62443-4-2/A11: A closer look.

Graphics created with AI-support

CRA recap

Approaching CRA

Overview: Step 1 - your destination

Overview: Step 2 - your inventory and prioritization

Gaps: Step 3.1 - gap analysis on your Secure Development Process - Annex I, Part I (1)

Gaps: Step 3.2 - gap analysis on your products/clusters conformity with CRA's ECR - Annex I, Part I (2)

Gaps: Step 3.3 - gap analysis on your Vulnerability Handling process - Annex I, Part II

Plan: Step 4 - plan gap-closure

Execute: Step 5 - close the gaps

Compliance Checklist

CRA Compliance Checklist

Position in the M/606 CRA Architecture:

Conformity Assessment Route

Important: Presumption of Conformity

Warning: Overwrite Data

Wrap-up

Let’s Turn Strategy Into Delivered Value

The Standardization Request M/606

Key purpose & scope

Let’s Turn Strategy Into Delivered Value

Is the upcoming EN IEC 62443/A11 family is already outdated?

Continuous risk management vs. point-in-time checklists

Machine-readable triage vs. manual supply chain tracking

Execution-layer neutralization vs. boundary-only defense

The CRA and the EU AI Act

Offensive cyber capabilities & malicious exploitation

Specific attack vectors with data poisoning, model poisoning, and evasion

Wrap-up

Let’s Turn Strategy Into Delivered Value

Key Mechanisms for Demonstrating Compliance

Procedural Rules & Special Provisions

Will we see Common Specifications from the Commission?

Let’s Turn Strategy Into Delivered Value

Highlights from the Guidance

Scope and "Placing on the Market"

Free and Open-Source Software (FOSS)

Substantial Modifications and Spare Parts

Support Periods

Important and Critical Products

Conformity Assessments:

Risk Assessments & Remote Data Processing Solutions (RDPS)

Reporting Obligations and Interplay with Other Laws

Wrap-up

Let’s Turn Strategy Into Delivered Value

COMMISSION IMPLEMENTING REGULATION(EU) 2025/2392

The Key Tables

Important Class I

Important Class II

Critical

Wrap-up

Let’s Turn Strategy Into Delivered Value

Let’s Turn Strategy Into Delivered Value

Scenario #1: The sub-component placed on the EU market as its own product

Scenario #2: The sub-component is custom made only for this WTG

Scenario #3: The sub-component supplier does not develop and add software

To conclude

Let’s Turn Strategy Into Delivered Value

So what to do?

Annex B

The overall tool design approach

The 62443-4-1 reference matrix

The three steps

Wrap-up

The Standards Sandwich

The audit tool

The tool header

The audit cards - one per requirement

Flow and findings

The sandwich link

Filled audit card examples

Administration header

View: Executive Matrix (Heatmap)

Wrap-up

Where is EN IEC 62443-4-1/A11in the standards sandwich?

The helicopter view - what is new

Harmonized EN IEC 62443-4-1 Evolution

Key Changes with the A11 amendment

Table of requirements

Product security context category

Applicability of security requirements and risk workflow