On 11 September 2026, the operational obligations of the Cyber Resilience Act came into force. Most technical teams focused on the notification deadlines: 24 hours for the initial alert to ENISA, 72 hours for the full notification, 14 days for the final report. These deadlines concern vulnerabilities that you detect yourself. There is a second obligation, often overlooked: the coordinated vulnerability disclosure (CVD) policy. It is the document that governs the reverse entry point: how a security researcher, a user or a partner can report a flaw in your product. In three days, its absence will constitute non-compliance.
What the regulation requires exactly
Regulation (EU) 2024/2847, in Article 13(6), requires any manufacturer or publisher of products with digital elements to establish and apply a coordinated vulnerability disclosure policy. Article 14 specifies that this policy must be accompanied by a single, public and accessible point of contact through which third parties can submit their reports.
The distinction from the notification deadlines is fundamental. The 24-hour and 72-hour periods apply to an actively exploited vulnerability that your organisation detects in its own product. The CVD policy applies to an incoming flow: someone outside your organisation has found a flaw in your product and is looking for a channel to inform you. Without a formalised policy, that researcher has no door to knock on. They publish directly, or they give up. In both cases, you have lost the chance to fix the flaw before it is exploited.
The European Commission explicitly aligns this obligation with ISO/IEC 29147:2018, which defines the expected content of a responsible disclosure policy, and ISO/IEC 30111:2019, which covers internal processes for handling reported vulnerabilities. A security.txt file containing an email address does not constitute a policy within the meaning of the regulation.
Why most publishers have not yet formalised a policy
The European Commission estimates that 60 % of manufacturers concerned by the CRA are SMEs (impact assessment of the CRA regulation, October 2024). For these structures, the absence of a CVD policy is rarely a deliberate choice: it is a non-issue that has never been addressed because nobody has received an external report before. The regulation reverses this logic: the policy must exist before the first report, not in response to it.
Large organisations often have a security@ mailbox, sometimes a security.txt file. They believe they have covered the topic. That is not enough. The CVD policy must specify what you do with a report once received, within what timeframe you respond, and what you commit to with respect to the researcher who helped you. These commitments must be public and enforceable.
The first NIS2 maturity audits point to the same finding. Among the five systematic gaps identified in preliminary reports covering fourteen Member States, the absence of a responsible vulnerability disclosure policy features prominently, alongside an outdated supplier risk register and the lack of MFA on administrator access. The CRA now extends this requirement beyond NIS2 operators: it covers all manufacturers and publishers of digital products on the European market.
A test conducted in 2025 by researchers at the University of Delft simulated a vulnerability report to one hundred European SaaS publishers. 43 % had no dedicated security contact address. Among those that did, the median delay before a first response was eleven days. ISO/IEC 29147:2018 recommends an acknowledgement within seven days, a threshold that the European Commission has adopted in its guidelines published on 27 July 2026.
Furthermore, according to the ENISA Threat Landscape report of January 2026, 34 % of actively exploited vulnerabilities in the European perimeter have a CVSS score below 7.0. This figure highlights a structural blind spot: organisations filter their priorities by score, while attackers exploit flaws that internal teams would not have prioritised. An external researcher who finds this type of flaw in your product, and cannot find a clear reporting channel, will not come back a second time.
The five elements of a minimal, compliant policy
A CVD policy is not a hundred-page document. Its effectiveness rests on five precise clauses, which most teams can draft and publish in a day.
The contact channel. A dedicated address, preferably with a PGP key for sensitive reports. The address must appear in the security.txt file at the root of the domain and on the Security or Privacy page of the website. The regulation requires that this channel be publicly identifiable.
The scope covered. Which products, which versions and which services fall within the policy. A publisher that distributes several products may opt for a single global policy or separate policies per product. Without a defined scope, the policy cannot be applied in practice.
Timing commitments. Acknowledgement within seven days. Initial assessment within fourteen days. A fix made available within a timeframe proportionate to severity: most reference frameworks adopt 90 days for critical vulnerabilities and 180 days for others. These timeframes may be adjusted according to the complexity of the product, but they must be explicit and public.
The researcher protection clause. You commit not to pursue a researcher who acts in good faith within the framework of your policy. In return, you ask the researcher not to actively exploit the flaw or publish it before a fix is available. ENISA explicitly recommends this clause in its 2024 CVD guidelines; its absence weakens the attractiveness of your programme and may discourage legitimate reports.
Reference to the national CSIRT. For vulnerabilities of critical or national scope, the CERT-FR of France's national cybersecurity agency (ANSSI) can act as a mediator between the researcher and you. The policy must mention this alternative channel, in line with the coordination architecture provided for by the regulation.
These five elements fit on two pages. A mid-sized SaaS publisher can formalise and publish them before 11 September. The effort is modest. The absence, on the other hand, will be the first thing an auditor checks: the policy is public, so it is observable, either present or absent.
The CVD policy and the ENISA notification deadlines are two sides of the same vulnerability management system. For the practical details of active reporting via the Single Reporting Platform, see the article on the CRA and 24-hour vulnerability notification. To build the technical base that makes it possible to detect a flaw in a third-party software component quickly, the article on SBOMs under NIS2 and DORA details the generation methods and available tools. The three topics are linked: without an up-to-date software inventory, detection is blind; without a CVD policy, external reports have nowhere to go; without a notification process, the regulatory deadlines cannot be met.