How to Report a Security Vulnerability in a Smart Device: We Found No Published Way for 7 in 10 Apps We Could Check

securebydesignlabs
SecureByDesignLabs October 29, 2026
0 Comments

Last reviewed: 29 October 2026. General information, not legal advice.

If your smart camera, doorbell or baby monitor does something that looks like a security flaw, the maker is the one who can fix it. But many makers don’t say where to send a report, so the person who spots the flaw has no obvious place to take it.

How common is that? On 21 October 2026 we checked the makers’ websites behind 550 connected-device apps on Google Play, the phone apps that come with smart devices, looking for a published way to report a security flaw. We could get a clear result for 438 of them, and for about 7 in 10 of those (306 of 438, 69.9%) we found none. So don’t count on an obvious contact. The four steps below will still get your report to someone who can act on it, and if you make smart devices, the last section is for you.

How to report a flaw in a smart device: 4 steps

  1. Look for the maker’s own security contact. Start with the device brand’s website, and if the app comes from a different company, try theirs too (step 2 shows how to tell). Search the site for “security”, “report a vulnerability” or “vulnerability disclosure policy”.

    CERT/CC’s guide to finding a maker’s contact also suggests searching the web for the company’s name plus “PSIRT”. That’s short for product security incident response team, the team at a maker that handles reports of security flaws.

    Then, in your browser’s address bar, type the brand’s home address followed by /.well-known/security.txt, for example https://example.com/.well-known/security.txt. If the maker has one, you’ll see a short text page, and its “Contact:” line gives an email address, phone number or web page for reports; if not, you’ll usually get an error or “not found” page. A security contact is meant for exactly this, so you can send it your full report straight away. (This security.txt file is set out in an internet standard, RFC 9116 (2022); you don’t need to read it.)

  2. Found nothing? Check the app’s store listing. Google says it displays each developer’s legal name and email address on Google Play, “as part of your developer profile”. So the developer details on the app’s Google Play page tell you who publishes the app and where to write. Apple’s help for app makers describes a support web address that “displays on the App Store for users who have downloaded your app” and “must lead to actual contact information”.

    A general support address is fine for a first message. Keep it short, for example: “I think I’ve found a security flaw in your camera (product name). How would you like me to send you the details?”

    Don’t put the details anywhere public, such as a review or a public forum. If nobody answers, send a reminder. Our own suggestion is to give it about two weeks from your first message before going to a coordinator (the next step).

  3. No route, no reply, or a reply that doesn’t treat it as a security problem? Go to a coordinator. In the EU, every country must name one national security team as a coordinator. It’s called a CSIRT (computer security incident response team), and it acts as a trusted go-between that can contact the maker for you.

    The law also requires countries to let you report to it “anonymously where they so request”, and the coordinator must “ensure the anonymity” of the person reporting. To find your country’s team, the EU CSIRTs network’s disclosure page says the most suitable contacts are in “the CVD policies published under their specific national frameworks”, and it links an overview of those policies that names the team behind each one. If your country isn’t there, the network’s home page has a map of its member teams, where you can find your country’s.

    In the UK, the rule sits with the maker. Since 29 April 2024, makers of most consumer smart products sold in the UK have had to publish “at least one point of contact” so that people can “report to the manufacturer security issues” (the PSTI Regulations 2023, Schedule 1, paragraph 2). In our reading, that usually covers the device’s app too: the rule reaches “software used for, or in connection with, any manufacturer’s intended purpose of the product unless the product is a smartphone or a tablet computer capable of connecting to cellular networks”. Some products, such as medical devices and smart meters, are outside these rules altogether, according to OPSS. So a maker selling in the UK that publishes nothing may be breaking that rule, and you can tell the regulator. The Office for Product Safety and Standards (OPSS) enforces it, and its guidance says: “If you have a specific enquiry about compliance or wish to contact us regarding suspected non-compliance, please email OPSS.enquiries@businessandtrade.gov.uk.”

    That’s a route for the missing contact, not a go-between for your report. OPSS’s page doesn’t say it passes flaw details on to the maker, so our suggestion is to leave the details out of that message. And the NCSC’s vulnerability reporting page is for a flaw in “a UK government online service”, not a device you bought.

    For the flaw itself, outside the EU (the UK included) or if you can’t find your country’s team, there’s the CERT Coordination Center (CERT/CC) in the US. Treat it as a fallback: it asks you to “try contacting the vendor directly” (the maker) first, and it says it “does not accept or respond to every report”. It also recommends “reading our vulnerability disclosure policy and guidance before submitting a vulnerability report”.

  4. Send the right details. Say which product and model it is, and which firmware or app version it runs if you can find it. Then describe what you saw, how it happened and what someone could do with it. Add whether you’ve already told the maker, and how to reach you.

    Give what you can; you don’t need to be a security expert, and the fuller checklist is below.

A note for every step: Test only devices you own or are allowed to use, and keep away from other people’s data. If checking the flaw would mean opening someone else’s data, don’t check: report what you’ve seen and say you haven’t confirmed it. And our suggestion is not to publish the details while you’re still trying to reach the maker or a coordinator.

While you wait: the UK’s National Cyber Security Centre has general advice for any smart device (last reviewed February 2024). Change a default password, turn on 2-step verification if “the device or app offers” it, install updates, and “If you don’t need to access your smart device when you’re away from your home Wi-Fi, then switch off the ‘remote access’ functionality.” The rest is in its smart devices guide.

What happens when a flaw can’t be reported?

It may never reach the maker. The internet standard behind security.txt opens with exactly this problem: “When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported.” (RFC 9116, 2022).

The other outcome is that the flaw goes public without the maker. CERT/CC’s guide to handling reported flaws covers the case where a reporter “has been unable to find a way to contact the vendor”. It gives two options: the reporter “may publish the report on their own”, or they may “attempt to engage a coordinator” (Finding Vendor Contacts). Going public first isn’t what we suggest, and it’s why the coordinator step matters: a coordinator gives your report somewhere to go even when the maker publishes nothing.

Our two-week suggestion is only a rule of thumb for when to try a coordinator. CERT/CC’s own rule, for when it treats a maker as unresponsive, is a different thing. Its Unresponsive Vendor page lists when it “would consider the vendor to be non-responsive”:

  • the reporter and the maker “had already been in contact about the vulnerability”;
  • the reporter “has repeatedly attempted to communicate with the vendor”;
  • the maker “has been non-responsive for at least two weeks”;
  • and either “an already-agreed embargo date has passed” (a date agreed for the details to go public), or “no embargo date was set and at least six weeks have elapsed since the vendor’s last response”.

How often is there no published route?

For most of the apps we could check. In our 21 October 2026 check, for 306 of the 438 connected-device apps whose result we could determine (69.9%), we found no published way to report a security flaw. We counted a route if we found a security.txt file with a contact, or a page telling a reporter where to send a vulnerability, on the maker’s website or on the website behind the email address it publishes.

Read it as a floor, not a verdict on any maker. A maker may publish a route at an address our checks don’t reach, or with a parent company, so “no route we could find” is not “no route exists”. Apps whose result we couldn’t determine (for example, a site that blocked our checks) are left out rather than counted as “no”, and the figure counts apps, so a maker with two apps counts twice. The method and the full results are in our study of 550 connected-device apps.

What should you send in your report?

The EU CSIRTs network lists what a report to a national coordinator “should include at least”, but only when available, so leave out what you can’t answer. It’s a good checklist for a report to the maker too:

  • the product or service where you found it, and its version or the setting that makes it vulnerable;
  • the kind of weakness and how serious it is;
  • a description: a summary, the steps and setup needed to reproduce it, and any way to reduce the risk;
  • what it could lead to;
  • whether you’ve already reported it to the maker, and whether anyone has asked for a CVE number (the public ID given to a known flaw);
  • your contact details, including a secure way to reach you, and anything else that matters.

On contact details, our own suggestion is to give at least an email address you check.

The CERT/CC guide adds that “Reporters that do not provide enough information to a vendor or coordinator may find their reports delayed or even rejected.”

What should you avoid?

Four things, all from the CERT/CC guide:

  • Testing what isn’t yours. Research “should of course be performed on equipment that the finder is authorized to use for the purpose” (Avoid Unnecessary Risk).
  • Touching real people’s data. The same page warns that in some settings “there may be legal consequences to accessing real data”.
  • Testing what you can’t contain. Where the impact can’t be kept to a controlled test, “do not attempt to test your exploit and instead report your findings directly to the vendor” (Avoid Unnecessary Risk).
  • Going public first. “We recommend you avoid posting vulnerability details in public when making initial contact when possible” (Finding Vendor Contacts).

If you make smart devices

If someone finds a flaw in your product, can they reach you?

In the EU, that’s becoming a legal duty. The Cyber Resilience Act (CRA) is the EU’s security law for products with digital elements, such as connected devices and their apps. For products placed on the market from 11 December 2027, you’ll need to “put in place and enforce a policy on coordinated vulnerability disclosure” and provide “a contact address for the reporting of the vulnerabilities discovered in the product with digital elements”. You’ll also need a single point of contact for users that is “easily identifiable by the users”. Products placed on the market before that date are covered only if they’re substantially modified from then on. In our reading of the Commission’s guidance, that’s judged device by device, not model by model: it quotes the EU’s Blue Guide, which says placing on the market refers “to each individual product, not to a type of product”.

One duty already applies. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities (flaws attackers are already using) in products the law covers, including products already on the market. A published route gives a researcher a way to tell you about one.

Two places to start:

  • See what an outsider sees. Look up your app in our connected-device readiness explorer, which shows what our 5 October 2026 run found for it, including whether we found a route to report a security flaw. That run used the earlier version of the route check, so the explorer’s rates differ from the 21 October figures above. If your app isn’t in our sample, the page says how to ask us to check it.
  • Check the EU radio rules too. If your device has a radio, such as Wi-Fi or Bluetooth, our EN 18031 checklist covers how the EU’s security rules for internet-connected radio equipment reach your companion app and cloud.

Sources

This is general information, not legal advice.

Continue in Cyber Resilience Act:

Categories: Cyber Resilience Act

Related Articles

Responses

Your email address will not be published. Required fields are marked *