Coordinated Vulnerability Disclosure Policy for Hardware Manufacturers

A hardware vulnerability disclosure policy needs a working reporting channel, an accountable response owner and clear boundaries for safe research. Publishing a policy without monitoring the inbox leaves researchers with a document and your team without a reliable intake process.

The CVD policy template is a starting point for a small manufacturer. Its contacts, time targets and legal wording are placeholders. Replace them only with arrangements your team can actually maintain.

Decide what the policy covers

List the supported product families, firmware branches, mobile applications and manufacturer controlled backend services. Explain how to report an issue in a retired product or third party component. Avoid silently rejecting a report merely because the researcher used a different channel.

Separate the public policy from the internal incident procedure. A researcher needs contact details, requested information, permitted activity and an explanation of coordination. Your responders additionally need access to release owners, product identifiers, legal support and the reporting decision process.

CRA Annex I, Part II addresses vulnerability handling, including coordinated disclosure and a contact for reporting vulnerabilities. Article 14 reporting is a separate obligation with its own triggers and clocks; receiving a researcher email is not automatically equivalent to every reporting trigger. Use the CRA text when defining those responsibilities.

Make the intake usable

Ask for product model, firmware version, affected interface, reproduction steps, observed impact and relevant logs. Tell researchers to remove credentials and personal information. Provide a way to arrange secure transfer if the evidence is sensitive.

Do not require a complete exploit as a condition of acknowledging a report. A reproducible observation can be enough to begin triage. If evidence is incomplete, ask focused questions: “Which firmware image did you test?” is more useful than “Please provide all details”.

An acknowledgement target is an operational commitment, not a legal definition of safety. Choose it after testing staff availability, weekends and leave cover. Publish an escalation route for unanswered reports and rehearse it from an external account.

Add security.txt without treating it as the policy

RFC 9116 defines security.txt as a machine readable way to discover security contacts. The example below deliberately uses a reserved domain and cannot receive reports.

Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy

Serve your actual file over HTTPS at the well-known path. Keep the Contact and Expires fields current; validate the deployed response and the linked policy. Publishing this example unchanged would create a broken reporting channel.

The RFC describes the file format. It does not provide a complete disclosure agreement, guarantee safe harbour or decide your regulatory reporting obligations.

Define research boundaries carefully

Say whether testing is permitted on researcher owned devices, a dedicated test environment or other specifically authorised systems. Describe activities that can harm customers: availability testing against production, accessing someone else's data, persistent access and physical interference.

Have counsel review any legal assurance you intend to offer. A manufacturer cannot promise protection against every third party claim or jurisdiction. Never imply that a short template grants unlimited permission to test customer deployments.

Also explain compensation accurately. If there is no bounty programme, say so. Researchers should not need to guess whether acknowledgement, credit or payment is offered.

Walk one report through the process

In this fictional exercise, a researcher reports that an undocumented debug service is reachable on gateway firmware 2.4.0. The intake owner acknowledges receipt, creates a restricted ticket and asks for the exact image hash and network setup. Engineering checks whether the service is present in released builds. Security evaluates exploitability and affected installations.

The team records the evidence available at each time, the disclosure contact and the next update date. It separately checks whether any mandatory reporting trigger is met. No fictional exercise ticket is sent to a regulator.

When the issue is fixed, the team coordinates an advisory that identifies affected and corrected releases, practical mitigations and credits agreed with the researcher. Keep sensitive details restricted until the disclosure decision is made; record the reason for any delay rather than imposing an indefinite embargo.

Prove the process works

Before publishing the policy, send a harmless test message, check backup access, rehearse an out of hours escalation and confirm the mailbox renewal owner. Keep the exercise record with the policy version.

We have not tested Cenitia's operational intake or authorised research against any device through this article.

CRA applicability and timing

Most CRA product obligations apply from 11 December 2027; manufacturer Article 14 reporting applies from 11 September 2026. Check the product scope, role and specific transitional provisions before treating a future requirement as a current duty. See the Commission manufacturer guidance and reporting guidance.