A product security contact point is not merely a published email address. It should reliably receive reports, preserve submissions, acknowledge reporters, route cases to the correct security team and remain operational when staff or organisational structures change.
Annex I Requires a Vulnerability Reporting Contact
Annex I Part II point 6 requires manufacturers to take measures facilitating the sharing of information about potential vulnerabilities in their products and third-party components, including by providing a contact address for reporting vulnerabilities discovered in the product. The contact therefore needs to serve real vulnerability intake rather than simply point researchers toward ordinary sales or marketing channels.
- Provide a vulnerability reporting contact.
- Accept potential vulnerability information.
- Cover product and relevant third-party component reports.
- Connect the contact to vulnerability handling.
Annex II Requires a Single Point of Contact
Annex II point 2 requires the user information accompanying the product to identify the single point of contact where information about vulnerabilities can be reported and received and where the manufacturer's coordinated vulnerability disclosure policy can be found. The external experience should therefore be simple even if the manufacturer uses several internal engineering or product-security teams behind the contact point.
- Publish one clear entry point.
- Allow information to be reported and received.
- Link or identify the CVD policy.
- Route internally without burdening the reporter.
Use a Durable Address Rather Than a Personal Mailbox
The CRA does not prescribe a particular email naming convention or reporting technology. Operationally, however, the contact should survive staff changes. A role-based address, maintained web form or another durable reporting mechanism is usually more reliable than publishing one employee's personal mailbox. Ownership and backup responsibility should be defined so reports do not disappear during holidays, role changes or organisational restructuring.
- Use a durable reporting mechanism.
- Avoid dependence on one individual.
- Assign primary and backup ownership.
- Review the contact when organisational responsibilities change.
Monitor the Contact Point
A published reporting contact has little value if nobody monitors it. The manufacturer should define who reviews incoming reports, how often the queue is checked and what happens outside ordinary staff availability where the product risk justifies faster handling. Automated acknowledgement can reassure reporters that a submission arrived, but automation should not replace security triage.
- Assign queue ownership.
- Define monitoring expectations.
- Use acknowledgement where appropriate.
- Escalate urgent reports quickly.
Preserve the Original Submission
Incoming reports can contain product versions, configuration information, logs, proof-of-concept code, screenshots or other details needed during investigation. The contact system should preserve the original report and attachments while creating a structured internal case. This avoids losing important technical context when reports are copied manually between support, engineering and security teams.
- Preserve the original message.
- Preserve attachments.
- Record receipt time.
- Create a traceable internal case.
Route Reports by Product Without Changing the External Entry Point
Larger manufacturers can have many product teams, but external researchers should not need to understand the manufacturer's internal organisation before reporting a vulnerability. The single external contact can route submissions using product name, version, component or business-unit information. Internal ownership should be maintained in case-management rules rather than creating a maze of public addresses that can become obsolete.
- Collect product-identification information.
- Route internally by product.
- Maintain clear case ownership.
- Keep the public entry point stable.
Make It Possible to Exchange Follow-Up Information
Annex II describes a point where information can be reported and received. The process should therefore support two-way communication where appropriate. The manufacturer may need clarification, additional reproduction details or confirmation from the reporter. The reporter may need acknowledgement or information about remediation and disclosure coordination. A one-way form that cannot support any follow-up can make coordinated disclosure unnecessarily difficult.
- Allow follow-up questions.
- Maintain reporter contact information where provided.
- Protect sensitive vulnerability details.
- Connect communication to the case record.
Security of the Reporting Channel Should Match the Information
Vulnerability reports can contain sensitive technical information. The manufacturer should consider appropriate protection for the reporting channel and stored submissions. The CRA does not mandate one encryption technology for vulnerability reports. Optional mechanisms such as encrypted email or secure upload can be offered where appropriate, but the reporting process should remain usable enough that researchers are not forced to disclose sensitive findings through an unrelated public channel.
- Protect stored reports.
- Restrict access to vulnerability cases.
- Offer appropriate secure submission options.
- Avoid unnecessary barriers to reporting.
The Product Security Contact Is Not the CRA Single Reporting Platform
The manufacturer's product security contact receives vulnerability information from researchers, customers and other external sources. The CRA Single Reporting Platform serves a different function for regulatory notifications under Article 14 and related provisions. A researcher should not be expected to submit an ordinary product vulnerability report through the manufacturer's regulatory SRP workflow. Internally, however, a report received through the product security contact can trigger an Article 14 assessment if evidence of active exploitation emerges.
- Keep researcher intake separate from SRP submission.
- Route reports into internal vulnerability handling.
- Assess Article 14 triggers internally.
- Escalate qualifying cases without disrupting CVD.
Test the Contact Point Periodically
Manufacturers should periodically verify that the published contact still works and reaches the responsible team. A simple controlled test can confirm message receipt, automated routing, acknowledgement and case creation. This is especially useful after website migrations, email-system changes, mergers or security-team reorganisations. Evidence of the contact address is specifically relevant to Annex VII technical documentation.
- Test inbound delivery.
- Test routing.
- Test case creation.
- Review the published address after organisational changes.
Retain Evidence of the Contact Point
Annex VII explicitly refers to evidence of the provision of a contact address for reporting vulnerabilities. Useful evidence can include the published contact information, user instructions, CVD policy location, ownership records and controlled tests showing that the contact works. The objective is to demonstrate that the manufacturer has created an operational route through which vulnerability information can actually enter the handling process.
- Published vulnerability contact.
- Annex II user information.
- CVD policy location.
- Ownership record.
- Contact-point test evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.