A vulnerability disclosure policy for a connected product needs three things: a contact for reporting security issues, a timeline for acknowledging a report, and a timeline for status updates until the issue is resolved. Publish it where anyone can find it, in plain English, without asking first.
Where the requirement comes from
ETSI EN 303 645 provision 5.2-1 says the manufacturer shall make a vulnerability disclosure policy publicly available that includes at minimum contact information and timelines for initial acknowledgement of receipt and for status updates until resolution. The UK product security regime asks for the same elements: how to report issues, and the timescales for acknowledgement and status updates. GOV.UK adds that the information should be free, available in English without a prior request, and easy to understand.
What to publish
- A security contact: an email address monitored by a named team, or a web form that needs no account.
- An acknowledgement timeline: for example, a stated number of days. Pick one you can meet.
- A status update cadence: how often you will write while the issue is open.
- What the reporter can expect: whether you credit researchers and whether you will tell them before a public fix.
- Scope: which products and versions the policy covers.
The standard's commentary says a policy clearly specifies the process through which researchers and others can report issues, and that it can be updated as needed.
Coordinated disclosure
The standard refers to coordinated vulnerability disclosure, which it says is standardized by ISO in ISO/IEC 29147. The idea is a framework that gives researchers a route to inform you, puts you ahead of malicious exploitation, and gives you a chance to fix issues before public disclosure. The standard notes that in the IoT industry such practice is not yet well established, with some companies reluctant to deal with researchers.
Common mistakes
- A contact address that nobody reads.
- A policy that exists on one product page and is missing from others.
- Timelines that you do not track, so you miss them.
- A form that demands personal details or a login before accepting a report.
- No link from the product page, the app or the packaging.
Make it real inside the company
A page is not a process. Decide who triages a report, who can approve a fix, how a fix reaches devices, and who writes to the reporter. Practice once with an internal test report. Keep a log with the date received, date acknowledged and date of each update, so you can show you met your own timelines.
Link it to your update plan
A report only helps if you can ship a fix. That ties disclosure to update design and to knowing what is in your firmware. Safeguard provides SBOM and dependency scanning, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Do I need a bug bounty to have a disclosure policy?
No. The requirement in the sources is a contact and timelines, not payment.
Can I use a generic support address?
Only if someone watches it for security reports and routes them. Many teams use a dedicated address instead.
Sources
Last reviewed: 19 October 2026.
