CVD: drafting and publishing a coordinated vulnerability disclosure policy

A public document most manufacturers have never produced

Before the Cyber Resilience Act, no European product regulatory framework required connected product manufacturers to publish a channel enabling third parties to report vulnerabilities to them. Some actors in the IT sector had adopted this practice voluntarily, drawing on the norms of the security research community. In the electronic security, home automation, or connected industrial equipment industries, it was the exception.

The CRA changes this structurally. Annex I Part II, point 1 requires manufacturers to establish and apply a coordinated vulnerability disclosure policy. This is a mandatory essential requirement, on the same footing as the design requirements of Annex I Part I. Its absence is a direct non-conformity finding. It must be in place before products subject to full CRA conformity are placed on the market (11 December 2027) but, a point often underestimated, it must be operational by September 2026 to support the Article 14 notification obligations.

This distinction deserves emphasis. Article 14 requires any manufacturer that becomes aware of an actively exploited vulnerability in one of its products to notify ENISA within 24 hours. The question is: how will a security researcher, an integrator, or a technically sophisticated user who discovers a vulnerability in your product inform you of it, if no public reporting channel exists? The CVD is the reception infrastructure without which the Article 14 clock can never start within the legal timeframe: because notification will not arrive, or will arrive through unpredictable channels (social media, national CERTs, direct public disclosure).

CVD and internal procedure: two distinct documents

A frequent confusion in CRA projects is treating the CVD and the internal vulnerability handling procedure as a single document. They are two different documents, with different audiences, different functions, and different confidentiality levels.

The CVD policy is a public document. It is addressed to security researchers, integrators, customers, partners, any third party who might discover a vulnerability in your products. It communicates the manufacturer's commitments to external reporters. It is published on the manufacturer's website and referenced in the security.txt file. It does not describe internal processes: including in a public document the names of responsible teams, tools used, or patch development timelines would be an unwanted operational exposure.

The internal vulnerability handling procedure is a confidential operational document. It defines who does what internally when a report arrives (RACI, Article 14 timelines, severity criteria, escalation). It is the basis for the operational note designating the PSIRT coordinator: a single person can be sufficient depending on the organisation's size, but must be formally designated, with an on-call arrangement defined for critical reports received outside business hours given the 24-hour Article 14 deadline. Its structure is defined by prEN 40000-1-3 (Phase [PRE-1]) and EN ISO/IEC 30111. The regulatory notification procedure (notification to ENISA and the national competent authority within Article 14 timelines) is distinct and also covered by prEN 40000-1-3, which defines its formalism and triggering criteria.

Publishing the internal procedure in place of a genuine CVD exposes operational processes without providing the assurances researchers expect from a serious CVD policy. Conversely, having a published CVD with no internal procedure to support it creates public commitments that cannot be honoured, a source of legal and reputational risk.

What the CVD must contain: the regulatory minimum and recommended content

prEN 40000-1-3 (Phase [PRE-2]) specifies the requirements for the CVD policy. In combination with EN ISO/IEC 29147 (vulnerability disclosure), which serves as the reference framework, the following elements must appear in the CVD:

Contact channel

Mandatory requirement ([PRE-2-RQ-02]): at least one contact mechanism must be provided. In practice, the operational minimum is a dedicated, non-personal email address: security@domain.com or vuln@domain.com. A web form is recommended in addition, as it structures incoming reports and reduces noise. The email address must be monitored during business hours, with an on-call arrangement defined for critical reports. A published email address without active monitoring is worse than none: it creates an expectation of response that will not be met.

Scope

The CVD must specify which products and what support period are covered. If legacy products are explicitly excluded, because their support period has been exhausted and the manufacturer has formally documented this exclusion (Article 14 CRA), this must be stated. This transparency prevents researchers from investing time in products for which no patch will be produced, and subsequently publishing directly in the absence of a response.

Acknowledgement and response timelines

Mandatory requirement ([PRE-2-RQ-03]): communication expectations must be stated. The CVD must specify the timeframe within which the manufacturer acknowledges receipt of a report (common practice: 5 business days) and the timeframe within which a substantive response is provided (validity confirmation and remediation plan). These timelines become enforceable commitments : researchers can invoke them to justify early disclosure if the manufacturer fails to meet them.

Embargo period and disclosure strategy

The embargo period is the duration during which the vulnerability is kept confidential during patch development. The industry standard is 90 days, with the possibility of extension for documented technical complexity. The CVD must state: the default embargo duration, the conditions under which it may be extended or shortened, and what happens in the event of premature disclosure by the reporter. It must also specify whether the manufacturer publishes public security bulletins, coordinates with national CERTs (CERT-FR for France), or notifies through the EUVD database.

Safe harbour clause

This is the legally most sensitive element of the CVD, and paradoxically the one that most determines the quality of reports received. A security researcher who discovers a vulnerability in your product takes a legal risk if they must conduct tests on your infrastructure or firmware to characterise it. Without an explicit commitment by the manufacturer not to pursue legal action against a researcher acting in good faith within the scope defined by the CVD, serious researchers do not report, they publish directly, or work through intermediaries (CERTs, journalists). The first path triggers Article 14 through an uncontrolled channel; the second dilutes the manufacturer's control over disclosure.

In the French legal context, the safe harbour clause must be assessed against Article 323-1 of the Code pénal (unauthorised access to automated data processing systems) and Article L.122-24 of the Code de la propriété intellectuelle (reverse engineering restrictions). The formulation of this clause cannot be generic: it must precisely define the scope (covered products, permitted test types, good faith conditions) to be enforceable. This is a 2–3 day engagement for a digital law specialist, and a cost that should be budgeted into the CRA project. It is shared between the CVD and PSIRT workstreams and should not be commissioned twice.

security.txt: the operational entry point of the CVD

The security.txt file is defined by RFC 9116 (IETF, May 2022). It is a standard text file, published at the URL /.well-known/security.txt on the manufacturer's web domains, centralising security contact information in a format readable by both humans and automated tools.

The minimum mandatory fields under RFC 9116 are:

• Contact: — the reporting URL or email address (multiple entries permitted);
• Expires: — the validity expiry date of the file (beyond which its content should no longer be considered current).

Recommended fields for a CRA-compliant CVD:

• Policy: — URL of the full CVD policy;
• Preferred-Languages: — languages in which the manufacturer can process reports;
• Acknowledgments: — URL of a page acknowledging researchers who have reported vulnerabilities (hall of fame practice — optional but recommended as a positive signal to the research community).

The file can be digitally signed via OpenPGP if the manufacturer has a security key pair. Signing increases the file's credibility for advanced researchers but is not a normative requirement.

A frequently overlooked deployment point: security.txt must be deployed on all domains associated with a product — the manufacturer's corporate site, but also cloud service domains, mobile application domains, and installer portals. A researcher who discovers a vulnerability in a cloud service for an alarm system will first look for the security.txt on the cloud service domain, not necessarily on the manufacturer's corporate site.

What makes a CVD policy operational rather than decorative

A published CVD policy with no operational internal infrastructure behind it is a source of risk, not a protection. It creates public commitments (acknowledgement timelines, response timelines, embargo period) that will visibly not be met when the first real report arrives. This gives researchers documented justification for early disclosure, and market surveillance authorities a non-conformity basis under Annex I Part II.

The minimum operational infrastructure that must support the CVD by 11 September 2026 includes:

• A monitored inbox behind the contact channel: a ticket system or email inbox with processing SLA (no report left without response for more than 5 business days);
• An internal triage procedure — who assesses whether a report is valid, what its severity is (for example using a CVSS score), and who in R&D is responsible for remediation;
• A clear escalation path for reports reaching the Article 14 threshold : "actively exploited vulnerability" or "severe incident". Upon receipt of such a report, or upon the triage identifying it as such, the 24-hour Article 14 clock starts. There is no margin between reception and the escalation decision;
• Response templates — initial acknowledgement, triage response, closure response (patch published or documented rejection);
• A report register — required for CRA technical file documentation (Annex VII §2b — description of the vulnerability management process) and to demonstrate compliance with timelines in the event of a regulatory inspection.

The "awareness" trigger in Article 14

Article 14 CRA triggers notification obligations from the moment the manufacturer becomes aware of an actively exploited vulnerability or a severe incident. The CVD is one possible vector for this awareness, but not the only one. EUVD monitoring and SBOM correlation constitute a second active vector, independent of external reports.

A manufacturer who receives a report at security@, archives it without triage for 3 days, and then discovers that the vulnerability is being actively exploited, has violated their notification obligation: the 24-hour window begins at receipt of the report, not when triage identifies it as critical. This interpretation follows from prEN 40000-1-3 ([RCP] Reception) read in combination with Article 14 CRA: receipt of a report constitutes initial awareness, even if the full assessment has not yet been completed.

In practice, this means that the triage procedure must be backed by an initial assessment SLA (48 hours maximum for a first severity evaluation, regardless of complexity) so that reports that might trigger Article 14 are identified before the 24-hour window expires.

Implementation timeline

A realistic timeline for an SME starting the CVD project without existing infrastructure:

• Weeks 1–2: drafting CVD v0 (internal working draft, unpublished):  structure, scope, timelines, safe harbour clause pending legal validation;
• Weeks 3–6: legal validation of the safe harbour clause by a specialist in digital law;
• Weeks 3–6 (parallel): creation of the security@ email address, setup of ticketing system or alias, drafting of internal procedure v0 and PSIRT RACI;
• Weeks 6–8: finalisation of CVD after legal validation, deployment of security.txt on relevant domains, publication of CVD on the website;
• Before 11 September 2026: CVD published, monitored channel operational, activatable internal procedure, ENISA registration completed.

Conclusion

The CVD is not a communication document. It is a legally structured public commitment, which requires internal infrastructure to honour it. The drafting itself is rapid: a few days of focused work. The difficulty is ensuring that it is supported by an organisation capable of responding within the stated timelines and of triggering regulatory notifications when the situation calls for it.

The absence of a CVD by 11 September 2026 leaves the manufacturer without a vulnerability reception infrastructure, which means that actively exploited vulnerabilities in its products will be brought to its attention through uncontrolled channels, after the Article 14 24-hour window has already passed. This is not an abstract hypothesis: it is precisely the scenario that Article 14 is designed to prevent.