Coordinated Vulnerability Disclosure

Coordinated Vulnerability Disclosure (CVD) is the process that lets researchers, customers, users, and partners report potential vulnerabilities to a manufacturer so the issue can be triaged, remediated, communicated, and evidenced.

For connected-product teams, CVD is not just a public email address. It is an operating workflow: intake, acknowledgement, validation, severity assessment, affected-product analysis, remediation, reporting, customer communication, disclosure, and retained evidence.

Use this page to design a proportionate vulnerability disclosure process and connect it to CRA reporting, secure updates, patch cadence, security logging, and the Secure-by-Design Evidence Pack.

This page is product-security and process guidance. It is not legal advice.

Use This Page When

Use this page when you need to:

• publish or update a public vulnerability disclosure policy;
• create a security.txt contact route;
• define internal triage, escalation, and remediation ownership;
• prepare for CRA reporting obligations for actively exploited vulnerabilities;
• decide what vulnerability records, communications, and evidence to retain;
• connect vulnerability handling to patch cadence, OTA updates, security advisories, and customer support.

What Good Looks Like

A connected-product vulnerability handling process should be able to show:

• a public reporting channel that is easy to find and monitored;
• a clear vulnerability disclosure policy with scope, safe-harbor language, and response expectations;
• an internal triage workflow with named owners;
• a vulnerability log or case system recording reports, status, severity, affected products, decisions, and closure;
• a process for identifying actively exploited vulnerabilities and severe incidents;
• a reporting runbook for CRA Article 14 timelines where applicable;
• a remediation path through patch cadence, OTA updates, configuration changes, mitigation, recall, replacement, or customer guidance;
• customer communication records where users, operators, distributors, or authorities need to know or act;
• retained evidence showing what was reported, how it was assessed, what was fixed, and what remains unresolved.

Regulatory Context

The Cyber Resilience Act (CRA) makes vulnerability handling a manufacturer responsibility.

CRA Annex I, Part II requires manufacturers to put in place and enforce a policy on coordinated vulnerability disclosure (CRA Annex I, Part II § 5). BSI TR-03183-1 provides practical detail by requiring a public document that defines a reporting process and contact channels (REQ_VH 5).

From 11 September 2026, CRA Article 14 also requires manufacturers to report certain actively exploited vulnerabilities and severe incidents. This makes a practised internal triage and escalation process essential.

For boot managers, the draft ETSI EN 304 623 reinforces that low-level firmware needs the same vulnerability-handling discipline as application software: component tracking, remediation paths, update evidence, and support-period records.

Do I Need A CVD Process?

Yes. Every manufacturer of a product with digital elements should have a public route for vulnerability reports and an internal process for handling them.

The process can be proportionate. A small manufacturer with one low-risk product may not need a bug bounty platform or a large security operations team. But it still needs a monitored contact route, a public policy, a triage owner, and records showing what happened after a report arrived.

The question is not whether to have CVD. The question is how formal the process needs to be for the product risk, company size, support model, and customer commitments.

Public Disclosure Route

Your public route should be easy to find and stable over time.

At minimum, provide:

• a public security contact, such as security@example.com;
• a vulnerability disclosure policy page;
• a /.well-known/security.txt file that points to the policy and contact route;
• product or service scope;
• safe-harbor or authorisation language, reviewed by legal counsel;
• what information a reporter should include;
• what response timeline the reporter can expect;
• what behaviour is out of scope, such as denial-of-service testing or access to third-party data.

Use the Secure-by-Design Policy Starter Kit for starter CVD and security.txt templates.

Internal Triage Workflow

Once a report arrives, the public policy must connect to an internal workflow.

Step	Action	Evidence to retain
Intake	Acknowledge the report and create a case record.	Report timestamp, reporter contact, affected product, intake owner.
Triage	Decide whether the report is valid, in scope, reproducible, and security-relevant.	Triage notes, reproduction evidence, in-scope/out-of-scope decision.
Severity and impact	Rate severity and determine affected products, versions, configurations, and support status.	Severity rationale, affected-version analysis, product scope, assumptions.
Exploitation check	Decide whether the vulnerability is actively exploited or part of a severe incident.	Exploitation signals, logs, threat intelligence, escalation decision.
Remediation	Decide the fix, mitigation, update, configuration change, recall, or replacement path.	Engineering owner, remediation plan, release target, risk acceptance if any.
Reporting	Submit required notifications where legal or contractual obligations apply.	CRA/authority reporting record, timestamps, submitted content.
Customer communication	Publish advisory, release notes, mitigation guidance, or direct notice where needed.	Advisory URL, customer notice, release notes, support script.
Closure	Confirm fix or mitigation, update status, credit reporter where appropriate, and retain evidence.	Closure note, final status, CVE/advisory reference, reporter coordination record.

Vulnerability Log

A vulnerability log is the operational record that ties reports to decisions, updates, communication, and evidence.

At minimum, record:

• report ID and date received;
• reporter or source;
• affected product, model, firmware/software version, service, or component;
• vulnerability description and reproduction status;
• severity and impact rationale;
• exploit status and incident escalation decision;
• affected/not-affected analysis;
• owner and current status;
• remediation, mitigation, or risk-acceptance decision;
• update, advisory, CVE, VEX, or customer communication references;
• evidence location and closure date.

The log does not need to be public. It should be retained in a controlled system and linked into the Secure-by-Design Evidence Pack where relevant.

CRA Article 14 Reporting

From 11 September 2026, manufacturers must notify the EU reporting infrastructure of certain actively exploited vulnerabilities and severe incidents under CRA Article 14.

At a practical level, your process should be able to identify and escalate:

• whether a vulnerability affects a product with digital elements in scope;
• whether it is actively exploited;
• whether a severe incident affects product security;
• who can approve and submit the notification;
• what information is available within the required timeframe;
• what follow-up information must be provided after mitigation or remediation.

Retain timestamps and decision records. The most important operational issue is speed: a team cannot meet a short reporting deadline if reports sit untriaged in a generic inbox.

Customer Communication

Not every report needs a public advisory, but many vulnerability decisions need some form of communication.

Possible communication paths include:

• private response to the reporter;
• release notes for a security update;
• security advisory or CVE publication;
• direct customer or distributor notification;
• mitigation guidance for products that cannot be updated immediately;
• support-period or end-of-life clarification;
• regulator or CSIRT follow-up.

Customer communication should be coordinated with patch cadence and update readiness. If users need to install an update, change configuration, avoid a feature, or understand support status, the communication should say so clearly.

Evidence To Retain

Transfer vulnerability-handling evidence into the Secure-by-Design Evidence Pack. Useful evidence includes:

Evidence	Why it matters
Public CVD policy	Shows the reporting route and expectations.
security.txt record	Shows the machine-readable security contact and policy location.
Vulnerability log	Shows reports, owners, status, decisions, and closure.
Triage and reproduction notes	Shows how the report was assessed.
Affected-product analysis	Shows which products, versions, services, or configurations are affected.
Severity and exploitability rationale	Shows why the response path was chosen.
CRA/authority reporting records	Shows notifications, timestamps, and follow-up.
Remediation plan and release record	Shows how the issue was fixed or mitigated.
Update, patch, or configuration evidence	Shows the corrective action was tested and released.
Customer communication	Shows users, distributors, or operators were informed where needed.
Risk acceptance or exception record	Shows unresolved issues, rationale, owner, and review date.

Common Gaps

Common vulnerability disclosure gaps include:

• publishing security@example.com but not monitoring it;
• having a public policy but no internal triage owner;
• failing to record affected/not-affected product decisions;
• treating a vulnerability report as a support ticket without security severity or exploitability review;
• missing CRA Article 14 escalation criteria;
• fixing the issue but not retaining release, update, or communication evidence;
• publishing a patch without customer guidance or advisory context where users need to act;
• not connecting vulnerability handling to OTA updates, patch cadence, SBOM/VEX, or security logging;
• losing reporter coordination records after closure.

Tooling Options

Email can work for a small team if it is monitored and backed by a disciplined workflow. As report volume, product risk, or customer obligations grow, dedicated systems can help with intake, triage, communication, and audit trail.

Possible tooling categories include:

• vulnerability disclosure platforms such as HackerOne;
• ticketing or case-management systems;
• security advisory publishing workflows;
• CVE and VEX tooling;
• vulnerability intelligence and monitoring tools;
• logging, SIEM, or incident-response tooling for exploitation analysis.

For product and tooling categories, see Vulnerability & Threat Intelligence and Security Logging & Monitoring.

Vulnerability Disclosure Checklist

Before release, confirm that:

• Public CVD policy: A clear public policy exists and is linked from an appropriate location.
• security.txt: A current /.well-known/security.txt file points to the contact route and policy.
• Monitored reporting channel: Reports reach a team or owner who can act.
• Internal triage workflow: Intake, validation, severity, affected-product analysis, remediation, communication, and closure are defined.
• Vulnerability log: Reports, owners, decisions, status, evidence, and closure are recorded.
• CRA reporting path: Actively exploited vulnerabilities and severe incidents can be identified and escalated quickly.
• Customer communication path: Advisories, release notes, mitigation guidance, or direct notifications can be issued where needed.
• Remediation path: Vulnerability decisions connect to patch cadence, OTA updates, configuration changes, mitigation, recall, or replacement.
• Evidence retention: Policies, reports, triage records, update records, communications, and open gaps are retained.

Related Pages

If you need to:

• draft CVD, security.txt, patch, or internal handling policies, use the Secure-by-Design Policy Starter Kit;
• plan remediation timing, support periods, and rollback expectations, use Patch Cadence & Rollback Strategy;
• deliver and evidence fixes, use Secure OTA Updates;
• record security-relevant events and exploitation signals, use Security Logging & Monitoring;
• assess readiness and gaps, use the CRA Readiness Gap Analysis;
• retain vulnerability-handling evidence, use the Secure-by-Design Evidence Pack;
• choose supporting tools, use Vulnerability & Threat Intelligence.