CRA for automation components: PLCs, HMIs, field devices and industrial switches

Your component is a product in its own right

If you supply programmable logic controllers (PLCs), human-machine interfaces (HMIs), field devices or industrial switches to machine builders and plant manufacturers, you are a manufacturer yourself under the Cyber Resilience Act (Regulation (EU) 2024/2847, CRA). A product with digital elements is “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately” (Art. 3(1)). A CPU module, a panel or a switch that you market under your name or trademark is therefore a product of its own (manufacturer: Art. 3(13)), even if it is only one part of your customer’s machine.

The prerequisite is a data connection: the CRA applies to products with digital elements made available on the market, “the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network” (Art. 2(1)). Simple field devices deserve a closer look, because the Regulation does not define the term. According to the draft Commission guidance on the application of the CRA, whose content the Commission approved on 27 July 2026 (C(2026) 5252, so far English only; formal adoption pending), states must be deliberately encoded as information and be capable of being decoded as information at the destination; a signal that only triggers or powers a function is not enough (para. 28). A sensor with IO-Link transmits encoded data; a plain switching output needs to be checked case by case.

On the status of the draft: according to the Commission’s accompanying communication, the guidance will be formally adopted once all language versions are available and will only apply from then. Even then it is not binding; an authoritative interpretation can only be given by the Court of Justice of the European Union (para. 8). We cite the draft only in addition to the Regulation, whose text remains authoritative.

The machine builder’s perspective is covered in our article Cyber Resilience Act for machinery, building automation controllers on the page building automation and BMS, firewalls and VPN appliances on the page network and security hardware. (This text provides a technical classification and is not legal advice.)

Why your customers ask for evidence

As manufacturer of its product, the machine builder “shall exercise due diligence when integrating components sourced from third parties” (Art. 13(5)). Recital 34 lists, depending on the risk, checks such as whether the component bears the CE marking, whether security updates are provided regularly and whether it appears in publicly accessible vulnerability databases. According to the draft guidance, the integrator also relies on documentation from the component manufacturer such as technical specifications or security documentation (para. 171). This leads to the questions in supplier questionnaires:

• Software bill of materials (SBOM): you draw up an SBOM “in a commonly used and machine-readable format covering at the very least the top-level dependencies” (Annex I Part II point 1) and keep it in the technical documentation (Annex VII point 2(b)). The CRA contains no express obligation to hand it to customers; Annex II point 9 only covers the case where you decide to make it available to the user. Passing it on is therefore a matter for your supply contract.
• Support period: it reflects the expected use time and is at least five years, shorter only where the product is expected to be in use for less time (Art. 13(8)); the end date must be specified at the time of purchase, including at least the month and the year (Art. 13(19)). Your customer may take into account the support periods of integrated components that provide core functions when setting its own (Art. 13(8), second subparagraph).
• Vulnerability information: once a security update is available, you publish information about fixed vulnerabilities (Annex I Part II point 4) and provide a contact address for reports (point 6). This is also how your customer reaches you, as it must report vulnerabilities in your component to you (Art. 13(6)).
• Integration guidance: if your product is intended for integration, the user information must include what the integrator needs to comply with Annex I and Annex VII (Annex II point 8(f)).

Typical products and their likely classification

Whether a product falls under Annex III (important, class I or II) or Annex IV (critical) depends on its core functionality (Art. 7(1), Art. 8(1)); the technical descriptions are laid down in Implementing Regulation (EU) 2025/2392 (IR). The table is an initial technical assessment and does not replace a binding classification of your product.

Integrating a component with an Annex III core functionality does not in itself make the overall product an important product (Art. 7(1), second sentence). If you also offer a communication module separately, however, it is a product of its own as a component placed on the market separately (Art. 3(1)), with its own core functionality; the draft guidance takes the same view (para. 145). Datasheet, instructions and technical documentation should describe the same intended purpose (Annex VII point 1(a)); a PLC advertised in a brochure as a “security router” deserves a second look. An unmanaged switch without a management plane does not readily match the IR description and needs to be checked case by case.

You assess default products yourself (module A, Art. 32(1)). In class I, module A is only available where harmonised standards, common specifications or a European scheme of at least assurance level “substantial” are applied in full, otherwise module B+C or H applies (Art. 32(2)); class II requires module B+C, H or such a scheme (Art. 32(3)). More in our article on CRA product classes.

IEC 62443-4-1 and -4-2: a practical framework without presumption of conformity

IEC 62443 is established in automation: part 4-1 covers the secure development process, part 4-2 technical security requirements for components of automation systems. Standards only give rise to a presumption of conformity, however, where they are harmonised standards whose references have been published in the Official Journal of the EU, and only to the extent that they cover the requirements (Art. 27(1)). On 1 November 2026, no harmonised standard for the CRA had been published in the Official Journal; IEC 62443 therefore does not currently give rise to a presumption of conformity. An established 62443 process is still useful: without harmonised standards, the technical documentation describes the solutions adopted (Annex VII point 5), and the evidence can be placed there. Compare your 62443 evidence requirement by requirement with Annex I and the other obligations, and add what it does not cover. This includes at any rate the notifications under Art. 14 via the single reporting platform; whether your risk assessment meets Art. 13(2) and (3) also belongs in this comparison. More on the page IEC 62443-4-1 and the CRA.

Complex systems, older protocols and legacy components

The CRA starts from the risk assessment: the requirements in Annex I Part I point 2 apply on that basis “where applicable”, and where a requirement is not applicable, a clear justification belongs in the technical documentation (Art. 13(3) and (4)). The draft guidance applies this to complex systems made up of several elements and placed on the market as a single product (paras. 29 to 32): long design cycles, older components and interoperability standards do not take them out of scope; constraints are to be documented, addressed with compensating measures and reassessed during the support period. For fieldbus protocols without built-in security, example 10 fits: the older protocol is permitted where interoperability requires it and the risks are mitigated by other means; where both are feasible, the secure protocol is implemented and enabled by default.

Example 11 of the draft concerns your customers: a manufacturer of an industrial automation system integrates microcontrollers bought before the CRA applies, after its risk assessment has identified no specific risks from them, and ensures that the system as a whole meets the requirements. For your own products, what counts is placing on the market, i.e. the first making available of a product (Art. 3(21)), which the draft applies unit by unit (para. 11). Units placed on the market before 11 December 2027 are subject to the requirements only if substantially modified afterwards (Art. 69(2)). Units of an older product line that you first supply after that date need a conformity assessment, an EU declaration of conformity and the CE marking (Art. 13(12)); the measures this requires follow from the risk assessment (Art. 13(2)).

Art. 2(6) excludes identical spare parts manufactured according to the same specifications; according to example 39 of the draft, this can also be a complete replacement PLC for an identified automation system, but not a successor chip with a different cryptographic implementation (example 37). According to recital 56, the requirements on automatic updates do not apply to products primarily intended for integration, nor to industrial environments where automatic updating could disrupt operations. You still provide security updates (Annex I Part II points 2 and 8).

Deadlines, remote data processing and the Machinery Regulation

The reporting obligations under Art. 14 have applied since 11 September 2026 (Art. 71(2)), including for products placed on the market before 11 December 2027 (Art. 69(3)): actively exploited vulnerabilities and severe incidents via the single reporting platform, with an early warning without undue delay and in any event within 24 hours of becoming aware (Art. 14(1) to (4)). All other obligations apply from 11 December 2027 (Art. 71(2)). More on the page reporting process and PSIRT.

If you operate a portal for remote access, configuration or update distribution, check remote data processing: software that you design and develop yourself or under your responsibility, and without which the product could not perform one of its functions, is part of the product (Art. 3(1) and (2)). Safety controllers may also fall under the Machinery Regulation (EU) 2023/1230, which lists “logic units to ensure safety functions” as safety components (Annex II point 4); “logic units to ensure safety functions” are also listed in Annex I, Part B, point 17, for which Article 25(3) of the Machinery Regulation provides specific conformity assessment procedures. The CRA does not exclude them; its exclusions in Art. 2(2) to (4) concern medical devices, in vitro diagnostic medical devices, vehicle type approval, civil aviation and marine equipment.

A constructed example

A medium-sized manufacturer supplies compact controllers, touch panels, a managed switch and a PROFINET module that can also be ordered separately. A machine builder asks for an SBOM per firmware version, the end of the support period, how vulnerabilities are published and the status regarding IEC 62443-4-2. The manufacturer makes a technical assessment: controllers and panels likely default, switch and module likely class I. Because it cannot apply harmonised standards, common specifications or a European scheme, it plans a notified body for both. It sets end dates per product line, generates the SBOM from the firmware build, publishes security advisories with a coordinated vulnerability disclosure policy, writes integration guidance and answers the questionnaire from these documents. Who is the manufacturer when a customer resells panels under its own brand is flagged for review by its legal department.

Next steps

1. Create a product list with variants and record the core functionality of each product, including separately sold modules.
2. Check your reporting process under Art. 14, because it already applies.
3. Set support periods and generate the SBOM per release from the build.
4. Prepare customer documentation: integration guidance, security advisories, a contact address for vulnerabilities.
5. Plan the conformity route per product, involving a notified body early for class I.

In the CRA gap analysis, Blackfort Technology assesses the classification of your components from a technical standpoint, includes your customers’ questionnaires and flags open legal questions, such as role or product class, for review by your legal department. We introduce the SBOM and vulnerability handling with your teams in our SBOM consulting. A first step is the applicability check; to talk to us: get in touch.