Independent information resource Product security · EU CRA
CRA product classification / 14

How the CRA Treats Industrial Automation Products

Understand how the Cyber Resilience Act applies to industrial automation hardware and software, why industrial automation is not a standalone CRA product class, and how individual products should be screened against Annex III and Annex IV.

IN BRIEF

The CRA does not classify products simply because they are used in industrial automation. Industrial sector use and CRA product classification are separate questions. Manufacturers should first determine CRA scope and product boundaries, then screen each industrial product against the current Annex III and Annex IV categories according to its core functionality.

01 / 12

Industrial Automation Is Not a Standalone CRA Product Category

Annex III does not contain a category named industrial automation products, industrial control systems or operational technology products. Annex IV also does not contain a general industrial automation category. That distinction is important because a manufacturer should not label an industrial product Class I or Class II merely because it is deployed in a factory, production line, warehouse, utility environment or other operational setting. The CRA classification system is based on the product's core functionality and the categories listed in the Annexes. Industrial use can be highly relevant to the cybersecurity risk assessment, but industrial context alone does not create an important-product classification.

  • Industrial automation is not a standalone Annex III category.
  • It is not a standalone Annex IV category.
  • Industrial deployment does not automatically mean Class I or Class II.
  • Product functionality determines the classification.
02 / 12

Many Industrial Products Can Still Fall Within CRA Scope

Article 2 applies the CRA to products with digital elements made available on the market where their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Article 3 defines a product with digital elements broadly as a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. Industrial automation products frequently contain processors, software, communications interfaces or control functions and can communicate directly or indirectly with other equipment. A network-connected industrial controller, embedded software product or separately marketed industrial communication component can therefore require CRA scope analysis even where it never connects directly to the public internet.

  • CRA scope is not limited to internet-connected consumer products.
  • Direct logical or physical connections can be relevant.
  • Indirect device or network connections can also be relevant.
  • Separately marketed hardware and software components can be products with digital elements.
03 / 12

Industrial Use Does Not Replace the Product-Boundary Analysis

Industrial automation architectures can contain many separate products: controllers, operator interfaces, embedded operating systems, communication modules, network devices, management software, engineering tools, security appliances and remote services. CRA classification should not treat the complete industrial environment as one product merely because the components work together. The manufacturer needs to identify what it actually places on the market under its name or trademark and which hardware, software and remote processing functions form that product. Separately supplied components can have their own CRA obligations and classification. The product boundary should therefore be established before screening Annex III and Annex IV.

  • Identify what is actually placed on the market.
  • Separate product, component and wider industrial system boundaries.
  • Identify separately supplied software and hardware.
  • Classify each relevant product according to its own core functionality.
04 / 12

An Industrial Operating System Can Be Class I

Industrial and embedded environments often use real-time or special-purpose operating systems. Operating systems are Annex III Class I category 11, and Commission Implementing Regulation (EU) 2025/2392 expressly includes real-time, general-purpose and special-purpose operating systems. An operating system supplied for industrial equipment therefore does not fall outside the category because it is embedded or used in an automation environment. Where operating-system functionality is the product's core functionality and the product is within CRA scope, the Class I classification can apply. The industrial machine or controller containing the operating system still requires its own product-level analysis rather than automatically inheriting the operating system's classification.

05 / 12

Industrial Network Management Products Can Also Be Class I

Network management systems are Annex III Class I category 6. An industrial product whose core functionality is managing connected network elements by monitoring them and controlling their network operations and configuration can therefore match that category. Industrial environments can contain specialised management systems for network devices, communications infrastructure and other connected elements. The classification should be based on the network-management technical description rather than the fact that the software is used in operational technology. A general production-management or process-control product should not be called a network management system merely because it communicates with networked equipment.

  • Network management systems are Class I.
  • Industrial use does not create a separate version of the category.
  • Monitoring and control of network operations and configuration are central.
  • General process-control software is not automatically network management.
06 / 12

Industrial Routers and Switches Can Match Annex III Class I

Annex III Class I category 12 covers routers, modems intended for connection to the internet and qualifying switches. The technical descriptions are based on routing, internet-modem and managed switching functionality rather than customer sector. A router or managed switch designed for industrial networks can therefore fall within the same category as a product deployed elsewhere when its core functionality matches the description. Commission Implementing Regulation (EU) 2025/2392 also identifies Fieldbus among examples associated with physical network interfaces, illustrating that the technical descriptions can extend into industrial communication environments. The manufacturer should classify the specific networking product rather than classify an entire industrial automation system from the presence of one network component.

  • Industrial routers can be Class I.
  • Qualifying managed switches can be Class I.
  • Fieldbus-related network interfaces can require separate category screening.
  • The host industrial system does not automatically inherit component classification.
07 / 12

Industrial Semiconductor Products Can Require Class I or Class II Screening

Annex III contains several semiconductor categories. Microprocessors and microcontrollers with security-related functionalities appear in Class I, together with ASICs and FPGAs with security-related functionalities. Tamper-resistant microprocessors and tamper-resistant microcontrollers appear separately in Class II. Industrial automation equipment can contain these components, but the complete equipment should not automatically be classified according to the component. A semiconductor component separately placed on the market can require its own classification, while the manufacturer of the larger industrial product should evaluate that product's own core functionality and treat the component as part of its supply-chain and cybersecurity risk analysis.

  • Security-related processors and controllers can be Class I.
  • Tamper-resistant processors and controllers can be Class II.
  • Separately supplied components can have their own classification.
  • The larger industrial product still needs its own product-level analysis.
08 / 12

Industrial Virtualisation Products Can Be Class II

An industrial deployment can also contain virtualisation infrastructure. Hypervisors and qualifying container runtime systems are Annex III Class II category 1 regardless of whether they are deployed in a datacentre, edge environment or industrial computing platform. Where a separately supplied industrial virtualisation product abstracts or allocates computing resources and enables execution and management of logically separated virtual machines, the Class II category can apply. A larger industrial appliance that simply uses a hypervisor internally does not automatically become a Class II hypervisor. The product boundary and core functionality still control the classification.

  • Hypervisor classification is not limited to cloud datacentres.
  • Industrial virtualisation software can be Class II.
  • Integrated hypervisors do not automatically reclassify the host appliance.
  • Classify the supplied product by its own function.
09 / 12

Industrial Firewalls Can Be Class II

Firewalls and intrusion detection and prevention systems are Annex III Class II category 2. A dedicated firewall designed for an industrial network can therefore be a Class II important product when firewall functionality is its core functionality. The industrial setting does not change the underlying CRA class. Conversely, an industrial controller or gateway that merely contains firewall functionality does not automatically become a Class II firewall. The manufacturer should distinguish the dedicated security product from the broader automation or communications product and document which function defines the supplied product.

  • Dedicated industrial firewalls can be Class II.
  • Industrial deployment does not alter the firewall category.
  • Integrated firewall capability does not automatically classify the host product.
  • Product purpose and core functionality remain central.
10 / 12

Many Industrial Products Can Remain in the Default CRA Category

An industrial product can be fully within CRA scope without matching Annex III or Annex IV. In that situation, it remains within the default product category for conformity assessment rather than becoming an important or critical product. The manufacturer still has to satisfy the applicable CRA requirements, including cybersecurity risk assessment, essential cybersecurity requirements, technical documentation, vulnerability handling and the applicable conformity process. The distinction matters because important and critical classification primarily changes the conformity assessment route. A manufacturer should therefore avoid forcing an industrial product into an Annex III category merely because the industrial environment is security-sensitive.

  • CRA-covered does not mean Annex III.
  • A product can remain in the default category.
  • Default-category products still have CRA obligations.
  • Classification mainly affects the available conformity route.
11 / 12

Industrial Product Classification Should Be Function Based

A repeatable industrial classification process should begin by identifying the exact product and version, intended purpose, reasonably foreseeable connectivity, product boundary and principal functions. The manufacturer should then screen the product against every plausible Annex III and Annex IV category using Commission Implementing Regulation (EU) 2025/2392. Where no category matches the product's core functionality, the record should state that the product remains in the default CRA category rather than leaving the classification undocumented. Where a category does match, the result should identify the applicable class and Article 32 procedure. Integrated components should be recorded separately so that their classification does not accidentally become the classification of the entire automation product.

  • Determine CRA scope first.
  • Define the industrial product boundary.
  • Identify core functionality.
  • Screen plausible Annex III and Annex IV categories.
  • Record default-category conclusions where no category matches.
  • Map any listed-category match to Article 32.
12 / 12

Industrial Risk Assessment Should Reflect Operational Consequences

The absence of a standalone industrial automation category does not make industrial risk unimportant. Article 13 requires manufacturers to undertake a cybersecurity risk assessment and take the result into account during planning, design, development, production, delivery and maintenance. Industrial products can control physical processes, communicate with other equipment or form dependencies within wider operational systems. The risk assessment should therefore reflect the actual intended environment, privileges, connectivity, foreseeable misuse and consequences of compromise. The classification decision and the risk assessment answer different questions: classification identifies the applicable conformity route, while the risk assessment determines how the product's cybersecurity risks and essential requirements should be addressed.

  • Classification and cybersecurity risk assessment are different processes.
  • Industrial operational consequences should inform the risk assessment.
  • Connectivity and privileges should be documented.
  • Security measures should reflect the actual product risk.
REFERENCE DESK

Official sources

Read the full legal text and Commission material for precise wording, qualifications and updates.

Editorial review: 26 September 2026. Regulatory material can change; follow the official sources for current guidance.