Only 1 in 8 Small Publishers in Europe’s App Store Charts Publish a Security Contact

Article · Security Engineering

If you’re a small publisher with an app in Apple’s European App Store charts, the odds are you publish no way for anyone to report a security flaw in your app. Only about 1 in 8 small publishers there (12.1%) publish one, against 50.0% of large publishers.

The EU Cyber Resilience Act’s reporting obligations have applied since 11 September 2026. Two weeks later, on 26 September 2026, we checked 5,671 reachable app publishers across 30 European App Store storefronts (5,071 with a measurable result) for the most basic readiness signal: a published route for vulnerability reports.

Updated 26 September 2026 with the full European sample (30 storefronts, up from 8). Refreshed monthly. Last reviewed 29 October 2026.

What we found

• Only about 1 in 8 small publishers (12.1%) publish any way to report a vulnerability, against 50.0% of large publishers. That’s a fourfold gap, far too wide to be down to chance.
• For the machine-readable file alone, security.txt, the gap is wider: 8.9% of small publishers (274 of 3,082) against 46.7% of large ones (142 of 304).
• Across everyone we could measure, 18.6% (945 of 5,071) publish some route, and 14.8% have a security.txt.
• Publishers on .app domains are almost entirely absent: 14 of 234 publish any route.
• Apps from small publishers are about 7 times as likely not to have been updated in a year: 8.7% of their charting apps (315 of 3,606), against 1.3% for large publishers (6 of 473).

How this compares

Across the web generally, security.txt is rare: about 1.25% of the top million domains host one (URIports, 2025). For the CRA specifically, UpGuard (survey data collected 13–22 Aug 2026) checked the disclosure policies of smartphone and tablet makers and 162 publicly traded software companies that almost certainly sell in the EU. It found only 14% of the smartphone and tablet makers had a basic reporting mechanism, although weighted by market share most phones and tablets come from makers that do (94% of phones, 86% of tablets). This series looks instead at App Store publishers, the long tail of companies the CRA covers through their apps, and a follow-up looks further up the chain at the SDKs inside the apps.

By country

Measured by the publisher’s country domain (.nl, .de and so on), for countries with at least 40 measurable publishers. That’s a proxy for home market, not headquarters, and .com publishers (37%) are excluded here.

Dutch publishers lead by a wide margin. That may partly reflect long-standing national guidance: the Netherlands’ National Cyber Security Centre published a coordinated vulnerability disclosure guideline in 2018 that revises one from 2013, and 7 of the 71 Dutch security.txt files we found point reports to the national CSIRT or a sector CERT. Germany, Czechia and the UK follow. Italy, Greece, Iceland, Portugal and Romania trail far behind. With 40 to 180 publishers per country, differences of a few points between neighbouring rows aren’t meaningful.

By app category

Health, fitness, medical and education apps are the least likely to publish a way to report a vulnerability.

Where a file exists, it’s often stale

• 13% of the security.txt files we found (96 of 748) have passed their own Expires: date.
• 22% (167 of 748) have no Expires: field at all, which RFC 9116 (section 2.5.5) requires.
• Just under half (49%) link to a disclosure Policy:.

Why it matters under the CRA

The Cyber Resilience Act usually covers apps that EU users can download, including from the App Store and Google Play, when they are supplied in the course of a commercial activity (Articles 2(1) and 3(22)). Our guide to the Cyber Resilience Act for app teams covers scope and obligations in full. Two dates matter:

• Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents within 24 hours (early warning) and 72 hours (notification). This applies to products already on the market, not just new ones.
• From 11 December 2027, the essential requirements apply to products placed on the market from that date (Article 71(2)); for apps already on sale before then, they apply only if the app is substantially modified afterwards (Article 69(2)). They include a coordinated vulnerability disclosure policy and a published contact address for reporting vulnerabilities (Annex I, Part II, points 5 and 6).

The CRA doesn’t mandate security.txt specifically. But it is one machine-readable way to publish that contact (RFC 9116), and it’s how researchers and scanners find you. A publisher without one isn’t necessarily non-compliant; they may accept reports another way. But they are harder to reach, and from the outside we can’t tell whether they have a process for handling reports.

Stale apps matter too. The EU’s revised Product Liability Directive applies to products placed on the market or put into service after 9 December 2026 (Article 2(1)). For those, a manufacturer can’t escape liability for a defect caused by “a lack of software updates or upgrades necessary to maintain safety” while the product is within its control (Article 11(2)(c)), and “safety-relevant cybersecurity requirements” are among the circumstances taken into account in deciding whether a product is defective (Article 7(2)(f)). From 11 December 2027 the CRA requires security updates throughout a product’s support period (Article 13(8); for apps already on sale before then, only if they are substantially modified afterwards, Article 69(2)).

What to do

1. Publish a security.txt at /.well-known/security.txt with a monitored contact and an Expires: date. Put the renewal in your calendar.
2. Write a short disclosure policy: how you receive, acknowledge and fix reports, and link it from the file.
3. Decide who reports an actively exploited vulnerability within 24 hours, and how. This obligation is already live.
4. Work out your wider CRA scope before December 2027: SBOM, support period, technical documentation (for apps already on sale before then, only if they are substantially modified afterwards, Article 69(2)).

Frequently asked questions

Does the Cyber Resilience Act apply to my iOS or Android app?

Usually, yes. If users in the EU can install your app and you make it available as part of a business, the CRA treats the app as a “product with digital elements” and you as its manufacturer, wherever your company is based. An app that isn’t listed as an important or critical product is usually in the default category, where you can assess conformity yourself through internal control (CRA Article 32(1)(a)). Pure web services with nothing installed on the device are generally outside the CRA.

Are free apps covered?

Often. The CRA covers products supplied in the course of a commercial activity, whether for payment or free of charge. A free app from a company, or one funded by ads, subscriptions or in-app purchases, is typically in scope. Genuinely non-commercial projects can fall outside it.

Does the CRA require a security.txt file?

No, not by name. From 11 December 2027 it requires a published contact point for reporting vulnerabilities and a coordinated vulnerability disclosure policy (Annex I, Part II, points 5 and 6; for apps already on sale before then, only if they are substantially modified afterwards, Article 69(2)). A security.txt file (RFC 9116) is a short text file at /.well-known/security.txt that tells researchers where to send a report. It is one machine-readable way to make that contact easy to find.

What has applied since 11 September 2026?

Reporting. A manufacturer that becomes aware of an actively exploited vulnerability in its product must send an early warning within 24 hours and a notification within 72 hours via ENISA’s single reporting platform. The same applies to severe incidents affecting the product’s security.

How many app publishers are ready for the CRA?

On this measure, few. As of 26 September 2026, 12.1% of small app publishers in European App Store charts publish any way to report a vulnerability, against 50.0% of large publishers (5,071 publishers with a measurable result, of 5,671 reachable; 30 storefronts). Having a contact is only the first step, so full readiness is lower still.

What should a small app team do first?

Publish a security.txt and a short disclosure policy, and decide who handles a 24-hour report. Those three steps help you prepare for the reporting duty in Article 14 of the CRA, which has applied since 11 September 2026. A security.txt on its own doesn’t meet that duty. Then plan the rest (SBOM, support period, documentation) before December 2027 (for apps already on sale before then, only if they are substantially modified afterwards, Article 69(2)).

Method and limits

• Sample: Apple top-free charts (overall plus Business, Productivity, Finance, Health & Fitness, Utilities, Education, Medical and Lifestyle) in all 27 EU countries plus the UK, Norway and Iceland: 10,032 apps from 5,887 publisher domains (from each app’s developer website link), of which 5,671 were reachable.
• Probe: /.well-known/security.txt and /security.txt on the domain and its www. host. We count a file only if it contains a Contact: line and isn’t an HTML error page. Any route also counts a vulnerability-disclosure page or a bug-bounty platform link on the homepage. A disclosure page counts only if it’s clearly labelled as one or contains reporting language.
• Exclusions: 600 publishers whose sites refused or challenged our request for the security.txt file (access denied, rate limited and similar responses, rather than a clean “not found”) are recorded as unknown and left out of the rates, so blocking isn’t counted as “no”. 216 domains were unreachable. Eleven publishers are left out of every count under our editorial policy, and every figure on this page is calculated without them.
• Size proxy: total App Store ratings across the publisher’s charting apps. Large means at least 100,000 ratings, mid at least 1,000, and small fewer than 1,000. It’s imperfect but consistent.
• Stale apps: an app counts as not updated in a year if its current version was released before 26 September 2025. Chart apps may skew towards active ones.
• Limits: this is an outside-in check of what a publisher makes public, not an audit. A publisher may accept reports another way, such as an address inside the app. Chart apps are the successful ones, so the rate among all small publishers may be lower; we haven’t measured publishers outside the charts. Apple App Store only.
• Series: the first snapshot (23 September 2026) covered 8 storefronts, with security.txt at 13.9% of small and 45.6% of large publishers. Re-measured on 26 September, the same 8 storefronts gave 12.3% and 46.4%, within the margin of error. The 30-storefront sample adds 2,293 small publishers, of whom 7.7% have a security.txt (177 of 2,293), so the overall small-publisher rate is lower. Refreshed monthly.
• Full method: how each check works, its limits, and how to ask for a correction: How we measure.

Snapshot: 26 September 2026. First published 27 September 2026. Last reviewed 29 October 2026. Not legal advice.