The CRA requires a coordinated vulnerability disclosure policy but does not prescribe one universal template. Manufacturers can create a product-appropriate policy that explains how security researchers report potential vulnerabilities and how the manufacturer coordinates investigation, remediation and disclosure.
Start With the CRA Requirement, Not a Generic Template
Annex I Part II point 5 requires the manufacturer to put in place and enforce a policy on coordinated vulnerability disclosure. Point 6 separately requires a reporting contact, Annex II requires users to be told where the CVD policy can be found, and Annex VII includes the CVD policy within the vulnerability-handling information in the technical documentation. A useful policy should therefore match the manufacturer's real process rather than copy commitments from another organisation that the manufacturer cannot enforce.
- Create a policy that matches the actual process.
- Publish or make the policy discoverable as required by Annex II.
- Connect the policy to the reporting contact.
- Retain the policy in technical documentation.
Define the Policy Scope
The policy should explain which products, services, components or product versions are covered by the reporting process. Clear scope helps researchers determine whether they have reached the correct manufacturer and gives the internal team a starting point for routing. The scope should not be written so narrowly that reports concerning third-party components contained in the product are automatically discarded, because Annex I point 6 expressly includes potential vulnerabilities in those components.
- Identify covered products.
- Identify relevant services where appropriate.
- Address third-party component reports.
- Explain obvious exclusions without blocking useful reports.
Publish the Reporting Contact Clearly
The policy should identify the product security contact or reporting mechanism. Reporters should not need to search corporate legal pages or ordinary customer-support menus to find it. Annex II requires the single point of contact and the location of the CVD policy to be communicated in the product's user information. The policy and contact information should therefore remain consistent across the website, documentation and product instructions.
- Provide the reporting contact.
- Keep it consistent across user information.
- Use a durable mechanism.
- Review links and addresses periodically.
Tell Reporters Which Information Is Useful
The CRA does not prescribe one mandatory vulnerability-report form. The manufacturer can nevertheless explain which information helps investigation, such as the product and version, affected component, reproduction steps, observed impact, proof-of-concept information and reporter contact details. Requirements should remain proportionate. A report should not be ignored merely because a researcher did not complete every preferred field if the submission contains actionable security information.
- Product and version.
- Affected component where known.
- Reproduction steps.
- Observed security impact.
- Supporting evidence.
- Reporter contact details where provided.
Explain the Acknowledgement and Investigation Process
A policy can tell reporters what generally happens after submission: receipt, acknowledgement, technical validation, affected-version assessment, remediation and disclosure coordination. The CRA does not prescribe one universal researcher-response deadline. Manufacturers should therefore avoid presenting voluntary service targets as if they were statutory deadlines. Any response commitments included in the policy should be realistic for the manufacturer's product risk and staffing model.
- Describe acknowledgement.
- Describe validation.
- Describe remediation coordination.
- Use realistic communication targets.
- Do not confuse internal targets with CRA statutory deadlines.
Describe Responsible Testing Expectations
Manufacturers can explain reasonable expectations for vulnerability research, such as avoiding unnecessary harm, data destruction, privacy intrusion or disruption to other users. The policy should remain focused on helping legitimate researchers report security problems rather than creating vague restrictions that discourage reporting. Any legal language should be reviewed in the context of applicable law and the manufacturer's own risk position.
- Avoid unnecessary disruption.
- Avoid unnecessary access to third-party data.
- Use the reporting channel promptly.
- Protect sensitive vulnerability details during coordination.
Safe-Harbour Language Is an Optional Policy Choice, Not a Named CRA Requirement
Some vulnerability disclosure policies include safe-harbour or good-faith research language. The CRA's Annex I CVD requirement does not prescribe a specific safe-harbour clause. A manufacturer may choose to include appropriately reviewed language to encourage responsible research, but it should not describe that wording as a mandatory CRA policy element. Legal commitments should match what the organisation is actually authorised and prepared to honour.
- Do not label optional safe-harbour language as a CRA requirement.
- Review legal commitments carefully.
- Keep the policy consistent with actual organisational authority.
- Use clear language for good-faith researchers where appropriate.
Explain How Disclosure Will Be Coordinated
The policy should explain that vulnerability disclosure may be coordinated with investigation and remediation rather than occurring immediately after the initial report. Annex I Part II point 4 separately requires public information about fixed vulnerabilities after a security update has been made available and allows justified delay where publication risk outweighs security benefits until users have had the possibility to apply the patch. The policy can describe this general coordination principle without promising one fixed publication date for every case.
- Coordinate disclosure with remediation.
- Prepare accurate affected-product information.
- Consider user security.
- Avoid inflexible publication promises.
Explain How Third-Party Components Are Handled
A report may identify a vulnerability in an upstream library or component embedded in the manufacturer's product. The policy can explain that the manufacturer may coordinate with the relevant maintainer while separately assessing its own affected products and versions. Researchers should not be required to understand the manufacturer's supplier relationships before reporting. The manufacturer remains responsible for its own product vulnerability-handling process.
- Accept relevant component reports.
- Coordinate with upstream maintainers where appropriate.
- Assess product-specific exposure.
- Protect embargoed technical information.
Keep Article 14 Escalation Internal
The public CVD policy does not need to turn researchers into CRA regulatory-reporting experts. Internally, however, reports should be assessed for Article 14 triggers. If a report establishes or contributes to manufacturer awareness of an actively exploited vulnerability, the statutory reporting workflow may need to begin. The Article 14 process should therefore be connected to CVD intake without forcing the reporter to submit information through the CRA Single Reporting Platform.
- Assess active exploitation internally.
- Capture awareness timing.
- Escalate possible Article 14 cases.
- Keep researcher reporting simple.
Version and Review the Policy
A CVD policy can become stale as products, reporting channels and organisational responsibilities change. The manufacturer should assign ownership, record meaningful policy changes and review the document after changes to product scope, contact mechanisms or vulnerability-handling processes. Broken contact details or obsolete product names can undermine the practical value of an otherwise well-written policy.
- Assign policy ownership.
- Record the current version.
- Review contact information.
- Review product scope.
- Update the policy when the process changes.
Retain Policy Evidence for Annex VII
Annex VII includes the coordinated vulnerability disclosure policy and evidence of the vulnerability-reporting contact among the information and specifications of the manufacturer's vulnerability-handling processes. The technical documentation should therefore retain the applicable policy version, its publication location and evidence that the contact mechanism exists and functions. Case records can further demonstrate that the policy is enforced rather than merely published.
- Applicable CVD policy version.
- Publication location.
- Reporting-contact evidence.
- Policy ownership.
- Operational case records.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.