How to Create a Vulnerability Disclosure Policy for CRA Compliance

The EU Cyber Resilience Act requires manufacturers to establish processes for handling vulnerability reports from external sources — security researchers, customers, and other stakeholders. A vulnerability disclosure policy (VDP) is how you formalize that process.

If you do not have one, you are not just missing a CRA requirement — you are missing vulnerability reports that could prevent the next security incident. This guide shows you how to create a policy that satisfies the CRA and actually works in practice.

Why the CRA Requires a Vulnerability Disclosure Policy

Annex I, Section 2 of Regulation 2024/2847 requires manufacturers to address and remediate vulnerabilities without delay, including those reported by third parties. Article 13 further requires that manufacturers provide a contact address for vulnerability reporting and publish a policy for coordinated vulnerability disclosure.

Without a published policy, security researchers have no clear way to report issues to you. Many will default to public disclosure — which means your customers learn about vulnerabilities at the same time as attackers.

The Foundation: ISO 29147

The international standard for vulnerability disclosure is ISO/IEC 29147:2018. While the CRA does not mandate ISO 29147 specifically, aligning with it gives your policy credibility and ensures you cover all necessary elements. The standard defines three disclosure models:

• Coordinated disclosure: the reporter and vendor agree on a timeline for public disclosure. The vendor has a defined window to develop and release a fix before the vulnerability is made public. This is the model the CRA expects.
• Full disclosure: immediate public disclosure without coordinating with the vendor. The CRA does not support this model — it requires coordination.
• Non-disclosure: the vulnerability is never made public. The CRA requires public disclosure of fixed vulnerabilities, so pure non-disclosure is not an option either.

Coordinated disclosure with a defined timeline (typically 90 days) is the standard practice and aligns with CRA expectations.

Creating Your SECURITY.md File

The most widely recognized way to publish your vulnerability disclosure policy is through a SECURITY.md file in your code repository. GitHub, GitLab, and Bitbucket all recognize this file and surface it to users. Here is what to include:

Contact Information

Provide a clear, monitored channel for vulnerability reports. Options include:

• A dedicated email address (e.g., security@yourcompany.com)
• A web form on your security page
• GitHub Security Advisories (if your project is on GitHub)
• A dedicated bug bounty platform (HackerOne, Bugcrowd)

Do not use a generic support email. Security reports need to reach security-aware staff, not a general support queue.

Scope

Define which products and versions are covered by your disclosure policy. Be explicit about what is in scope and what is not. If your organization has multiple products, specify which ones are covered and how to report for each.

Response Timeline

Commit to specific timelines. The CRA does not prescribe exact response times for external reports (as opposed to the 24-hour ENISA reporting for actively exploited vulnerabilities), but industry standards suggest:

• Acknowledgment: within 48 hours of receiving the report
• Initial assessment: within 5 business days
• Status update to reporter: at least every 14 days
• Fix development: within 90 days for most vulnerabilities (shorter for critical severity)
• Public disclosure: coordinated with the reporter after the fix is released

Safe Harbor

Include a safe harbor statement assuring good-faith security researchers that you will not take legal action against them for responsibly reporting vulnerabilities. Without this, many researchers will not report to you at all. A simple safe harbor states that you will not pursue legal action against individuals who report vulnerabilities in good faith and follow your disclosure policy.

What Reporters Should Include

Guide reporters on what information helps you triage effectively:

• Affected product and version
• Description of the vulnerability and its potential impact
• Steps to reproduce
• Any proof-of-concept code (shared securely, not publicly)
• Their preferred communication channel for follow-up

Connecting Your VDP to CRA Processes

Your vulnerability disclosure policy is one piece of a larger CRA compliance framework. It connects to:

• ENISA reporting: if an externally reported vulnerability turns out to be actively exploited, it triggers the 24-hour ENISA reporting obligation
• SBOM management: reported vulnerabilities in third-party components should trigger an update to your SBOM and vulnerability monitoring pipeline
• Technical documentation: your VDP and vulnerability handling process must be documented as part of your CRA technical documentation package
• CE marking: the conformity assessment verifies that vulnerability handling processes, including external disclosure, are in place

Template: SECURITY.md for CRA Compliance

Here is a practical template structure for your SECURITY.md file:

Section 1: Reporting a Vulnerability. State your security contact (email or form URL). Explain that you practice coordinated disclosure and ask reporters not to disclose publicly until a fix is available.

Section 2: Scope. List the products, repositories, and version ranges covered by the policy.

Section 3: Response Process. Describe your commitment to acknowledgment within 48 hours, triage within 5 business days, and regular status updates.

Section 4: Disclosure Timeline. State your standard disclosure window (typically 90 days) and the conditions under which it may be shortened (active exploitation) or extended (complex fixes).

Section 5: Safe Harbor. Commit to not pursuing legal action against good-faith reporters who follow your policy.

Section 6: Recognition. Explain whether and how you credit reporters (security advisories, hall of fame, bug bounty payments).

Maintaining Your Policy

A vulnerability disclosure policy is not a static document. Review and update it at least annually, and whenever:

• You add new products to your portfolio
• Your security team structure changes
• Your response timelines prove unrealistic (adjust them rather than missing them)
• Regulatory guidance on CRA disclosure requirements is updated

Track metrics: how many reports you receive, your average response time, and how many reports led to fixes. These demonstrate to market surveillance authorities that your process works.

For a complete CRA preparation plan, see our CRA compliance checklist. To assess your project's current vulnerability handling posture, run cra-scanner.

Complaro helps teams manage the full vulnerability lifecycle — from intake through CRA-compliant disclosure to ENISA reporting. Get started free.