Method
Every figure in our published data, and every finding we raise with a company from that data, comes from the checks on this page.
They use public information only: what a company publishes in an app store, on its own website and in public DNS. Anyone can repeat them. If a result about your company looks wrong, tell us.
What we measure
App publishers and device makers
A security contact (security.txt)
Whether the company publishes a security.txt file (RFC 9116), the standard place to tell researchers where to report a vulnerability. We look at /.well-known/security.txt and /security.txt. A file counts only if it contains a Contact: line, so an error page or a redirect to the home page does not. We also record whether the file’s own Expires: date has passed.
App publishers and device makers
A disclosure route
Any published way to report a vulnerability: a security.txt file or a vulnerability-disclosure page, and for app publishers a bug-bounty programme linked from the home page. We look on the company’s own website, and for device makers also on other company domains named on the store listing. A page counts only if its title, address or text shows it is for reporting vulnerabilities.
Device makers
A support period
Whether the maker publishes a page at the usual addresses for a support-period, product-lifecycle or software-update policy. We record that such a page exists. We don’t read or judge the period it states.
App publishers and device makers
Update recency
When the app was last updated, from its store listing. We report the share of apps not updated in the past 12 months. Google Play doesn’t show an update date for every listing. Where it is missing, the app is left out and the coverage is reported. We never use the app’s original release date instead.
Also recorded for device makers: whether the maker publishes a website; whether its domain has SPF and DMARC email-authentication records, from public DNS; the Data Safety answers on its Google Play listing, such as encryption in transit; whether its privacy-policy link works; whether its contact address is a free-mail one; and the trader details it declares on Google Play.
The readiness score. The Connected-Device Readiness Explorer combines these signals into a score from 0 to 100. The weights are a judgement, and a published disclosure route carries the most weight. A signal we couldn’t determine is left out of the score entirely, rather than scored as zero. Some failed checks are recorded as not found rather than undetermined (see How we check), so a score can be lower than it should be when one of our checks failed.
No score for app publishers. We checked whether one would mean anything, and it wouldn’t. The public signals for app publishers are few and move together: a publisher either publishes a route, usually with a policy and a valid file, or publishes none of them. A score would add nothing to the simple question of whether a route exists, so we report that instead.
Where the data comes from
App publishers
Apple App Store top-free charts in 30 European storefronts (the 27 EU countries, the UK, Norway and Iceland): the overall chart plus eight categories (Business, Productivity, Finance, Health & Fitness, Utilities, Education, Medical and Lifestyle). Each app’s developer-website link gives the publisher’s domain, and apps from the same domain count as one publisher. Links to social networks, link-in-bio services and hosting platforms are not treated as a publisher’s own site. Size is estimated from the total number of ratings across the publisher’s charting apps.
Connected-device makers
Companion apps on Google Play (UK store) for connected devices sold in Europe: a curated set of recognised brands, plus apps found by searching device categories. The list is fixed, so each month measures the same makers. An app listed under more than one brand name is counted once. We check the company websites and domains named on the listing.
How we check
- Public information only. We read store listings, pages a company publishes on its own site, and public DNS records. Every check is a plain request for a public page. We don’t log in, submit forms or test anything for vulnerabilities.
- What counts as unknown. When a site refuses or challenges our request for its security.txt file (access denied, rate limited and similar responses), that answer is recorded as unknown, left out of the rate and counted separately. Two cases are not treated as unknown: a request that times out or fails to connect, and the extra checks for a disclosure page or bug-bounty link, where a refused or failed page counts as no page found. Both can make us miss a route but never invent one, which is one more reason the disclosure-route figure is a lower bound.
- Every disclosure figure is a lower bound. We only find a route where we look. A company may publish one at an address we don’t check, or take reports inside its app. “We found none” means exactly that, not “they have none”.
- Checked before it is used. Each monthly run of the device-maker data is first tested against makers whose answers we have verified by hand. If one of those comes out wrong, or a headline figure moves more than expected, nothing is refreshed until a person has reviewed it.
- Named results are re-checked first. Before we contact a company about one of its own results, we re-check that result live.
Dates and refreshes
- Monthly. App-publisher data is re-measured on the 3rd of each month, and device-maker data on the 5th.
- Every figure is dated. Each number carries the date of the snapshot it comes from. Our main data articles are dated studies: the text describes the snapshot it was written from, and a panel shows the latest monthly figures alongside it. Other articles that quote one of our figures name the month it was measured.
- Comparable over time. Each monthly snapshot is kept. When we widen a sample, the original sample continues as its own series, so month-to-month comparisons stay like for like.
Limits
- Outside-in, not an audit. We see what a company makes public. That says nothing about how secure its product is, or what it does internally.
- Samples, not censuses. Chart apps are the successful ones, so small publishers outside the charts are likely to score lower. App-publisher data covers the Apple App Store only, and device-maker data covers Google Play only.
- Self-declared answers. Google Play’s Data Safety answers are filled in by the developer and are not verified by Google. When we say a maker declares something, that is what the form says, not a test result.
- Size is a proxy. Ratings count is imperfect but consistent from month to month.
- Not a verdict. This is engineering research, not legal advice and not a conformity assessment. A missing public route doesn’t mean a company is in breach of anything.
Corrections
If you think we have something wrong about your company, or anywhere else on this site, email support@securebydesignlabs.com with the page address and what you think is wrong. A person will check it by hand, and if we got it wrong, we will correct it.
If you have published a security.txt file or a disclosure page since our last run, the next monthly run will pick it up.
Where these checks are used
- Security contacts across European app publishersOver 5,000 publishers in 30 European App Store markets, measured monthly
- Connected-Device Readiness ExplorerReport routes, support periods and DMARC for over 500 device makers, measured monthly
- The Cyber Resilience Act and UK companiesHow UK app publishers compare
Engineering research, not legal advice, and not a conformity assessment. Last reviewed 26 October 2026.