CVD Policy for Machinery: What the ENISA Template Leaves Open

In October 2026, the EU Agency for Cybersecurity (ENISA) published a draft titled "Technical Advisory on security.txt, CVD Policies and Security Advisories," with the subtitle "SME Vulnerability Kit." Small manufacturers can use its templates for security.txt, a coordinated vulnerability disclosure (CVD) policy, and security advisories. The templates cover only part of Annex I, Part II of the Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA. The CVD policy also lacks a rule that manufacturers of machinery and plants need.

A CVD policy defines how third parties report vulnerabilities, how the manufacturer responds, and when it publishes. Under Annex I, Part II, point 5 of the CRA, manufacturers must put such a policy in place and enforce it. According to its legal notice, the ENISA draft reflects only the agency's own view. It creates no obligations and, by its own account, does not replace official guidance on the CRA.

Contents

1. ENISA puts three templates for SMEs up for consultation
2. The security.txt file and the advisory also cover the web interface and cloud app
3. The package does not cover three of the eight obligations in Annex I, Part II
4. The CVD template does not explicitly exclude tests on machines in operation
5. The draft is imprecise on reporting channels and deadlines
6. For machinery and plants, the OT notes matter most

ENISA puts three templates for SMEs up for consultation

The package addresses manufacturers of products with digital elements, especially micro, small, and medium-sized enterprises (SMEs) with few staff for legal and compliance work. It contains a security.txt file based on RFC 9116, a CVD policy with ten sections, and a template for security advisories. It builds on the CRA requirements for vulnerability handling and on the draft standard prEN 40000-1-3. Our overview of harmonized standards for the CRA shows how this series of standards is structured.

The package does not cover secure development, internal remediation workflows, incident response, or vulnerability management at suppliers. ENISA provides the draft as a PDF on its website. In the field table for security.txt, the label "Mandatory" refers to RFC 9116, according to footnote 5, and creates no legal obligation.

The security.txt file and the advisory also cover the web interface and cloud app

Take a machine controller that uses an embedded web server as its human-machine interface (HMI), with a cloud companion app from the manufacturer. Under the draft, the security.txt file sits at least at /.well-known/security.txt, is served only over HTTPS, and its Expires field reaches no more than 12 months into the future. It belongs on the manufacturer's main domain and on every domain that belongs to the product. In this example, the app's domain therefore needs its own file too.

For the embedded web server, the draft offers two options. Either the web interface or the product documentation points to the manufacturer's disclosure information, or the device gets its own security.txt with a clear scope and a current contact. Under Annex II, point 2 of the CRA, the single point of contact must also appear in the information for users.

The advisory template provides for identifiers from Common Vulnerabilities and Exposures (CVE) or the European Vulnerability Database (EUVD). It also includes a Common Vulnerability Scoring System (CVSS) score with vector, an optional "Safety impact" field, and the target audience, such as operators, integrators, or service partners. ENISA treats a public index of all advisories as evidence of ongoing compliance. As a machine-readable format, it recommends the Common Security Advisory Framework (CSAF) and refers to Article 14(8) of the CRA, which provides for informing users, where appropriate, in a structured, machine-readable format. We read the template as a merger of Annex I, Part II and the draft standard. The regulation does not explicitly require the index; ENISA turns it into evidence.

The package does not cover three of the eight obligations in Annex I, Part II

In Annex A.1, ENISA itself states that the templates alone do not fulfill the obligations and that manufacturers must actually run the underlying processes. Our mapping, based on that annex:

Requirement (Annex I, Part II)	Supported by	Degree according to ENISA	What remains with the manufacturer
Point 1: Identify vulnerabilities and components, software bill of materials (SBOM)	no template	none	Build and maintain the component list
Point 2: Remediate vulnerabilities without delay	CVD policy (targets for response and remediation)	supported	The remediation itself, setting deadlines
Point 3: Test and review	no template	none	Internal development process
Point 4: Disclose fixed vulnerabilities	CVD policy, advisory	supported	One advisory per vulnerability, maintaining the index
Point 5: Put in place and enforce a CVD policy	CVD policy	supported	Adaptation, responsibilities, resources
Point 6: Information sharing, contact address	security.txt, CVD policy	supported	Keep channels available and monitor them
Point 7: Distribute updates securely	no template	none	Update mechanism
Point 8: Distribute updates without delay and free of charge, with advisory messages	advisory	partial	Distribution and notices to users

The templates mainly cover what is visible from the outside. The component list, testing, and secure update distribution have no template, and in our assessment that is where most of the effort lies. Our article on SBOM requirements under the CRA describes how far the obligation to keep a component list extends.

The CVD template does not explicitly exclude tests on machines in operation

Section 2 of the CVD template excludes tests on systems, services, and infrastructure "not owned or controlled by" the manufacturer. The testing rules in section 4 prohibit denial-of-service tests and any disruption of the manufacturer's systems. They say nothing about safety or ongoing operation.

In the example, a researcher reaches the HMI of a controller that runs in production at a customer site. Does that plant count as "controlled by" the manufacturer, for example because the manufacturer services it through remote maintenance? The template does not answer this.

The draft names the core issue only in the implementation notes for the CVD policy. According to these notes, a safe harbor can authorize tests only on the manufacturer's own systems and not on third-party systems. The legal situation also differs between member states. In our view, this note belongs in the template itself. Manufacturers publish the template text, while the implementation notes stay in the ENISA document.

The draft is imprecise on reporting channels and deadlines

According to the draft's paragraph on the NIS2 Directive (Directive (EU) 2022/2555), one security.txt file and one monitored reporting channel are enough for both legal acts. The policy should still clarify whether a report concerns products, reported under Article 14 of the CRA, or the manufacturer's own networks, reported under Article 23 of NIS2. That reads as if every report had to be passed on to an authority. Under Article 14 of the CRA, however, only actively exploited vulnerabilities and severe incidents must be reported. Under Article 23 of NIS2, only significant incidents must be reported. An ordinary researcher report about your controller triggers neither notification. Our article on which vulnerabilities must be reported under the CRA explains which cases fall under these rules.

The draft mentions the early warning within 24 hours. It does not mention that Article 14 of the CRA has applied since September 11, 2026. Nor does it mention that, under Article 69(3) of the CRA, the obligation also covers products placed on the market before December 11, 2027. For a controller that has been in the field for years, the reporting obligation therefore already applies today, as described in CRA reporting obligations also apply to existing products.

The overview of the CVD policy announces default values for response times. The table in section 6 of the template contains only placeholders, though. The only fixed value is the acknowledgment of receipt within 7 calendar days, which ENISA attributes to the draft standard in footnote 7. You set the deadlines for triage, status updates, and embargo yourself.

For machinery and plants, the OT notes matter most

The implementation notes include a paragraph on machinery and other OT products. For these products, a fix may require revalidation, including of safety functions, and often can only be installed in a planned maintenance window. If a fix takes longer than the target times, provide mitigations and supporting measures first; the draft refers to question 4.3.1 of the European Commission's FAQ on the CRA. ENISA writes: "CVSS describes severity, not the risk in a specific operating environment."

For the controller in the example, the advisory therefore describes the situation from the operator's point of view. It names segmentation and disabling remote access as supporting measures and uses the "Safety impact" field. Section 3 of the advisory template states that such measures do not replace a necessary fix. Add the check for active exploitation to your CRA reporting process so that it happens for every report.

We consider the CVD template a usable starting point, and machine builders can adopt it. The draft itself points to two additions. In section 2, explicitly exclude plants in operation at customer sites, and in section 6, enter deadlines that take maintenance windows into account. ENISA accepts comments on scope, testing rules, and deadlines by November 15, 2026.