Most of the 550 Connected-Device Apps We Checked Have No Published Way to Report a Security Flaw (That We Could Find)

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

If you find a security flaw in a smart lock, robot vacuum or baby monitor, the maker may publish no way to report it. If you make one, an EU law may already require you to report some flaws, and later to publish a contact for them.

On 21 October 2026 we checked the makers’ websites behind 550 connected-device apps on Google Play. We looked for a published way to report a security flaw. For 306 of the 438 apps whose result we could determine (69.9%), we found none. Even if every app we couldn’t determine had one, that would still be 306 of all 550 (55.6%), most of them.

Who this is for: people who make connected devices and their apps, and anyone who has found a flaw and needs to tell the maker.

The short version

• Most apps: no route we could find. 306 of 438 (69.9%).
• The brand matters. We chose a list of recognised device brands sold in Europe. For 137 of their apps, 75 (54.7%) have a route and 62 (45.3%) don’t.
• Other apps do worse. In the long tail (apps we found through Play category searches), fewer than one in five have a route: 57 of 301 (18.9%).
• Each figure counts apps. A maker with two apps counts twice.

What should you do now?

• If you make a connected device: publish a clear way to report a security flaw on your website. One way is a security.txt file, a small standard file on your website that lists a security contact. The examples further down show how others do it.
• If you found a flaw: search for the maker in our connected-device readiness explorer to see whether we found a route for it.

Why does this matter now?

The EU’s Cyber Resilience Act (CRA) is a law that sets security rules for products with digital elements, such as connected devices and their apps. It sets two dates for makers:

• Since 11 September 2026, makers must report actively exploited vulnerabilities (flaws that attackers are already using) in every product the law covers. That includes products already on the market.
• For products placed on the market from 11 December 2027, makers must also provide a contact address for reporting vulnerabilities.

The exact legal wording is in the section for engineers below. The headline figures (306 of 438, and the two group rates) are also listed, at the same precision, on SDL Research. The other figures on this page come from the same 21 October check.

What did we find?

Source: SecureByDesignLabs measurement of connected-device companion apps and their makers’ websites, websites checked 21 October 2026; store-listing signals from the 5 October 2026 snapshot. Rates are over apps whose result we could determine; “could not determine” is left out of both sides, never counted as “no”. For the route, we could not determine the result for 33 recognised-brand apps and 79 long-tail apps.

What the rows mean:

• DMARC is a published email-authentication policy (RFC 9989). It lets a domain’s owner tell receiving mail servers how to handle email that fails checks on the use of its domain.
• Encryption in transit means data is scrambled while it travels over the internet. This row is what the developer says on Google Play, not something we tested.
• Trader details here means the trader country shown on the app’s Google Play listing.

What the table shows:

• For most apps, we found no route. Of the 438 apps whose result we could determine, 306 (69.9%) have none. That holds however the 112 we couldn’t determine are counted: between 55.6% and 76.0% of all 550 apps whose maker has a website.
• Recognised brands do much better, but not all of them. 54.7% of recognised-brand apps have a route, about 2.9 times the long tail’s 18.9%. For the other 62 recognised-brand apps we could determine (45.3%), we found none, close to half.
• The gap shows up in several signals. Nearly a quarter of the long tail (24.5%) gives a free webmail address as its contact, against 1.8% of recognised brands. 55.9% of long-tail websites have DMARC, against 84.1% of recognised brands.

Who is getting it right?

Some makers already publish a route. These five are from our hand check on 21 October 2026. The links go to the pages as they are today, which may have changed since.

• DoorBird, Ecovacs and eufy each published a security.txt file with a contact (DoorBird, Ecovacs, eufy).
• TP-Link published a UK PSTI statement that says “Users can report vulnerabilities to TP-Link via” its security advisory page. PSTI is a UK law, the Product Security and Telecommunications Infrastructure Act 2022, that sets security rules for connectable products.
• Home Connect, the appliance app, published a page for reporting product security vulnerabilities. It points reporters to the Bosch Product Security Incident Response Team (PSIRT), Bosch’s product security team, which handles reports of security flaws. Bosch’s PSIRT page calls it “the central point of contact for external security researchers, partners, and customers to report cybersecurity information related to products developed by Bosch and its brands”.

Where do these makers say they are based?

For around seven in ten apps whose trader country we could read from the Google Play trader declaration, the trader declares an address outside the EU and EEA: 414 of 588 (70.4%). The most common are the United States (152), China (88), the United Kingdom (35) and Hong Kong (23). Among recognised brands, 39.4% declare an EU or EEA address; in the long tail, 25.2%. That describes the market; it is not a criticism.

Nothing here says any company is in breach of anything. The figures describe what is published today.

Look up a maker

Search for a maker in our connected-device readiness explorer to see 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 ones above.

For engineers

The legal text

• Reporting (since 11 September 2026). A manufacturer that becomes aware of an actively exploited vulnerability in its product must send an early warning “without undue delay and in any event within 24 hours of the manufacturer becoming aware of it” (Article 14(2)(a) of Regulation (EU) 2024/2847). This applies to every product within the CRA’s scope, including products already on the market (Article 69(3)).
• A published contact (for products placed on the market from 11 December 2027). Manufacturers must “put in place and enforce a policy on coordinated vulnerability disclosure” and provide “a contact address for the reporting of the vulnerabilities” (Annex I, Part II, points 5 and 6). They must also designate a single point of contact “to enable users to communicate directly and rapidly with them, including in order to facilitate reporting on vulnerabilities”, one that is “easily identifiable by the users” (Article 13(17)). Article 71(2) sets both dates.
• Products already on sale aren’t automatically exempt. In our reading, “placed on the market” applies to each individual unit, not to a product model (Article 3(21) and recital 38). So device units sold from 11 December 2027 would usually need to comply, even if the model launched earlier. Article 69(2) only spares units placed on the market before that date, unless they are substantially modified.
• What the Commission’s guidance says. Article 26(1) says the Commission “shall publish guidance” on applying the regulation. It did so on 27 July 2026 (C(2026) 5252, Annex, paragraph 11). That paragraph quotes the Blue Guide, the Commission’s guide to EU product rules. It covers “placing on the market” and “making available”. Both refer “to each individual product, not to a type of product, and whether it was manufactured as an individual unit or in series”. Take advice before treating a product that launched earlier as exempt.

What did we measure, and what didn’t we?

We looked from the outside in. No app was installed, decompiled or tested. For each maker we checked what it publishes:

• A route to report a security flaw: a security.txt file with a contact (RFC 9116), or a page that tells a reporter where to send a vulnerability, found on the maker’s website or on the domain of its published contact address.
• DMARC on the website’s domain, a published email-authentication policy (RFC 9989).
• From the Google Play listing (5 October 2026 snapshot): whether the developer declares encryption in transit in the Data safety section, whether the published contact is a free webmail address, and the country in the developer’s trader declaration.

Three limits matter for how you read the figures:

• Data safety entries are the developer’s own description. Google says the section “lets developers describe how their apps collect, share, and handle different types of data”; we don’t verify them. “Declares encryption in transit” describes a form, not a test.
• Every route figure is a lower bound. A maker may publish a route at an address our checks don’t reach, or with a parent group. “No route we could find” is not “no route exists”.
• Some checks can’t be completed. A site that blocks automated requests, times out or fails its TLS check is recorded as “could not determine”, not as “no”. For the route, that was 112 of the 550 apps whose maker has a website (20.4%), including one whose check did not finish. Our requests used a standard desktop-browser User-Agent string rather than one naming SecureByDesignLabs.

Why we re-ran the check before publishing

Our monthly run on 5 October used an earlier version of the route check. Two of its habits could push figures in opposite directions. It credited some websites that answer any address with a page, which counted routes that don’t exist. And it recorded a blocked or timed-out check as “no”.

So on 21 October we re-checked the same apps’ websites with both versions. The earlier version reproduced its 5 October figures within a point (47.6% of recognised brands against 47.0%). The current version gives 54.7% for recognised brands and 18.9% for the long tail, and it’s the one we report here. Its recognised-brand denominator is smaller (137 apps, not 164) because checks that were refused or failed now count as “could not determine” instead of “no”. We also checked ten results by hand on the same day (see Method).

Method

• The rule behind every figure here: the 21 October re-check used the current version of the route check. It records any refused or failed check as “could not determine”, not as “no”. It doesn’t credit websites that answer any address with a page. The earlier version did, which is how it counted some routes that don’t exist. How to ask for a correction is on How we measure.
• Population: 634 Google Play companion apps for connected devices, classified from a fixed pool of 942 candidates: 182 apps from recognised device brands chosen as sold in Europe, and 452 apps from 48 category searches on the UK Play store (not individually checked as sold in Europe). It is not a census of the market. One app that our matching had resolved wrongly (a pension app) is left out. Website figures cover the 550 apps whose maker publishes a website (170 recognised, 380 long tail), which point to 505 distinct websites.
• Date: websites checked on 21 October 2026; store-listing fields from the 5 October 2026 snapshot.
• Denominators: each figure counts apps. Website signals are over apps whose maker publishes a website (170 recognised, 380 long tail); store-listing signals are over all apps in the group (182 and 452), less any we could not read. Rates exclude results we could not determine, so the totals differ from row to row.
• Checks by hand: on 21 October 2026 we checked ten results by hand: the five named above, one “not found” result we chose, and four picked at random (two “not found”, two “could not determine”). Together that is five routes found, three not found and two not determined, and we found no errors in those ten. A “not found” can still hide a route published by a parent company on another domain.
• Repeated monthly. The population is fixed; we re-measure it every month.

Legal quotations are from Regulation (EU) 2024/2847 as published in the Official Journal of the European Union. This is engineering research, not legal advice, and not a conformity assessment.