ICS manufacturers should not reuse outdated proposal-era classification tables. The final CRA requires a product-specific scope and classification analysis, followed by security engineering that reflects industrial realities: deterministic control, privileged engineering functions, industrial protocols, remote maintenance, segmentation assumptions, redundant controllers, constrained maintenance windows and long support periods. The technical file should separate product security responsibilities from site-level operational controls that belong to the operator.
The Final CRA Does Not List ICS as a Generic Annex III Category
The enacted Annex III of Regulation (EU) 2024/2847 lists nineteen Class I categories and four Class II categories, but it does not contain a general category for industrial automation and control systems, SCADA, DCS or PLCs. Earlier proposal material did contain industrial-control categories. Manufacturers should therefore classify against the final Regulation and the 2025 technical-description implementing regulation rather than relying on superseded proposal lists.
An Industrial Product Can Still Match Another Annex III Category
An industrial control product can still be important when its core functionality matches a current Annex III category. Examples can include operating systems, network management systems, VPN products, routers, switches, firewalls or physical and virtual network interfaces. The important-product decision should be tied to the actual core functionality of the marketed product, not to the fact that it is deployed in an industrial plant.
Define the Product Boundary Separately From the Plant
An ICS deployment can contain controllers, engineering workstations, HMIs, historians, gateways, remote I/O, servers and third-party network equipment. The manufacturer should identify which elements constitute the product placed on the market and which are customer infrastructure or separately supplied products. This prevents the technical documentation from assuming responsibility for an entire plant architecture that the manufacturer does not control.
Protect Engineering Functions More Strongly Than Routine Operation
Engineering stations and maintenance interfaces can download logic, change controller parameters, alter network settings or replace firmware. These functions often have greater impact than ordinary operator commands. Product-specific access control should distinguish engineering, maintenance and operator roles, authenticate privileged actions and record security-relevant configuration changes where appropriate to the product and risk.
Industrial Protocols Should Be Tested as Hostile Input
Industrial products can process fieldbus, industrial Ethernet, telemetry and vendor-specific protocols that were historically designed for trusted networks. The CRA risk assessment should not rely on plant isolation as the only protection. Manufacturers should identify externally reachable protocol parsers, validate message lengths and state transitions, constrain unauthenticated commands where the product design permits and test malformed or unexpected protocol traffic.
Deterministic Control Changes the Availability Analysis
Industrial control can depend on predictable cycle times and continuous process availability. Security controls that add latency, trigger restarts or block communications can themselves affect the intended function. The manufacturer should therefore test security mechanisms and update procedures under realistic control loads and document how the product behaves when authentication, logging, cloud connectivity or security services are unavailable.
Remote Maintenance Is a Privileged Trust Boundary
Remote service channels can provide deep access into control products and are frequent targets in operational technology environments. The product design should document how remote access is enabled, authenticated, authorized, logged and disabled, whether customer approval is required and what infrastructure brokers the connection. Shared vendor credentials or permanently open maintenance paths create fleet-level exposure that should be addressed in the product risk assessment.
Configuration and Logic Integrity Need Versioned Evidence
Industrial products can be secure at the firmware level while running unauthorized or corrupted configuration and control logic. Where the product manages logic or configuration, the security design should consider integrity checks, authorization for downloads, version identification, backup and restore controls and auditability. The manufacturer should distinguish its software image from customer-created control logic while documenting the security mechanisms that protect that logic.
Security Updates Must Fit Industrial Maintenance Windows
Industrial systems can run continuously and may have narrowly scheduled outages. The CRA does not remove the need to handle vulnerabilities because a product is difficult to patch. Manufacturers should design update processes that support predictable maintenance, authenticity verification, compatibility checks and recovery, and should provide users with the information needed to install security updates without unnecessary operational risk.
Redundant and High-Availability Systems Need Coordinated Updating
DCS, SCADA and control products may use redundant controllers, servers or communication paths. Updating one node can change protocol versions, configuration state or failover behavior. Product evidence should test supported rolling-update or failover procedures and identify combinations of software versions that are allowed during transition so that security maintenance does not silently disable redundancy.
Long Lifecycles Need a Realistic Support-Period Strategy
Industrial products can remain installed for far longer than ordinary consumer software. CRA support-period planning should therefore be based on the expected use of the product and the Regulation's requirements rather than on a short enterprise-software release cadence. Component obsolescence, cryptographic ageing, supplier support and the ability to build and test fixes for old hardware should be considered early in product planning.
Separate Product Evidence From Operator Security Controls
Plant segmentation, asset inventories, jump hosts and security monitoring can reduce operational risk, but they do not replace manufacturer obligations for the product itself. The technical documentation should state deployment assumptions and user instructions while still demonstrating the product controls under the manufacturer's responsibility. This distinction is particularly important when a secure deployment depends on network zones or external identity infrastructure.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.