What coordinated vulnerability disclosure policy does the CRA require from a manufacturer?
A manufacturer with products in scope must put in place and enforce a coordinated vulnerability disclosure policy, provide a contact address for reporting vulnerabilities, and offer a single point of contact that users can easily find. All three must be evidenced in the technical documentation. Article 14 reporting already applies from 11 September 2026, so the intake path has to work now, not when the broader regulation starts to bite. Before that date, confirm who receives reports, how they are triaged, and who can declare an actively exploited vulnerability within the reporting clock.
The organization owns this policy and is accountable for it. An implementation partner can build the operating process around it: the intake form or mailbox, the triage workflow, severity scoring, the internal escalation path to engineering and legal, and the records that show each report was handled. The partner does not decide whether the product conforms or issue any declaration. Only an independent conformity assessment body does that, and only where the chosen route requires one. Ask any partner to deliver the policy text, the runbook, a test report from a dry run of the intake, and a file layout that maps each artifact to the technical documentation.
Confirm three things with your legal and product teams before drafting. First, which components are third-party or open source, because Article 13(6) requires you to report a vulnerability in an integrated component to its maintainer and share any fix you develop. Second, how you will publish fixed vulnerabilities once a security update exists, since Annex I Part II point (4) requires a description, affected product information, impact, severity and remediation guidance. Third, whether the policy will cover every later substantially modified version, which the Commission's guidance treats as required even where older versions are no longer remediated. The Commission's CRA page is the natural starting point for tracking how these obligations are applied.
What a CVD policy and PSIRT intake must contain
The CRA turns vulnerability intake into product evidence: a published policy, a reporting address, a human point of contact, and a workflow that runs for the whole support period. Each card below names one element and the record that proves it exists in the technical documentation.
Published coordinated vulnerability disclosure policy
The manufacturer must put in place and enforce a coordinated vulnerability disclosure policy, and the user information must say where that policy can be found. Publish it on a stable public page, version it, and keep a copy in the technical documentation. The Commission's guidance says the policy must continue for later substantially modified versions, even where remediation of older versions has stopped. Check that the page states scope, safe harbor terms for researchers, and expected response steps.
Public contact address for reports
Annex I requires a contact address for reporting vulnerabilities, and the technical documentation must contain evidence that it was provided. Use a monitored mailbox or form that is linked from the policy, the product's security page and the user documentation. Keep a dated record of the address, its owner and any changes. Test it periodically by sending a report and confirming that someone acknowledges it.
Single point of contact beyond automation
Article 13(17) requires a single point of contact that users can easily identify and that lets them choose their preferred means of communication. It must not depend only on automated tools, so a named role or team must answer by a channel the reporter selects. Record the contact's identity or role, the channels offered, and proof that a human responded to a test report. Confirm with counsel how this role interacts with the PSIRT lead and the CSIRT contact used for Article 14 reporting.
Triage and remediation workflow
Article 13(8) requires policies and procedures to process and remediate potential vulnerabilities from internal and external sources. Define intake, severity assessment, reproduction, fix development, testing and release, with owners at each step. Keep a tracker that links each report to its fix, release and disclosure decision. Evidence is the procedure document, a sample of closed tickets across the support period, and records of the timing each step took.
Public advisory process
Annex I Part II point (4) requires manufacturers, once a security update is available, to share and publicly disclose information about fixed vulnerabilities. Each advisory needs a description, information to identify affected products, the impacts, the severity and clear remediation steps for users. Prepare an advisory template, agree who approves publication, and keep published advisories in a stable location. Evidence is the advisory archive and the matching change records for each fix.
Upstream reporting for open-source components
Article 13(6) requires a manufacturer that finds a vulnerability in an integrated component, including open-source software, to report it to the component's maintainer and share any fix it develops. Maintain the software bill of materials so the team can identify affected components quickly. Record each upstream report, the maintainer's response and the fix shared back. Confirm which upstream projects publish their own disclosure channels, since this shapes the workflow.
How to build the intake and disclosure process in phases
The sequence turns the CRA's vulnerability handling duties into a working intake, triage, reporting and disclosure process, with each phase producing a document or record that later feeds the technical documentation. It is ordered so that scope and policy are settled before contact points, reporting paths and public advisories depend on them.
Scope the products and support periods
Start by listing every product with digital elements, every version still in support, and every component the product integrates, including open-source components. Engineering and product management own the list, and legal or compliance confirms which products are in scope and which support periods apply. The output is a scope register that names each product, its versions, its support end point and its maintainers. The step is done when someone outside the product team can read the register and identify which versions the disclosure policy must cover. Ask any implementation partner to show how the register will be kept current as releases ship.
Draft and approve the CVD policy
Write a coordinated vulnerability disclosure policy that explains how external and internal parties report potential vulnerabilities, how the manufacturer acknowledges and processes them, how it coordinates timing with reporters and how it discloses fixes. Product security drafts the text, and senior management or the accountable product owner approves it under the organization's document control process. The output is an approved, versioned policy with an owner and a review date. The step is done when the policy is published in a stable location and the approval record is stored with the technical documentation. Keep the policy in the same language as the user information it will be referenced from.
Stand up the contact address and single point of contact
Create a dedicated, monitored contact address for vulnerability reports and name a single point of contact that users can find easily. The point of contact must allow users to choose their preferred means of communication and must not depend only on automated tools, so a web form or ticket queue should sit alongside a named human role. Operations assigns the mailbox and staffing cover, and product security owns the role. The output is a documented contact channel, a named role and a test message showing that reports reach the team. The step is done when the address appears in the policy, the user information and the technical documentation evidence.
Define triage and severity handling
Set out how each report is logged, validated, assigned and scored. Define the severity method the team will use, the roles that can accept or reject a finding, the criteria for escalating a report to incident response, and how third-party component findings are routed to their maintainers. Product security runs the process, and engineering leads supply the technical assessment. The output is a triage procedure with a severity method, a case template and an escalation matrix. The step is done when a sample report can be followed from intake to a documented decision without undefined handoffs.
Connect the Article 14 reporting path
Map how an actively exploited vulnerability or severe incident identified through the intake process moves into the Article 14 reporting duty, which has applied since 11 September 2026 through ENISA's Single Reporting Platform. Identify who decides that a report is notifiable, who holds access to the platform, which CSIRT is designated as coordinator for the organization, and how the internal decision is recorded. The output is a reporting runbook linked to the triage procedure and a record of platform access. The step is done when the team can show how a finding moves from triage to a notification decision with timestamps and named approvers. Confirm the designated CSIRT and platform access with the relevant national authority rather than assuming them.
Set up advisory publication and upstream reporting
Define how fixed vulnerabilities are publicly disclosed once a security update is available. Advisories must describe the vulnerability, identify affected products, state the impacts and severity, and give clear remediation information for users. Where a vulnerability sits in an integrated component, including open-source software, the team must also report it to the maintainer of that component and share any fix it develops. Product security drafts advisory templates and the upstream reporting steps, and communications signs off on publication. The output is an advisory template, a publication checklist and a log of upstream reports. The step is done when a test advisory is drafted against a sample fix and the upstream reporting step is recorded.
Assemble the technical documentation evidence
Collect the records that show the process exists and works. The technical documentation needs the disclosure policy, evidence that a vulnerability contact address has been provided, and the material supporting the vulnerability handling requirements. Compliance or the product security lead assembles the file, indexes each record to the requirement it supports, and sets a review cadence for keeping it current. The output is an indexed evidence pack that an assessor or market surveillance authority can navigate without interviews. The step is done when every record has an owner, a version and a link to the requirement it evidences. Ask the assessor which evidence format they expect before the pack is finalized.
Test the workflow with a tabletop exercise
Run a tabletop exercise on a realistic but invented scenario, such as an illustrative vulnerability reported through the public contact address in a bundled open-source library. The exercise walks through intake, triage, escalation, the reporting decision, upstream notification, advisory drafting and publication. Product security facilitates, and participants from engineering, operations, legal and communications play their normal roles. The output is an after-action report listing gaps, owners and corrections to the policy, runbook or templates. The step is done when the corrections are closed and the exercise record is added to the evidence pack. Repeat the exercise after material process changes so the record stays accurate.
Who owns the policy, who builds the process and who assesses it
The manufacturer owns the coordinated vulnerability disclosure policy, the reporting process and every obligation under the regulation. Annex I Part II point (5) requires the manufacturer to put in place and enforce the policy, so accountability cannot be delegated to a vendor or consultant. Inside the organization, a small set of roles usually shares this work, and the exact split depends on company size and product line.
- Policy ownership: A named executive or product owner approves the disclosure policy, sets its scope and reviews it when products or support periods change.
- Product security lead: This person runs triage, severity assessment and coordination with engineering, and decides when a fix is ready for public disclosure.
- Support and engineering staff: Support staff route reports to the security lead, while engineers develop and test fixes and keep the affected-product records current.
- Legal sign-off: Legal reviews the public advisory wording, the user communications and any reporting to authorities before release.
Before relying on any of these roles, confirm in writing who is the single point of contact for reporters and who can authorize an emergency release.
An implementation partner such as DeployOpen can help the manufacturer prepare the systems and evidence that the process needs. The partner works within a written scope, and the manufacturer keeps ownership of the policy and every decision made under it. A partner does not issue reports, attestations or certificates, and it does not become responsible for the manufacturer's declaration.
- Drafting support: The partner can help draft the disclosure policy and the public advisory template, based on the manufacturer's decisions about scope and timelines.
- Intake tooling setup: The partner can configure a contact address, a reporting form and ticketing workflows, and connect them to the manufacturer's existing tools.
- Workflow configuration: The partner can set up triage states, severity fields and escalation paths so that the process leaves a traceable record.
- Evidence packaging: The partner can collect the policy, contact records, test results and process logs that the technical documentation will reference.
- Testing support: The partner can exercise the intake channel and workflow with test reports before the process is relied upon.
Ask any partner to state in its scope document which deliverables it prepares and which decisions remain with the manufacturer.
An independent assessor or notified body checks conformity where the regulation requires third-party involvement. Most products follow self-assessment under module A, in which case the manufacturer's own review and documentation carry the conformity claim. Where a notified body is needed, it examines the evidence and issues the certificate for its part of the assessment, while the manufacturer still signs the EU declaration of conformity.
- Route depends on the product: Whether a notified body is needed follows from the product's classification and the harmonized standards applied, so confirm the route before planning the evidence.
- Evidence review: The assessor reviews the policy, contact address evidence and records in the technical documentation, and may sample reports and fixes.
- Independence: The assessor must be independent of the manufacturer and of any partner that prepared the evidence.
- Certificate scope: A certificate covers only what the assessor examined, so confirm its scope against the product version and support period.
- Declaration remains with the manufacturer: The manufacturer decides whether the product conforms and signs the declaration, whatever the assessor or partner has produced.
Before engaging an assessor, ask which conformity module applies and what evidence it will request.
What evidence goes into the technical documentation
Annex VII point 2(b) requires the technical documentation to contain two things for vulnerability handling: the coordinated vulnerability disclosure policy itself, and evidence that a contact address for reporting vulnerabilities has been provided. An assessor will not accept a policy that exists only as a document on a shelf. They will look for proof that the policy was approved, published and used. Start by assembling a versioned file for the policy with its change history, the named approver for each version, the date of each approval and the record of who was consulted. Keep the superseded versions too, because the Commission guidance expects the disclosure policy to remain in force for later substantially modified versions of a product, and an assessor may ask which version was in force when a given report arrived.
The contact address needs its own evidence pack. Capture a dated screenshot or saved copy of the published page that carries the address and the link to the policy, and record the mailbox or form in the documentation. Then test it. Send a test report from outside the organization, confirm an acknowledgment is returned, and keep the test result with the timestamp and the person who ran it. Keep an intake log that records each report, its handling and its closure, with sample entries redacted where needed. Show at least one worked example from start to finish, including triage, severity assessment, remediation and the decision on whether a public advisory was needed. Where the organization has received upstream reports for open-source components under Article 13(6), include the records of those reports and any fixes shared back. Confirm with the Commission FAQ and your market surveillance authority which format and level of detail they expect, since the documentation requirements are applied through national practice.
What usually delays a CVD and PSIRT project
Most CVD and PSIRT projects stall on ownership and proof rather than on writing the policy itself. The cards below cover the gaps that most often surface when an assessor or market surveillance authority asks how the process actually runs, and the check that closes each gap.
No single point of contact
A web form that routes to a shared inbox does not meet the requirement for a single point of contact that users can easily identify and that is not limited to automated tools. Name a person or role, publish the channel, and confirm that a human answers the preferred means of communication. Test it by submitting a report through each published channel and recording who replied and when.
Policy written but never enforced
A coordinated vulnerability disclosure policy that sits on a website but has no matching intake log, triage record or remediation ticket will not survive scrutiny. Annex I requires the manufacturer to put in place and enforce the policy, so enforcement must leave traces. Walk one past report from intake to fix and confirm each step matches what the policy promises.
No owner for upstream reporting
When a vulnerability sits in an open-source or third-party component, Article 13(6) requires the manufacturer to report it to the maintainer and share any fix it develops. Teams often assume someone else will do this. Assign a named owner for upstream reports, define how fixes flow back, and keep a log showing each report sent and each fix shared.
Advisories missing severity or fixes
Annex I Part II point (4) asks for public disclosure of fixed vulnerabilities with a description, identification of affected products, impacts, severity and clear remediation information for users. Advisories that name a patch but omit severity or upgrade steps are a common gap. Use a fixed advisory template with those fields as required blanks, and review sample advisories against it before release.
Support periods not mapped to policy
The disclosure policy must cover every substantially modified version still in use, even where remediation of older versions has ended. Commission guidance C(2026) 5252 makes this point explicitly. Build a table that lists each supported version against its support end date and the policy coverage, and keep it current whenever a release ships or support ends.
Evidence collected after the fact
Technical documentation must contain evidence that a vulnerability contact address has been provided, along with the policy itself. Teams that rebuild this evidence at audit time often find screenshots missing or dates unverifiable. Capture the published policy, the contact channel test results and the advisory archive on a schedule, and store them with the technical documentation under version control.
Common questions about CRA vulnerability disclosure
Is a coordinated vulnerability disclosure policy enough on its own under the CRA?
No. A coordinated vulnerability disclosure policy is one required piece, but it does not stand alone. Annex I Part II point (5) requires manufacturers to put in place and enforce the policy, Article 13(8) requires the surrounding policies and procedures to process and remediate reported vulnerabilities, and Annex I Part II point (6) requires a contact address for reporting. The policy also has to be enforced in practice, so intake, triage, fixes, updates and public advisories all need working procedures and records behind them. Ask an implementation partner to map each of these duties to a named process and an owner before writing the policy.
Does the CRA require a bug bounty programme?
The CRA text reviewed for this page does not require a bug bounty. What it requires is a coordinated vulnerability disclosure policy, a contact address, a single point of contact that users can easily identify, and a process to remediate reported issues. A bounty is a business choice that some manufacturers add on top. Confirm this against the current Article 13 and Annex I text on EUR-Lex and with your market surveillance authority before you rely on it, because interpretation guidance can change.
What work does a CVD programme need from our internal staff?
Internal staff own the decisions that an outside party cannot make for you. Product owners decide severity, affected versions and whether a fix ships. Engineers build and test patches. Legal and communications approve the public advisory and user notices. Someone must also staff the single point of contact so that users reach a person, not only an automated form. Expect these roles to recur for the full support period, not just during the first setup. A partner can design the workflow and write the templates, but your staff remain accountable for the responses.
Can a small team run a CVD process without outside help?
Often yes, if the product is small and the team can staff intake and remediation. The minimum is a published policy, a monitored contact address, a named single point of contact, a triage routine, a way to ship and document fixes, and a public advisory template. Small teams usually struggle with evidence rather than the process itself, since the technical documentation must show the policy and contact address exist and were used. Microenterprises and SMEs should also check the relief the regulation provides for their size before they design a heavier process.
How does the vulnerability disclosure process connect to Article 14 reporting?
Intake is the starting point for reporting. When a report, scanner finding or upstream notice indicates an actively exploited vulnerability, the triage team must decide quickly whether it falls under the Article 14 duty to notify. Article 14 reporting applies from 11 September 2026 and runs through ENISA's Single Reporting Platform, so your intake log, severity assessment and escalation path should record timestamps and decisions that support a 24-hour early warning. Public advisories under Annex I Part II point (4) follow once a fix is available. Keep the two tracks separate in your runbook, but make sure they share the same case record.
How does cost depend on product count, support period and third-party components?
Cost is driven mainly by staff time, and it recurs. The main drivers are the number of products and versions in scope, the length of the support period that the policy must cover, and the number of third-party and open-source components you must monitor and report upstream under Article 13(6). Each additional product line multiplies intake, triage and advisory work. Ask any partner for a written quote that lists products, versions, components, support period, tooling and the staff roles it assumes. The regulation itself does not publish a cost figure for CVD programmes, so treat any number you see without a stated source with caution.
How to choose an implementation partner for vulnerability handling
Before you sign, ask a prospective partner to show concrete experience with product security processes, not only with penetration testing or general IT operations. Ask who on their team has built or run a vulnerability intake process, how they would stand up a coordinated vulnerability disclosure policy, a published contact address and a single point of contact for a product you ship, and how they have handled a vulnerability report that arrived through a channel the vendor did not expect. Ask for examples they can describe in general terms, and ask how the work was evidenced for an outside reviewer. A partner that can only talk about tools has not yet shown you the process.
Separate the roles in writing. The manufacturer owns the policy, the decisions on disclosure and the obligations under Article 13 and Annex I Part II. The partner prepares the process, the records and the technical documentation. Only an independent assessor, a notified body where one is required, or a market surveillance authority can judge conformity, and no implementation partner can certify conformity or issue a report that says a product complies. Be wary of any proposal that describes a partner's output as a certificate, a declaration or an assurance of compliance. Ask the partner to confirm in the statement of work that it does not issue those documents.
Insist that scope, deliverables and handover are fixed in writing before work starts. The agreement should list the policy document, the intake channel, the triage workflow, the advisory template, the evidence pack for the technical documentation and the named owner of each item after handover. Ask who holds the administrative access to the intake mailbox, the web form and any tracking system, and who keeps the records of each report. Ask how the partner handles open-source components in the product: who reports a flaw to the upstream maintainer under Article 13(6), who shares any fix, and who decides on public disclosure. Confirm these answers with your own legal and product security leads, because the commitments you make to the public and to users depend on them.
How DeployOpen builds the CVD intake and prepares its evidence
DeployOpen plans, implements and documents the vulnerability intake and disclosure process inside your own infrastructure, using self-hosted open-source platforms where they fit your product. We prepare the systems, policies and evidence that the CRA asks manufacturers to hold, while your organization keeps ownership of its controls and an independent assessor or notified body makes any formal determination.
How we scope
- Each engagement starts with a written scope that names the products, versions and support periods covered by the CVD policy and PSIRT process.
- The scope lists the intake channels to build, such as a published contact address, a single point of contact and the internal ticketing tool that receives reports.
- Engagements are fixed-scope, so deliverables, responsibilities and timelines are agreed in writing before any work begins.
How we build
- We draft a coordinated vulnerability disclosure policy with your legal and product teams, covering intake, triage, remediation, coordination and public advisories.
- We configure the intake address, the vulnerability tracker and the triage workflow on infrastructure you control, then test the path from report to fix end to end.
- We set up the upstream reporting steps for open-source components so that issues in third-party code reach their maintainers and any fixes are shared.
How we hand over
- We assemble the evidence the technical documentation needs, including the policy, the published contact address and records from test reports.
- We provide runbooks for triage, advisory drafting and user notification, so your staff can run the process after handover without outside help.
- We document where the policy is published so the user information can point customers to it, and we confirm each item with you before closing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, which keep the intake channel and advisory process current as products change.
- Retainers can cover maintaining the PSIRT tooling and reviewing reports during the support period that your products must receive.
- Ask us to confirm how the process will interact with the ENISA Single Reporting Platform and your designated CSIRT before the reporting obligation applies to you.
Sources and further reading
- Regulation (EU) 2024/2847, Annex I (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Article 13 (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Annex VII (EUR-Lex) ↗
- Commission guidance on the application of Regulation (EU) 2024/2847, Annex to C(2026) 5252 ↗
- ENISA Single Reporting Platform: Frequently Asked Questions ↗
- Commission FAQs on the Cyber Resilience Act, version 1.4 ↗
