Bug Bounty Programme

A bug bounty programme is a structured initiative in which a manufacturer publicly invites external security researchers to find and report security vulnerabilities in defined products or systems, in exchange for a financial reward (the 'bounty'). Bounties are typically scaled by severity: critical vulnerabilities command the highest rewards, while informational or low-severity findings may receive smaller payments or acknowledgement only. Bug bounty programmes operate within a scope that defines which products, services, and vulnerability types are eligible, and they include the same core components as a CVD programme — a reporting channel, a triage process, safe harbour terms, and a disclosure timeline — with financial incentives layered on top.

Bug bounty programmes are complementary to CRA compliance but are not a substitute for the mandatory CVD policy required by Article 13(6). The CRA's requirement is for a coordinated vulnerability disclosure process — a mechanism through which any researcher or user can report a vulnerability and receive a timely response. A bug bounty programme can satisfy this requirement if it includes all the elements of a CVD policy (published contact, scope, safe harbour, timelines, and response commitment), but a bug bounty programme that offers rewards without a defined response process, or that discourages disclosure of out-of-scope findings, is not a compliant CVD policy. CRA compliance requires the CVD channel to be open and unconditional.

An effective bug bounty programme is built on a functioning CVD foundation. Key design elements include: a clearly defined scope identifying which products and systems are in scope; a severity-banded bounty table with transparent payout criteria; explicit safe harbour language protecting good-faith researchers from legal action; a defined response SLA (e.g. 5-day acknowledgement, 30-day triage, 90-day resolution target); a clear disclosure policy — most programmes use coordinated disclosure with a fixed embargo period; and a researcher communication commitment ensuring reporters receive regular updates. Manufacturers should also consider whether a public or private programme is appropriate: public programmes attract more researchers but also more noise; private programmes (invite-only) provide higher signal-to-noise ratios.

The most damaging bug bounty mistake is creating a programme that is too narrow in scope — excluding cloud backends, mobile applications, or specific product lines — and then refusing to process vulnerability reports that fall outside scope. Researchers who discover critical vulnerabilities outside scope have nowhere to go and may resort to public disclosure. Any product with digital elements subject to the CRA must have a CVD channel that accepts reports on all covered products, regardless of bug bounty scope. A second error is slow payment and opaque decision-making, which damages the manufacturer's reputation with the research community and reduces future report quality.