The quality of vulnerability handling depends heavily on intake. Losing the original report, proof of concept, affected-version information or receipt time can make later triage, remediation, researcher coordination and Article 14 assessment more difficult.
Researcher Reports Belong in the Vulnerability-Handling Process
Annex I Part II requires a coordinated vulnerability disclosure policy and measures that facilitate information sharing about potential vulnerabilities, including a contact address. A security researcher report should therefore enter a defined vulnerability-handling process even before the manufacturer knows whether the reported behaviour is a confirmed vulnerability. The reporting route should be connected to product security rather than treated as an ordinary customer-support complaint.
- Accept potential vulnerability reports.
- Route them into product security.
- Preserve technical evidence.
- Create a traceable case.
Preserve the Original Report
The original report can contain details that become important later, including exact product versions, configuration, logs, screenshots, packet captures, crash information or proof-of-concept material. The manufacturer should preserve the original report and attachments rather than replacing them with a brief internal summary. A structured case record can be added around the original evidence, but it should not erase what the security researcher actually submitted.
- Preserve the original message.
- Preserve attachments.
- Preserve proof-of-concept material.
- Record the source of the report.
Record the Receipt Time
The intake process should record when the vulnerability report was received. This helps measure internal handling and can become important if the report later contributes to manufacturer awareness of an actively exploited vulnerability under Article 14. Recording the receipt time does not by itself determine the Article 14 awareness time, because the legal reporting trigger depends on what the manufacturer becomes aware of, but preserving the timeline supports that later assessment.
- Record date and time of receipt.
- Record the reporting channel.
- Preserve later escalation timestamps.
- Do not automatically equate receipt with every Article 14 trigger.
Acknowledge the Security Researcher
An acknowledgement confirms that the report reached the responsible process and helps keep disclosure coordinated. The CRA does not impose one universal acknowledgement deadline for researcher reports. The manufacturer can nevertheless define an operational response target that reflects product risk and staffing. The acknowledgement can provide a case identifier, request missing information and explain that technical validation is underway without prematurely confirming the vulnerability.
- Confirm receipt where possible.
- Provide a case identifier.
- Request missing evidence.
- Avoid confirming severity before assessment.
Identify the Product and Affected Versions
A report should be linked to the exact product and affected versions as early as practical. The same code path can behave differently across editions, firmware branches, hardware revisions or deployment configurations. Version identification also determines which supported products may require remediation. If the reporter does not know the exact version, the product-security team should use available evidence to narrow the affected range rather than discard the report.
- Identify product family.
- Identify version or build.
- Identify relevant configuration.
- Identify potentially affected branches.
Treat Proof-of-Concept Material as Sensitive Security Information
Proof-of-concept code can help reproduce a finding, but it can also make exploitation easier if disclosed too broadly. Access to researcher submissions should therefore be limited to people who need the information for investigation, remediation, legal assessment or coordinated disclosure. The manufacturer should avoid copying exploit details into broad support systems or unrestricted communication channels merely for convenience.
- Restrict sensitive case access.
- Protect exploit details.
- Use appropriate internal channels.
- Share only what relevant teams need.
Validate the Technical Finding
The manufacturer should attempt to reproduce or otherwise substantiate the reported behaviour. Validation should identify the security property affected, prerequisites for exploitation and whether the issue exists in supported versions. A report can be valid even when the researcher's initial impact estimate is incomplete. Conversely, unexpected behaviour is not automatically a security vulnerability. Technical validation creates the evidence needed for severity assessment and remediation prioritisation.
- Attempt controlled reproduction.
- Identify exploitation prerequisites.
- Identify the affected security property.
- Record the validation result.
Handle Third-Party Component Reports Without Passing Responsibility Away
A security researcher may identify a vulnerability in a third-party component embedded in the product. The manufacturer may need to coordinate with the person or entity maintaining that component, but it still needs to assess whether its own products and supported versions are affected. The case should therefore preserve both the upstream component issue and the product-specific risk rather than simply redirecting the researcher and closing the manufacturer's record.
- Identify the upstream component.
- Assess product-specific exposure.
- Coordinate with the maintainer where appropriate.
- Keep the manufacturer's own case active where needed.
Run Article 14 Assessment When Evidence Warrants It
A researcher report can contain evidence suggesting that a vulnerability is already being exploited. If that occurs, the manufacturer should separately assess whether the CRA definition of an actively exploited vulnerability is met and preserve the relevant awareness timeline. The researcher's CVD submission does not become the Article 14 notification itself. Regulatory reporting through the CRA process and technical remediation can run in parallel.
- Assess evidence of active exploitation.
- Preserve the awareness timeline.
- Escalate potential Article 14 cases.
- Continue technical remediation.
Keep Researcher Communication Connected to the Case
Follow-up questions and disclosure coordination should remain linked to the vulnerability case. The researcher may provide new evidence, identify another affected version or clarify the proof of concept. The manufacturer may need to request retesting or coordinate publication timing after a security update becomes available. Keeping the communication history together helps avoid inconsistent statements and supports later evidence that the coordinated vulnerability disclosure policy was actually enforced.
- Keep communication with the case record.
- Record important new evidence.
- Coordinate remediation updates.
- Coordinate disclosure where appropriate.
Close the Intake Stage With a Documented Triage Decision
Researcher intake is complete when the manufacturer has enough information to move the case into triage or to document why further action is not currently warranted. The case should identify the affected product or uncertainty, validation status, relevant versions, preliminary impact and next owner. A clear handoff prevents researcher reports from remaining indefinitely in an inbox without remediation responsibility.
- Record validation status.
- Record affected versions.
- Record the next owner.
- Move confirmed or plausible issues into risk assessment.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.