Bug bounty programs for IoT and hardware vendors, explained

CISA's Binding Operational Directive 20-01 (2 September 2020), which requires every US federal civilian executive-branch agency to publish a vulnerability disclosure policy, states the distinction directly: "a VDP is similar to, but distinct from, a 'bug bounty.' In bug bounty programs, organizations pay for valid and impactful findings," and the directive "does not require agencies to establish bug bounty programs" — a VDP is the mandatory, no-cost baseline; a bounty is an optional, separately governed enhancement an organization can layer on top if it chooses. For a device or firmware company, the same ordering applies for reasons that have nothing to do with federal mandates: a VDP with no reward still gives you a monitored contact, triage process and safe-harbor commitment, which is also exactly what the EU Cyber Resilience Act's coordinated vulnerability disclosure requirement and the UK PSTI regime expect regardless of budget. A bounty without that underlying process in place has nothing to plug into — see how to set up a PSIRT for a hardware product company and the vulnerability disclosure policy template for building that baseline first.

A software-only bug bounty can often scope itself to "our production domains." A hardware or IoT program has to decide, layer by layer, what's actually fair game — and the clearest way to see that is in how real published programs draw the line:

The pattern across all four: scope is defined by naming specific device models, firmware layers, physical-access methods and companion software — not by a single blanket statement like "all our hardware." A device maker drafting its first hardware bounty scope should expect to make the same layer-by-layer calls: is a finding that requires opening the case and using a hardware debug port in scope? Is the companion mobile app in scope, or only the device? Is a cloud API the device talks to in scope, given it may be run by a different internal team or a third-party vendor entirely?

Safe-harbor language protects a researcher from legal action for testing conducted within a program's defined rules — but every published program this guide reviewed limits that protection to systems the operator actually owns. Arm's program (via Intigriti) states that ethical hacking consistent with its guidelines is treated as "authorized" conduct and that Arm will not pursue civil action for accidental, good-faith violations, but explicitly adds that it "cannot grant safe harbor to researchers for security testing of third-party software or systems." Intel's safe-harbor waiver similarly "does not apply to security research involving networks, systems, or devices of another party that is not Intel." For a device maker whose product bundles a third-party chipset's firmware, a licensed SDK, or a cloud backend operated by a different company, this is not a minor caveat — it is the line between what your own bounty program can actually promise a researcher and what it cannot, no matter how the marketing copy reads.

DJI's 2017 "Threat Identification Reward Program" is one of the most publicly documented cautionary cases in this space, and it is useful precisely because the same company later ran the process correctly. Per contemporaneous reporting from SecurityWeek and DroneLife, DJI launched the program via a one-page press release offering rewards of $100 to $30,000, without publishing defined scope or rules alongside it. Researcher Kevin Finisterre reported exposed SSL certificates and firmware AES encryption keys and was told he qualified for the maximum $30,000 reward — but after his lawyers reviewed DJI's proposed release agreement and judged it, in his own account, "extremely risky" and potentially "crafted in bad faith to silence anyone that signed it," he declined the payment rather than sign away his ability to discuss the finding, publishing an independent 18-page report instead. A second researcher, Sean Melia, reported an unpatched Heartbleed vulnerability alongside a SQL-injection and remote-code-execution issue with root access, was offered $500, declined it, and the two sides disputed whether he had broken a non-disclosure term by speaking to a reporter.

Nine years later, in March 2026, DJI paid a full, undisputed $30,000 bounty to researcher Sammy Azdoufal for a critical cloud-backend flaw in its Romo robot vacuum — reported independently by DroneXL, DroneDJ and AndroidHeadlines, with DJI deploying patches within days of the report and confirming payment on 7 March 2026. The difference between the two outcomes was not the size of the reward, which was identical; it was whether scope, release terms and payment process were defined and trusted going in. See ISO/IEC 29147 and 30111: the coordinated vulnerability disclosure process for the process standard a bounty program's intake and remediation workflow should still follow underneath the payment terms, and the FIRST PSIRT Services Framework for how that intake function should be structured as a standing team responsibility, not a one-off press release.