Connected-Device Readiness Explorer
Live dataset
We re-measure every one of these makers on the 5th of each month, from their own public listings and their own websites. Nothing here is estimated, modelled or generated — each Yes and No is a check that either found something or did not. How we measure sets out every check, its limits, and how to ask for a correction.
New to EN 18031? Start with our self-check for device makers.
- Check your own product — if you make connected devices, search for it and see what a buyer or an auditor sees from outside.
- See who is getting it right — the makers publishing both a report route and DMARC are listed by default.
- Verify anything we publish — filter to the same group we quoted and the headline figures recompute in front of you.
- What this is not — a ranking of who is failing. Individual results appear when you search for a maker, not as a browsable table, and a blank or Unknown result means our checks found nothing public, not that the maker does nothing.
This run, in one line. Of the 534 apps scored on 2026-10-05 (one row per app, so a maker with several apps counts once per app): 31.8% publish a route to report a security flaw (47.0% of recognised brands, 25.1% of the long tail), 64.0% have DMARC, and the median readiness score is 40/100. Figures are over apps where the answer was determinable; Unknown is excluded. Some failed checks, such as a timeout, are still recorded as not found, so a rate can be lower than the real one.
| Product | Score | Report route |
|---|
This covers a defined sample of the market, not every app — so plenty of real devices aren’t here yet. Send us the Google Play package name and we’ll reply with the result.
The package name is the id= value in the app’s Play Store URL, e.g. com.yourcompany.app.
Most of these gaps are quick to fix. Two of them are required under the EU Cyber Resilience Act from 11 December 2027: a single point of contact for reporting vulnerabilities (Article 13(17) and Annex II, point 2), and the end date of your support period, made clear at the time of purchase (Article 13(19) and Annex II, point 7). DMARC is not in the Act; we check it as good email-security practice. We publish how each check works, so you can reproduce any result yourself before you change anything.
The CRA’s reporting duty already applies: since 11 September 2026, manufacturers must report actively exploited vulnerabilities in every product in scope, including products already on the market (Articles 14 and 69(3)). A published report route gives researchers a way to tell you about one.
Responses