Vulnerability Disclosure Programmes: We Found a Response Time at 14 of 144 Top-Grossing iPhone Publishers in Four European App Stores

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

When someone finds a security flaw in your app, they need to know where to report it and when you’ll answer. Most top-grossing iPhone app publishers we checked don’t say how soon they’ll respond when someone reports a security flaw, as far as we could find.

We checked the 144 publishers behind the top-grossing iPhone apps in the UK, German, French and Dutch App Stores on 25 October 2026. We found a stated response time for 14 of them.

A vulnerability disclosure programme (VDP) tells people who find a security flaw where to report it and what happens next. In US spelling it is a “vulnerability disclosure program”. A bug bounty programme is a reporting programme that offers rewards.

Who this is for: anyone who publishes an app and wants reports of flaws to reach the right person fast.

What should you do now?

1. Check that your app has a public page saying where to report a security flaw.
2. Add a first-response time you can keep, and say what happens after that.
3. Decide who acts on a serious report within a day. The list below has the details.

Why does a response time matter?

In our view, what matters most here is how quickly a report becomes something the manufacturer can act on for a Cyber Resilience Act (CRA) early warning. The CRA is the EU’s security law for “products with digital elements”.

Since 11 September 2026, the manufacturer of a product with digital elements must send an early warning of an actively exploited vulnerability in that product “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; Article 71(2) sets the date). An actively exploited vulnerability is a flaw that attackers have already used.

In our reading, a report that waits days in an unread inbox delays the point at which anyone can start that work. Whether an unread report already counts as the manufacturer “becoming aware” is a legal question.

Whether a particular app is in the CRA’s scope depends on the product. Our guide The Cyber Resilience Act for App Teams covers that.

From 11 December 2027, the CRA adds two duties about disclosure: a policy on coordinated vulnerability disclosure, and a single point of contact for reports named in the information given to users. Which products they cover, and the exact wording, are under “For engineers” below.

In our reading, the CRA doesn’t set a time for answering the person who reports a flaw. A stated response time is a promise the publisher chooses to make.

What did we find?

Source: SecureByDesignLabs analysis of Apple’s top-grossing iPhone app charts and the publishers’ websites and bug bounty programmes, 25 October 2026; method below.

What does a stated response time look like?

Three examples, each quoted from the publisher’s own page:

• Discord: “Vulnerability reports will always be responded to as fast as possible—usually within 24 hours.” The same page says its bug bounty now runs on Bugcrowd as “a private program with select researchers”.
• Anthropic: “Acknowledge your submission within three (3) business days”.
• TP-Link: “Respond within 5 working days”, as a step in its triage process.

Across all 14, the shortest stated time is 24 hours and the longest 7 days; most are in business or working days. Some use softer wording, such as “usually”. The other 11 are programmes on bug bounty platforms or policies on the publishers’ own sites. The loosest fit is a time for responding to an accepted report with an evaluation; we count it because it names a response time.

How does this compare with our earlier data?

On 26 September 2026, we found that 49.2% of the “Large” publishers in Apple’s European App Store charts (152 of 309, those with at least 100,000 ratings) published some way to report a security vulnerability, against 12.1% of small ones (373 of 3,082) (Only 1 in 8 Small Publishers in Europe’s App Store Charts Publish a Security Contact). For the top-grossing publishers in this study, 58 of the 120 we could check (48.3%) publish a policy or a security contact. The earlier study used Apple’s top-free charts in all 27 EU countries plus the UK, Norway and Iceland. The two studies measured different things and populations, but the shares are close. This study adds the next question: once a report arrives, does the publisher say when it will answer?

What should your own vulnerability disclosure programme say?

• Publish the policy where reporters look: a security.txt file, a small text file on your website that tells people how to report a flaw (RFC 9116). Give it a Contact: and a Policy: line, and link to the policy from your site.
• Say what’s in scope: which apps, websites and APIs the policy covers, and what kinds of testing are not allowed.
• Say how you treat good-faith research: some policies, such as Anthropic’s, include a “safe harbour” statement that the publisher won’t take legal action against researchers who follow the policy.
• Name a time you can keep for the first response, and say what happens next (triage, updates, fix, disclosure). The UK government’s own policy is a plain example: “You’ll get confirmation that we have received your report within 5 working days” (GOV.UK).
• Measure your own first-response time from the last few reports, so the promise matches what happens.
• Decide who starts the 24-hour clock. Write down who judges whether a report shows active exploitation, and who drafts the early warning.
• Check your published contact still works. One publisher’s security.txt Policy: link returned “Page Not Found” when we checked.

For engineers

Which CRA duties on disclosure apply from 11 December 2027?

Two more CRA points apply from 11 December 2027 (Article 71(2)), for products placed on the market from then; products placed on the market earlier are covered only if they are substantially modified after that date (Article 69(2)):

• Manufacturers must “put in place and enforce a policy on coordinated vulnerability disclosure” (Annex I, Part II, point 5).
• The information given to users must include “the single point of contact where information about vulnerabilities of the product with digital elements can be reported and received, and where the manufacturer’s policy on coordinated vulnerability disclosure can be found” (Annex II, point 2).

Method and limits

• Population: the top 100 top-grossing iPhone apps in Apple’s UK, German, French and Dutch App Stores, from Apple’s public chart feed on 25 October 2026. That is 400 chart entries and 144 unique publishers, as named on the App Store. Some publishers are subsidiaries. For 6 of the 45 with a policy, the policy we counted is the parent group’s; for example, Playtika Santa Monica is covered by Playtika’s programme. Without those 6 the count would be 39.
• Checks per publisher: security.txt on the main domain, with and without www; the home page’s links and five common paths; a web search of the publisher’s site; a search of bug bounty platforms; and HackerOne and Bugcrowd programme names. We read the policy pages we found (43 of the 45 could be read), in a headless browser where needed. The other 2 are counted as not determined for response time.
• Categories: “policy” means a page with reporting instructions or rules. “Contact only” means a security address, for example in security.txt, with no policy page we could find. “Names a time” means the policy names a time within which the publisher will respond to, acknowledge or confirm a report, including hedged wording such as “usually”.
• Couldn’t be checked (24): 13 sites wouldn’t load from our network with any client we used (9 of them belong to apps whose App Store names say they are dating apps); 6 blocked the security.txt check (HTTP 403) and showed no route elsewhere; and for 5 publishers we couldn’t identify a website. These aren’t counted as having no route. For 2 publishers with a policy, the policy page wouldn’t load, so we don’t know whether it names a time.
• A floor, not a census: “no route found” and “no time on the pages we read” describe what our checks found on 25 October 2026. A publisher may answer reports quickly without saying so, or set response targets that aren’t public.
• Controls: we ran the same time-finding check on three public policies known to state a time (CISA’s template, GOV.UK and the UK government’s vulnerability reporting service) and found the time in all three. It found none in a public disclosure policy known to state no response time. For programmes on HackerOne, the stated time also appears in a second source: the policy text that HackerOne’s public GraphQL interface returns for each programme.
• Captures: captures of each cited page as read on 25 Oct 2026 are kept on file.
• What this doesn’t say: a stated time is a promise on a web page, not evidence of how any publisher handles reports. Naming a publisher here says nothing about its apps’ security.
• General method: how we measure, and how to ask for a correction, is on How we measure.

Last reviewed 25 October 2026. Legal quotations are from Regulation (EU) 2024/2847. This is engineering research, not legal advice, and not a conformity assessment.