A Cyber Resilience Act (CRA) coordinated vulnerability disclosure (CVD) policy is the manufacturer-facing rule set for receiving vulnerability reports, coordinating investigation and remediation, communicating with reporters, and controlling when detailed information becomes public. Under Regulation (EU) 2024/2847, manufacturers must put such a policy in place and enforce it; they must also make vulnerability reporting practical by providing a contact address and a user-facing single point of contact where the policy can be found.
For product teams, the useful question is not only “do we have a disclosure page?” but “can a real external report move from intake to an evidence-backed remediation and publication decision without disappearing between email, engineering, legal and release management?”
What the CRA actually requires
The legal baseline is spread across several connected provisions.
Article 13 requires manufacturers to have appropriate policies and procedures, including coordinated vulnerability disclosure policies, to process and remediate potential vulnerabilities reported from internal or external sources. Annex I Part II then requires manufacturers to:
- put in place and enforce a coordinated vulnerability disclosure policy;
- facilitate the sharing of information about potential vulnerabilities in the product and in third-party components, including by providing a contact address for vulnerability reports;
- address and remediate vulnerabilities without delay in relation to the risks posed to the product; and
- after a security update is available, share and publicly disclose information about fixed vulnerabilities, while allowing delayed publication in duly justified cases where publication risk outweighs the security benefit.
Annex II adds a user-facing requirement: the product information must identify a single point of contact where vulnerability information can be reported and received and where the manufacturer's CVD policy can be found.
Recital 76 explains the intended operating model. The policy should define a structured process that lets vulnerabilities be reported in a way that allows the manufacturer to diagnose and remedy them before detailed information is disclosed to third parties or to the public.
That makes CVD a lifecycle process, not a mailbox and not a public-relations document.
Define what the policy covers
A useful policy starts with scope that a reporter can understand without guessing.
State which products, services, domains, repositories, interfaces or supported versions are in scope. If some systems are excluded because they belong to another legal entity, supplier or hosting provider, explain where reports should go instead.
For a manufacturer with several product families, the public policy can remain concise while the internal routing logic maps reports to the correct product, release and owner. The external reporter should not need to know the internal organisation chart.
The policy should also explain what types of findings are appropriate to report. Examples may include authentication weaknesses, privilege escalation, remote code execution, insecure update mechanisms, exposed credentials, cryptographic weaknesses, unsafe default configurations or vulnerabilities in bundled third-party components.
Avoid turning the scope section into an exhaustive catalogue. A valid finding should not be rejected merely because the exact vulnerability class was not listed.
Provide one reporting path that is actually monitored
The CRA requires manufacturers to facilitate vulnerability reporting, including by providing a contact address. Annex II requires a single point of contact for receiving vulnerability information and locating the CVD policy.
Operationally, that means the contact must be more than a published address. It needs ownership, monitoring and continuity.
A practical intake design should define:
- the reporting address or secure submission mechanism;
- who monitors it and during which operational coverage;
- how absence, holidays and staff changes are handled;
- how reports are transferred into the controlled vulnerability workflow;
- how sensitive attachments are handled;
- what minimum information is useful for triage; and
- how the reporter receives acknowledgement.
A report form may ask for the affected product and version, reproduction steps, observed impact, proof-of-concept material, environment details and reporter contact information. These fields should help investigation rather than become reasons to discard incomplete reports.
Preserve the original report. Later summaries and engineering tickets should reference it rather than silently replacing what the reporter actually submitted.
Acknowledge reports before you know the answer
A first response does not need to decide whether the vulnerability is valid. It should confirm receipt, provide a tracking reference where appropriate, explain the next step and set a realistic communication expectation.
This matters because CVD depends on coordination. Silence encourages duplicate submissions, escalation through public channels and uncertainty about whether the manufacturer is investigating at all.
Internally, the acknowledgement should start a traceable record containing at least:
- receipt time;
- reporter and communication channel where known;
- claimed product and affected version;
- initial evidence;
- assigned owner;
- confidentiality expectations; and
- the next review point.
Do not promise a fixed remediation or disclosure date before the technical scope is understood. Instead, commit to communication milestones that the team can actually maintain.
Triage the report against exact product and release context
The first technical decision is whether the finding applies to a product for which the manufacturer is responsible.
Triage should establish:
- whether the reported behaviour can be reproduced or otherwise substantiated;
- which products, variants and supported releases are affected;
- whether a third-party component is involved;
- the security impact and realistic attack conditions;
- whether temporary mitigation exists;
- whether additional evidence is needed from the reporter; and
- whether the finding creates a separate regulatory reporting question.
A vulnerability record should distinguish facts from conclusions. “Component version 4.2 is present in release R17” is a fact. “The vulnerable function is unreachable in the supported configuration” is an assessment that should identify the evidence behind it.
When a third-party component is involved, the manufacturer may also need to coordinate with the component manufacturer or maintainer. That coordination should be tracked separately from communication with the external finder so the product-level remediation decision remains clear.
Set researcher communication rules without inventing legal immunity
A manufacturer CVD policy should make good-faith reporting predictable, but it should not promise legal protections the manufacturer cannot grant.
The policy can explain expected researcher behaviour, such as avoiding unnecessary access to personal data, service disruption, persistence, social engineering or destructive testing. It can also ask researchers to provide enough time for diagnosis and remediation before publishing detailed exploit information.
ENISA describes CVD as cooperation between finders and relevant stakeholders so that a fix, patch or mitigation can be prepared before public disclosure. That cooperative objective is useful guidance for manufacturer policy design.
However, national rules governing vulnerability research and researcher liability vary. Do not label a private company policy a universal “safe harbour” unless the legal effect has been verified for the relevant jurisdiction. A safer formulation is to state the manufacturer's own handling commitments and expected testing boundaries, while directing legal questions to applicable national law.
Keep remediation ownership inside the vulnerability workflow
CVD is not complete when a report is acknowledged or validated. The CRA's vulnerability-handling requirements connect disclosure to remediation and security updates.
Once the finding is confirmed, the controlled record should link:
- affected product and release scope;
- technical risk assessment;
- selected fix or mitigation;
- engineering change;
- verification evidence;
- release decision;
- security update or corrected version;
- reporter communication; and
- eventual advisory or disclosure decision.
If remediation requires an upstream component fix, backport or product-specific mitigation, record which approach is used for each supported release.
Where a fix cannot be delivered immediately, document the temporary mitigation, residual risk, owner and next decision point. Do not treat a workaround as silent closure.
Define public disclosure boundaries before a difficult case occurs
Annex I Part II requires manufacturers, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities. The disclosed information includes a description, affected-product identification, impact, severity and clear remediation information.
The CRA also permits delayed public disclosure in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits. The purpose is not indefinite secrecy. It is a controlled decision about when detailed information can be published without creating avoidable risk before users have had a reasonable opportunity to apply the relevant patch.
A CVD policy should therefore distinguish at least three stages:
- private coordination, while the report is being validated and remediation is being prepared;
- user protection, when mitigations or security updates are made available and affected users need actionable information; and
- public vulnerability disclosure, when sufficient detail can be released under the manufacturer's disclosure decision.
The internal process should capture who approved any publication delay, the security rationale, what user protection was available, and when the decision will be reviewed.
Avoid promising a universal disclosure deadline such as 30, 60 or 90 days unless the organisation has deliberately adopted and can operate that rule. The CRA establishes duties and boundaries but does not impose one universal CVD publication countdown for every vulnerability.
Do not confuse CVD with CRA Article 14 reporting
Coordinated vulnerability disclosure and mandatory CRA reporting solve different problems.
CVD governs how potential vulnerabilities are reported to the manufacturer, investigated, remediated and eventually disclosed. Article 14 reporting applies when the legal trigger for an actively exploited vulnerability or a severe incident affecting product security is met.
From 11 September 2026, manufacturers must use the CRA reporting process for those reportable events. The European Commission's current guidance describes an early warning within 24 hours of awareness and a full notification within 72 hours, followed by the applicable final-report stage.
A CVD intake process should therefore include an escalation question: does the evidence indicate a separate Article 14 trigger? That question should not replace ordinary vulnerability handling, and the absence of an Article 14 trigger does not remove the manufacturer's vulnerability-remediation and disclosure duties.
Keep the two records connected so awareness time, exploit evidence, product scope and remediation status can be reconstructed if reporting becomes necessary.
Protect sensitive information without losing auditability
Vulnerability reports can contain exploit details, credentials, crash dumps, customer information or unpublished product information. The workflow should define who may access that material and how it is retained.
At minimum, separate:
- the original reporter submission;
- internal technical analysis;
- restricted exploit material;
- product and release scope;
- decision records;
- external communications;
- remediation evidence; and
- the final public advisory.
Access restrictions should not destroy traceability. A later reviewer should still be able to see that a decision was based on controlled evidence even if the sensitive attachment itself is limited to a smaller group.
The public policy should also give reporters a reasonable way to submit sensitive information. Publishing only a general support mailbox can create an avoidable conflict between secure handling and easy reporting.
Define closure criteria
A vulnerability should not be marked closed merely because code changed.
Useful closure criteria include:
- affected-product scope is documented;
- risk and exploitability decisions have evidence;
- the remediation or accepted mitigation is recorded;
- the fix has been verified for the releases claimed as corrected;
- the security update or corrected version has been released where required;
- user communication has been completed;
- public disclosure has been made or a justified delay is still actively controlled;
- third-party coordination is recorded where relevant;
- any Article 14 assessment or reporting is complete where applicable; and
- the reporter has received an appropriate final communication.
If the report is rejected as not reproducible, out of scope or not a security vulnerability, retain the rationale and the evidence used. Rejection is still a security decision.
Test the policy as an operating process
A published CVD page can look complete while the internal process fails immediately.
Run periodic exercises using a realistic external report. Verify that:
- the public contact works;
- the message reaches the correct team;
- an owner is assigned;
- the exact product and release can be identified;
- sensitive evidence is handled correctly;
- engineering and security can coordinate remediation;
- communication with the reporter remains active;
- disclosure and Article 14 escalation decisions are distinct; and
- the final evidence can be reconstructed.
The exercise should produce corrective actions for gaps such as stale addresses, unclear ownership, missing release mapping or unowned publication decisions.
A CVD policy becomes difficult to operate when intake evidence, affected-release scope, vulnerability decisions, fixes, advisories and release records live in separate systems. AA-sec is designed around traceability between product-security evidence, vulnerability work, decisions and exact product or lifecycle context, which can help keep this workflow connected to the records behind it. AA-sec does not decide exploitability, disclosure timing or CRA conformity for the manufacturer.
Key takeaway
A CRA coordinated vulnerability disclosure policy should be designed as a controlled product-security workflow, not as a static webpage. Give researchers one monitored reporting path, preserve the original evidence, map every finding to exact product scope, keep communication active, connect remediation to release evidence, define publication boundaries, and keep mandatory Article 14 reporting as a separate but connected escalation path.
The strongest policy is the one the organisation can actually execute when the first difficult report arrives.