Does the CRA apply to industrial control systems?

Yes, the CRA applies to products with digital elements placed on the EU market, including industrial control systems, PLCs, HMIs, and industrial networking equipment. Products already fully covered by sector-specific EU legislation may be exempt - consult legal counsel. Many ICS manufacturers fall clearly within CRA scope and will need to comply with Article 13 and 14 obligations by 2027.

How do we handle vulnerabilities in safety-instrumented systems (SIS)?

Vulnerabilities in SIS components (IEC 61508 / IEC 62443 SL3–SL4) must be escalated immediately to your functional safety team and may require recertification after patching. The patch validation process for SIS components is significantly more complex than for standard IT software. Coordinate with your notified body if certification status is affected. Patient safety (for medical) or worker safety (for industrial SIS) takes priority over coordinated disclosure timelines.

What is ICS-CERT and when should we coordinate with them?

ICS-CERT (now part of CISA in the US) coordinates vulnerability disclosures for industrial control systems of broad significance, particularly when a vulnerability affects multiple vendors or could impact critical infrastructure across sectors or borders. ENISA plays a similar coordinating role in the EU. For vulnerabilities affecting a single product line, direct coordination with affected operators is usually sufficient. For systemic vulnerabilities (e.g. in a shared communication protocol), ICS-CERT/ENISA coordination is appropriate.

Our customers say they cannot patch because it requires a production shutdown. What do we do?

Provide network-level compensating controls as interim mitigations (e.g. firewall rules, VPN requirements, protocol filtering). Document these compensating controls in your advisory so operators can implement them quickly. Work with operators to plan a maintenance window for the full patch. For Critical vulnerabilities, consider whether operators should be advised to consider temporary shutdown if the exploitation risk exceeds the operational impact of a planned outage.

How should we handle zero-day disclosures in OT protocols that affect multiple vendors?

Multi-vendor OT protocol vulnerabilities (e.g. in Modbus, DNP3, OPC-UA implementations) should be coordinated through ICS-CERT and ENISA rather than individual vendor policies. Each affected vendor should have the opportunity to patch before public disclosure. The coordinated disclosure timeline may be extended beyond 90 days given the complexity of multi-party coordination and the operational constraints of OT patch deployment.

← All templates

Free Template

CVD Policy Template for Industrial and OT Manufacturers

A CVD policy template for manufacturers of industrial control systems (ICS), SCADA components, PLCs, HMIs, and other operational technology (OT) products. Addresses the unique challenges of OT environments: operational continuity requirements, long deployment cycles, critical infrastructure obligations, and sector-specific regulatory coordination.

Article 13 · Article 14 · Annex I

ForICS/SCADA component manufacturers, PLC and HMI vendors, industrial networking equipment makers, and OT security vendors placing products in EU critical infrastructure

CRA Articles

Article 13Article 14Annex I

Policy Statement

Article 13(1)

[COMPANY NAME] manufactures industrial control system (ICS) components and operational technology (OT) products deployed in critical infrastructure environments including [ENERGY / MANUFACTURING / WATER / TRANSPORT - select applicable]. We recognise that security vulnerabilities in industrial products carry operational and safety risks beyond those typical of consumer or enterprise software.

This Coordinated Vulnerability Disclosure (CVD) policy governs how we receive, assess, and respond to security vulnerability reports for [COMPANY NAME] products. It is maintained in compliance with the EU Cyber Resilience Act (Regulation (EU) 2024/2847), NIS2 Directive coordination obligations, and ICS-CERT best practices.

Note

Industrial CVD policies must acknowledge the operational and safety context explicitly. A vulnerability in a PLC or SCADA component can cause physical harm, production downtime, or critical infrastructure disruption - regulators and operators need to see that you understand this.

Scope

Article 13(4)

This policy covers all [COMPANY NAME] industrial products, including:

Programmable Logic Controllers (PLCs): [PRODUCT LINE, FIRMWARE VERSIONS]
Human-Machine Interfaces (HMIs): [PRODUCT LINE, SOFTWARE VERSIONS]
Industrial networking equipment: [ROUTERS / SWITCHES / FIREWALLS, VERSIONS]
Engineering workstation software: [SOFTWARE NAME, VERSIONS]
Remote access solutions: [PRODUCT NAME, VERSIONS]
Associated cloud-based monitoring services: [PLATFORM NAME]

Excluded from scope:

Vulnerabilities requiring physical access to secured operational environments (access to which constitutes a separate physical security issue)
Vulnerabilities in third-party SCADA software not distributed by [COMPANY NAME]
Products at end-of-support (see lifecycle page at [EOL URL])

For vulnerabilities in products used in safety-instrumented systems (SIS) or functional safety applications (IEC 61508 / IEC 62443 SL3–SL4 certified), please use our priority reporting channel.

Note

OT scope must address the full product stack: PLCs, HMIs, engineering software, and remote access tools are all common targets. Functional safety system vulnerabilities deserve explicit mention - they carry safety-of-life implications.

How to Report a Vulnerability

Article 13(1)

Report security vulnerabilities in [COMPANY NAME] products via:

Portal (preferred): [VULNERABILITY DISCLOSURE PORTAL URL] Email: [[email protected]] PGP key: Fingerprint [FINGERPRINT], available at [PGP KEY URL] Urgent / Safety-of-life issues: [PHONE NUMBER] (24/7)

Please include:

Product name, model, and firmware/software version
Protocol or interface affected (e.g. Modbus, DNP3, OPC-UA, EtherNet/IP, proprietary)
Deployment context if known (e.g. energy sector, water treatment, discrete manufacturing)
Whether the vulnerability can be exploited remotely or requires network adjacency / local access
Whether exploitation would affect process control (availability/integrity) or data confidentiality
Proof of concept and reproduction steps

Do not report vulnerabilities via public forums, social media, or sector-specific mailing lists before notifying us. Active exploitation of OT vulnerabilities can cause immediate operational harm.

Note

OT researchers need to describe the affected protocol and deployment context - these dramatically affect severity in industrial environments. A Modbus vulnerability with no authentication in a water treatment system is categorically different from the same issue in an isolated test bench.

Response Commitments and Operational Continuity

Article 13

[COMPANY NAME] commits to the following response timeline:

| Milestone | Target | |---|---| | Acknowledgment | Within 48 hours | | Initial severity and safety assessment | Within 5 business days | | Interim workaround or mitigation guidance | Within 14 days for Critical | | Patch or firmware update | Per severity SLA below | | Customer advisory to affected operators | Before or at patch release |

Severity SLAs: | Severity | CVSS Range | Patch SLA | Notes | |---|---|---|---| | Critical | 9.0–10.0 | 14 days | Interim mitigation may precede patch | | High | 7.0–8.9 | 60 days | - | | Medium | 4.0–6.9 | 120 days | - | | Low | 0.1–3.9 | Next release | - |

Operational continuity note: [COMPANY NAME] understands that critical infrastructure operators cannot always immediately apply patches or take systems offline for updates. We will provide interim mitigations and network-level compensating controls where possible, and will work with operators to plan update windows that do not disrupt operations.

Note

OT patch SLAs are typically longer than enterprise software SLAs because update windows in operational environments are constrained by production schedules and safety validation requirements. Be honest about this. An OT operator who cannot patch immediately still needs interim mitigations.

Critical Infrastructure and Regulatory Coordination

Article 14

Vulnerabilities in [COMPANY NAME] products may affect operators of critical infrastructure subject to the EU NIS2 Directive. Where a reported vulnerability could affect critical infrastructure operations, [COMPANY NAME] will:

Coordinate directly with affected operators via our critical customer notification process.
Notify the relevant sector CSIRT or national authority if required (see below).
Coordinate with ICS-CERT / ENISA where the vulnerability affects multiple vendors or is of systemic significance.

Article 14 (CRA) notification: Where a vulnerability is actively exploited or constitutes a severe security incident, [COMPANY NAME] will notify ENISA via the Single Reporting Platform within 24 hours (early warning) and 72 hours (full notification).

NIS2 coordination: Where affected operators are NIS2 essential entities, [COMPANY NAME] will proactively share advisory information with the relevant national CSIRT ([NATIONAL CSIRT NAME AND URL]) to support operator compliance.

ICS-CERT / sector coordination: For vulnerabilities of broad industrial significance, [COMPANY NAME] may coordinate disclosure through ICS-CERT (CISA) and ENISA's industrial CSIRT network.

Note

OT manufacturers serve critical infrastructure operators who have their own regulatory obligations under NIS2. Proactive coordination with sector CSIRTs and ICS-CERT is expected and builds significant credibility with operators. Include this even if you hope never to use it.

Safe Harbour

[COMPANY NAME] authorises security research conducted in good faith on our products in accordance with this policy. We will not pursue legal action against researchers who:

Conduct research only in isolated lab environments, not on live operational systems
Do not disrupt or attempt to disrupt production operations
Do not access or attempt to access operational technology owned or operated by third parties
Report to us before any public disclosure
Comply with applicable law

Lab environments: We strongly recommend and, upon request, can facilitate access to test firmware, simulation environments, or hardware in our security lab for qualifying researchers. Contact [[email protected]] to arrange.

Important: Attempting to reproduce OT vulnerabilities on live industrial systems is prohibited and may cause serious physical harm. Our safe harbour does not extend to testing on live operational infrastructure.

Note

OT safe harbour must absolutely prohibit testing on live operational systems. A researcher exploiting a PLC vulnerability in a live plant can cause physical harm, production loss, or safety incidents. Offer lab access as an alternative - it produces better research and safer outcomes.

Patch Validation and Deployment Guidance

Annex I

Industrial operators require additional assurance before deploying patches to operational environments. [COMPANY NAME] provides the following for all security patches:

Patch validation report: Documents testing performed, regression scope, and any known limitations
Deployment guidance: Step-by-step installation instructions, rollback procedure, and estimated downtime
Compatibility matrix: Confirmed compatibility with known third-party SCADA platforms (e.g. [LIST])
Functional safety impact statement: For SIS-relevant products, confirmation of IEC 61508 / IEC 62443 certification status post-patch

Patches are delivered via [AUTOMATIC UPDATE SERVICE / MANUAL DOWNLOAD AT [URL] / FACTORY AUTHORISED SERVICE CENTRE].

For customers who cannot apply patches immediately, [COMPANY NAME] provides network-level mitigation guidance as an interim compensating control.

Note

OT operators are justifiably cautious about patching - a bad patch can take a production line offline. Providing validation reports and rollback procedures reduces operator hesitation and accelerates deployment of critical security fixes.

Use this template automatically in CVD Portal

CVD Portal generates your CVD policy, tracks acknowledgments, and creates an audit trail — free for Article 14 compliance.

Set up your free portal

Frequently asked questions

Ready to go beyond the template?

CVD Portal automates acknowledgments, tracks deadlines, and generates CSAF advisories — free.

Set up your free portal

Related templates

CRA-Compliant CVD Policy Template

A comprehensive CVD policy structured specifically for the EU Cyber Resilience Act. Addresses Articles 13 and 14 obligations including 24-hour early warning, 72-hour full notification, and coordinated disclosure timelines.

CVD Policy Template for IoT Manufacturers

A CVD policy template tailored to the specific challenges of IoT and connected device manufacturers: long product lifespans, constrained firmware update mechanisms, heterogeneous fleets, and supply chain complexity. Structured for CRA compliance.

PSIRT Charter Template

A formal charter for establishing or formalising a Product Security Incident Response Team (PSIRT). Defines the team's mandate, authority, scope, membership, and operating procedures under the EU Cyber Resilience Act and ISO/IEC 30111.

Article 14 Early Warning Notification Template

A structured notification template for the CRA Article 14 24-hour early warning obligation. Designed to be submitted to ENISA (or the relevant national CSIRT) when a manufacturer discovers an actively exploited vulnerability or severe security incident.