Vulnerability Disclosure Under CRA Article 15
Article 15 of the CRA requires manufacturers to establish and maintain a policy for coordinated vulnerability disclosure (CVD). This guide explains the requirements and how to build a programme that satisfies them.
What Article 15 Requires
Article 15 of the CRA sets out vulnerability handling obligations for manufacturers. In summary, manufacturers must:
Establish and document a coordinated vulnerability disclosure policy (CVD policy)
Make contact details publicly accessible for reporting vulnerabilities — this can be a dedicated email address (security@...), a web form, or a security.txt file
Acknowledge reported vulnerabilities without undue delay
Investigate vulnerabilities with due diligence and, where needed, develop a corrective update
Take appropriate measures to mitigate the vulnerability without undue delay after becoming aware
Publicly disclose information about vulnerabilities along with relevant mitigations (CVE identifiers, CSAF advisories)
Not prevent third parties from disclosing vulnerabilities in their products (no gag clauses in contracts or policies)
Notify ENISA of actively exploited vulnerabilities under Article 14
Writing a CVD Policy
Your CVD policy should be a concise, publicly accessible document. It does not need to be a lengthy legal document — clarity and accessibility are more important. The policy should cover:
Scope
Which products or services the policy covers. If you have a narrow product range, list them explicitly.
How to report
A dedicated email (security@yourdomain.com), web form, or PGP-encrypted contact. Make it easy — friction reduces reports.
What to include in a report
Product name and version, description of the vulnerability, steps to reproduce, impact assessment, and proof-of-concept if available.
Acknowledgement timeline
Commit to acknowledging reports within a specified period — 5 business days is ISO 29147's recommendation.
Disclosure timeline
Your default coordinated disclosure window (90 days is standard). State that extensions are available by mutual agreement.
Safe harbour commitment
A statement that good-faith security researchers who follow the policy will not face legal action. This is critical for attracting reports.
Exclusions
What is out of scope — e.g., physical attacks, social engineering, DoS, already-known issues. Be specific.
Credit
Whether you will acknowledge researchers who report valid vulnerabilities in your security advisories or a Hall of Fame.
Tip: Add a /.well-known/security.txt file to your website. This machine-readable file (RFC 9116) tells researchers where to report vulnerabilities and is increasingly checked by automated scanning tools and bug bounty platforms.
The CVD Process: Step by Step
Receive and acknowledge
Acknowledge receipt of the vulnerability report within 5 business days (ISO 29147 recommendation). Do not disclose details to third parties without the researcher's consent.
Validate the report
Reproduce the issue in a controlled environment. Assign a severity rating (CVSS) and determine scope — which product versions and configurations are affected?
Develop a fix
Prioritise based on severity and exploitability. For critical vulnerabilities, target a fix within 7–14 days. For high severity, within 30 days. Track progress and keep the reporter informed with status updates.
Assign a CVE identifier
Request a CVE identifier from a CVE Numbering Authority (CNA). You can become your own CNA (recommended for larger manufacturers) or request via MITRE or national CSIRTs. CVE identifiers are required by the CRA for publicly disclosed vulnerabilities.
Coordinate disclosure date
Agree a public disclosure date with the reporter — typically 90 days from initial report, though this can be extended by mutual agreement. ENISA and national CSIRTs can assist if parties cannot agree on timing.
Publish advisory and CSAF document
Release a security advisory describing the vulnerability, affected versions, CVE identifier, severity, mitigations, and the security update version. Publish a CSAF (Common Security Advisory Framework) document in machine-readable JSON format alongside the human-readable advisory.
Notify users
Inform all customers and users of the affected product, directing them to apply the security update. Where automatic updates are available, ensure they are deployed promptly. Report to ENISA via Article 14 if the vulnerability is being actively exploited.
CSAF: Machine-Readable Security Advisories
The Common Security Advisory Framework (CSAF) is an OASIS standard for publishing security advisories in machine-readable JSON format. CSAF documents can be consumed by software composition analysis tools, SBOMs, and vulnerability management platforms automatically — significantly reducing the time it takes for customers to learn they are affected and need to patch.
CSAF documents should be published at a well-known URL path (/.well-known/csaf/) and listed in a CSAF provider-metadata.json file so that automated tools can discover them.
VEX: Vulnerability Exploitability eXchange
VEX is a companion to SBOM that allows manufacturers to state whether a specific vulnerability in a component actually affects their product (or not, and why). VEX dramatically reduces false positives in downstream vulnerability scanning. CycloneDX supports VEX natively; CSAF VEX is a separate CSAF profile. Producing VEX statements for your products is considered best practice under the CRA.
Article 15 CVD vs Article 14 Incident Reporting: What Is the Difference?
Article 15 (CVD)
- Triggered by any reported or discovered vulnerability
- Process is researcher/manufacturer coordinated
- No fixed notification deadline to ENISA
- Output: security advisory, CVE, patch
Article 14 (Incident Reporting)
- Triggered only when a vulnerability is actively exploited
- Mandatory notification to ENISA and national CSIRT
- Strict 24h / 72h / final report timeline
- Output: ENISA notification, EUVD entry
CRAReady's Vulnerability Disclosure Portal gives each product a public-facing disclosure page — no researcher account required. Submissions auto-create Article 14 incidents for your triage team.
Need help implementing this? Try CRAReady →