EU Cyber Resilience Act Guide for Industrial Automation & PLC Vendors

The CRA applies to PLCs, DCS components, industrial gateways, SCADA servers, HMI terminals, and industrial routers placed on the EU market. Annex III classification is determined by the product's function and network exposure. OT products that can affect industrial process control, manage energy distribution, or interface with safety instrumented systems (SIS) are classified as Important Class I at minimum.

Products deployed in critical infrastructure sectors — energy generation, water treatment, manufacturing of hazardous materials — may be assessed as Critical Class II depending on the specific functionality and the criticality of the processes they control. Vendors must not rely on customer deployment context alone; classification is determined by the product's capabilities as designed and placed on market, not the customer's particular installation. A PLC with a built-in Ethernet interface and remote programming capability is Class I regardless of whether the customer operates it in a critical facility.

OT product vendors face particularly demanding Annex I obligations because many legacy PLC and SCADA architectures were designed without cybersecurity as a primary concern. The CRA requires:

• Elimination of default credentials: All PLCs and HMIs must require credential configuration at first use. Factory-default username/password combinations are prohibited.
• Authenticated firmware updates: Industrial firmware update mechanisms must be cryptographically authenticated. Unauthenticated TFTP-based update paths must be eliminated.
• Network segmentation support: Devices must support, and ideally enforce, network segmentation — either via built-in firewall rules or by operating correctly in segmented OT network topologies.
• Audit logging: Devices must generate security-relevant audit logs (login events, configuration changes, firmware updates) accessible to authorised operators.
• SBOM: A software bill of materials must be maintained, including real-time OS components, protocol stacks (Modbus, PROFINET, EtherNet/IP), and any third-party libraries.

Vendors with products already certified under IEC 62443-4-2 (component security requirements) will find substantial alignment with CRA Annex I obligations.

Many OT vendors have historically handled vulnerability reports through informal sales or technical support channels, without a formal CVD programme. Article 13 of the CRA makes a formal, publicly disclosed CVD policy mandatory for all products with digital elements.

• Be publicly accessible via a security.txt file or dedicated security disclosure page
• Cover all CRA-scoped product lines, including legacy products still within their supported lifetime
• Define submission channels that are accessible to both sophisticated security researchers and industrial operators who may identify anomalous behaviour in the field
• Commit to acknowledgement within a defined timeframe and to remediation communication to affected customers

OT vendors should consider that their customer base — manufacturing plants, utilities, infrastructure operators — may have contractual or regulatory obligations that require them to receive timely security advisories. The CVD policy must therefore include a downstream communication commitment, not merely an internal triage process. CVD Portal supports CSAF 2.0 advisory generation for each resolved vulnerability, enabling automated distribution to subscribed asset owners.

Article 14 requires ENISA notification within 24 hours of becoming aware that a vulnerability in a product is being actively exploited. For OT vendors, this creates an operational challenge: industrial environments are often air-gapped or minimally monitored, meaning exploitation of a PLC vulnerability may be detected by a customer weeks or months after it begins.

Vendors should establish clear procedures for when the 24-hour clock starts: upon receipt of credible exploitation intelligence, whether from a customer, a security researcher, a national CSIRT, or threat intelligence monitoring. The initial ENISA notification confirms the product and the nature of the exploit; detailed technical content follows in the 72-hour report.

For ICS vulnerabilities, vendors should also co-ordinate with ENISA's ICS-CERT liaison contacts and relevant national CERTs (e.g., BSI in Germany, ANSSI in France) who maintain sectoral oversight of industrial cybersecurity incidents. CVD Portal integrates Article 14 deadline tracking with configurable multi-stakeholder notification workflows.

Class I OT products require third-party conformity assessment. For industrial automation vendors, IEC 62443-4-2 certification provides the most direct alignment with CRA Annex I requirements and may reduce the scope of additional notified body assessment work.

1. Annex I Part I technical security requirements (secure defaults, update integrity, network access control)
2. Annex I Part II vulnerability management process (SBOM, patch process, CVD policy)
3. Technical file completeness — architecture documentation, threat model, conformity declaration
4. CVD policy operational status

Vendors managing large product portfolios with multiple hardware generations should prioritise products still under active development for compliance remediation; end-of-life products that are nevertheless within their CRA-declared supported lifetime must also satisfy the Annex I Part II ongoing obligations (vulnerability monitoring and patching). Plan for notified body engagement by Q1 2026.