DEV Community: Catalin Shipmark

CRA vulnerability reporting for app teams: 24 hours, 72 hours, 14 days

Catalin Shipmark — Sat, 07 Nov 2026 13:41:29 +0000

Short answer: if your app has a vulnerability that attackers are actually exploiting, the manufacturer has 24 hours to send an early warning to ENISA's Single Reporting Platform.

Two things must be reported: actively exploited vulnerabilities and severe incidents that affect the security of the app (Article 14(1) and (3)).
Each one has three steps: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a fix (vulnerabilities) or one month after the notification (incidents).
The clock starts when you "become aware": when an initial assessment shows with reasonable certainty that your product is being exploited, not when a CVE is published.
This has applied since 11 September 2026, including to apps that were already on the market.

What must be reported

Article 14 of the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets two separate reporting duties for manufacturers:

Actively exploited vulnerabilities contained in the product (Article 14(1)).
Severe incidents having an impact on the security of the product (Article 14(3)).

Both are notified at the same time to the CSIRT designated as coordinator and to ENISA, through the single reporting platform established by ENISA under Article 16. The duty sits with the manufacturer: normally the company that publishes the app under its own name. If you are an agency building apps for clients, see whether the CRA applies to your apps and agree in writing who reports.

An ordinary vulnerability, one that exists but has not been exploited, does not have to be reported under Article 14. It still has to be handled and fixed under the vulnerability handling requirements of Annex I, Part II, from 11 December 2027. Voluntary reporting of other vulnerabilities, cyber threats and near misses is possible under Article 15, but ENISA says this is not yet available on the platform and will come in a later phase.

The three deadlines

Step	Actively exploited vulnerability (Art. 14(2))	Severe incident (Art. 14(4))
Early warning	Without undue delay and in any event within 24 hours of becoming aware. Where applicable, it names the Member States where the manufacturer knows the product has been made available.	Within 24 hours of becoming aware. It says at least whether the incident is suspected to be caused by unlawful or malicious acts and, where applicable, the Member States where the product has been made available.
Notification	Within 72 hours of becoming aware: general information about the product, the general nature of the exploit and the vulnerability, corrective or mitigating measures taken and those users can take, and how sensitive you consider the information.	Within 72 hours of becoming aware: the nature of the incident, an initial assessment, corrective or mitigating measures taken and those users can take, and how sensitive you consider the information.
Final report	No later than 14 days after a corrective or mitigating measure is available: a description of the vulnerability, its severity and impact, information on any malicious actor where available, and details of the security update or other measures.	Within one month after the 72-hour notification: a detailed description of the incident, its severity and impact, the type of threat or likely root cause, and the mitigation measures applied and ongoing.

A step can be skipped only if its information was already provided in an earlier one. The CSIRT that receives the notification can also ask for intermediate reports on status updates (Article 14(6)).

The deadlines run from the moment of awareness, not from the previous submission. ENISA notes in its FAQ that the platform's 72-hour counter is currently calculated from the 24-hour submission, so a notification can appear overdue early. A future release will use the "became aware" field instead.

What "actively exploited" means

Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. In practice, for an app team:

A vulnerability that is only known, for example a new CVE in one of your dependencies, is not enough on its own.
A flaw found during your own testing, a penetration test or a good-faith report from a researcher is not exploitation by a malicious actor. Noerr's summary states that a zero-day found or reported only in testing is not enough; there must be evidence of unauthorised exploitation in a live system.
Listings such as CISA's Known Exploited Vulnerabilities catalogue or the European Vulnerability Database are strong indicators, but they do not replace a case-by-case assessment of whether the vulnerability can be exploited in your app.

When you "become aware"

The CRA does not define "becoming aware", and ENISA's platform FAQ refers to the Commission's own FAQ for it. Law-firm summaries of the Commission guidance give a consistent reading:

Awareness arises when an initial assessment concludes, with a reasonable degree of certainty, that a vulnerability in your own product is being exploited (Noerr; CMS describes it as a "sufficient degree of certainty").
A root cause analysis, or findings about the damage or the attacker, are not needed at that point. They belong in the later reports.
CMS adds that weekend or on-call cover is not mandated, but a ticket that sits unread can already make a notification late, and recommends documenting the path from first signal to notification.

For a small app team, the practical consequence is that someone must look at incoming security signals quickly and record when the assessment was made. That timestamp is what the deadlines are measured against.

What counts as a severe incident

Under Article 14(5), an incident is severe if it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or is capable of leading to malicious code being introduced or executed in the product or in the systems of a user.

For apps, the second limb is worth noting: an attacker getting into the build or release process and shipping a tampered version to users is the kind of event this targets. Severe incidents are about the security of the product, not every outage of your company's IT.

Where and how to report

Reports go through the CRA Single Reporting Platform, which ENISA launched on 11 September 2026 at portal.cra-srp.enisa.europa.eu. From ENISA's FAQ:

You log in as an "Assigned Representative" with a personal EU Login account that has multi-factor authentication enabled. You can create the EU Login account in advance.
Each manufacturer has one Primary Assigned Representative and up to 20 Secondary ones. The CSIRT verifies the association, but you can submit up to 20 notifications before verification becomes mandatory, so a missing verification does not block an urgent report. ENISA asks manufacturers to register on the platform only when a notification is needed.
There is no API at launch: notifications are entered through the web interface, in English.
One notification per vulnerability or incident is enough, even for a group with several EU subsidiaries.
If the platform is down, wait and submit when it is back; you may contact the CSIRT directly in the meantime but must still submit through the platform.

Which CSIRT

Under Article 14(7), you choose the CSIRT designated as coordinator in the Member State of your main establishment in the EU, which is where decisions related to the cybersecurity of your products are predominantly taken. If that cannot be determined, it is the Member State of the EU establishment with the most employees. A manufacturer with no EU establishment uses, in this order, the Member State of its authorised representative, its importer, its distributor, or the Member State with the most users. ENISA warns that choosing the wrong CSIRT may invalidate the notification.

The receiving CSIRT shares the notification with the CSIRTs of the Member States where the product is available. In justified cases it can delay that sharing (Article 16(2)); a Commission delegated act adopted on 11 December 2025 sets the conditions.

Telling your users

Reporting to authorities is not the end. Article 14(8) requires the manufacturer, after becoming aware, to inform the impacted users, and where appropriate all users, about the actively exploited vulnerability or severe incident and about any risk mitigation and corrective measures they can take, where appropriate in a structured, machine-readable format. If you do not inform users in a timely manner, the notified CSIRTs may do so where they consider it proportionate and necessary.

For an app, that usually means a release note for the security update, an in-app message or email to affected users, and a security advisory page you can point to.

Apps that are already on the market

Most CRA obligations apply only to products placed on the market from 11 December 2027. Reporting is the exception: Article 69(3) applies the Article 14 obligations to all products in scope that were placed on the market before that date. So the app versions your users have installed today are covered.

ENISA's FAQ adds that there is no duty to report retrospectively if you became aware of the exploitation before 11 September 2026. If you become aware on or after that date, the duty applies even if the vulnerability itself is older.

Vulnerabilities in third-party components

Most exploited vulnerabilities in apps will sit in a dependency: an SDK, a networking library, a native module. Two rules apply:

If the component's vulnerability is actively exploited in a way that affects your app, you report it as the manufacturer of the app. Noerr notes that you must check independently whether there is reliable evidence of exploitation for your own product; suppliers have no CRA duty to tell you.
Article 13(6) separately requires you to report a vulnerability you identify in an integrated component, including open-source components, to the person or entity manufacturing or maintaining it, and to share your fix where you made one.

This is why an SBOM per release matters for reporting: without a list of what is in each app version, you cannot tell within hours whether a newly exploited library is in your product. See the guides for Flutter and React Native.

Fines

Provision	What it says
Article 64(2)	Non-compliance with Annex I and with the obligations in Articles 13 and 14 is subject to administrative fines of up to EUR 15 000 000 or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.
Article 64(10)(a)	Microenterprises and small enterprises are not fined for missing the 24-hour early warning deadline of Article 14(2)(a) or (4)(a). The other reporting steps and the duty to report remain.

A reporting runbook for app teams

Decide who reports for each app. Name the manufacturer, and if an agency maintains the app, write down who notices, who assesses and who submits.
Create EU Login accounts with MFA now for at least two people who can submit, and know which CSIRT is yours.
Keep an SBOM for every released version so you can answer "are we affected?" in minutes.
Watch for exploitation signals: known-exploited lists, advisories for your dependencies, crash and abuse reports, and your security contact address.
Record the time of the assessment that concluded your app is being exploited. That starts the 24-hour clock.
Send a short early warning rather than waiting for complete facts. Details belong in the 72-hour notification and the final report.
Prepare the user message in parallel with the fix, and track the 14-day final report deadline from the day the update is available.

Try it on your own app: the free Shipmark scanner builds a CycloneDX SBOM from a lockfile in the browser and checks it against OSV.dev. Not sure the CRA applies? Use the six-question CRA check.

Sources

Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Articles 3(40)–(44), 13(6), 14, 15, 16, 24, 64 and 69.
ENISA: Single Reporting Platform, Frequently Asked Questions.
European Commission: CRA reporting obligations, updated 11 September 2026.
Noerr: CRA Single Reporting Platform launched, reporting requirements apply with immediate effect, 15 September 2026.
CMS: CRA reporting obligations: the 24-hour clock is ticking, but when does it start?, 1 October 2026.

This guide summarises EU law, ENISA material and law-firm readings of non-binding Commission guidance for practical use. It is not legal advice. Related: Does the CRA apply to mobile apps? · SBOM for Flutter apps · SBOM for React Native apps.

Originally published on shipmark.eu, where the guide is kept up to date. More guides for app teams: shipmark.eu/guides.

Does the Cyber Resilience Act apply to mobile apps?

Catalin Shipmark — Sat, 07 Nov 2026 13:32:50 +0000

Short answer: yes, for most apps published by companies.

An app that users download and run on their phone is software "provided to and obtained by a user", which the Commission treats as a product with digital elements.
It is covered when it is made available in the EU in the course of a commercial activity. A price is not required: monetisation through ads, data or related services can be enough.
A website or web app used only in the browser is not covered on that basis alone, but the backend of an installed app can be.
Reporting of actively exploited vulnerabilities already applies, since 11 September 2026, to apps that are on the market today. Everything else applies from 11 December 2027.

What the regulation says

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, applies to "products with digital elements made available on the market" whose intended or reasonably foreseeable use includes a data connection to a device or network (Article 2(1)). Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions.

A mobile app is software, and it connects to networks almost by definition. The questions that decide whether a specific app is in scope are therefore narrower: is it supplied for local use, is it made available in a commercial context, and does an exclusion apply?

1. Installed apps are products, browser-only web apps are not

The Commission's guidance on the application of the CRA, adopted on 27 July 2026 (C(2026) 5252), explains that standalone software is in scope when it is provided to and obtained by a user and executed on the user's side. That covers apps downloaded from the App Store or Google Play, installed desktop software and browser extensions.

Software that executes remotely and is merely accessed by the user, such as a typical website or web app, is not a product with digital elements on that basis alone. The guidance uses online banking as an example: the banking app customers install is in scope and the bank is its manufacturer, while banking used purely through a web browser is not itself a product.

2. "Commercial activity" is broader than charging a price

The CRA covers products made available in the course of a commercial activity. According to the Commission guidance and the summaries published by law firms, a commercial context can exist without a direct price, for example when:

the software is used to monetise other products or services;
personal data is required for purposes other than security, compatibility or interoperability;
access to the software is tied to buying a service.

The assessment is made per product, not per company. A donation link alone does not make software commercial, and separately sold consulting or training does not automatically make a free product commercial.

Example	Likely position
Paid app, or free app with in-app purchases	In scope
Free app from a company, financed by ads or data collection	In scope
Free app that is part of a paid service (banking, retail, utilities, fitness)	In scope; the company that publishes it is the manufacturer
Companion app for a connected device	In scope, together with the device
Free hobby app by an individual, with no monetisation of any kind	Usually outside scope
Website or web app used only in the browser	Not a product on that basis alone

These examples summarise the guidance for practical use. Borderline cases depend on the facts and are worth checking with a lawyer.

3. The app's backend can be in scope too

Because the definition includes remote data processing solutions (Article 3(2)), the servers an app relies on can fall under the CRA. The Commission applies three tests: the processing happens at a distance, the app cannot perform one of its functions without it, and it was designed by or under the responsibility of the manufacturer. Internal systems the app does not interact with, such as a CRM, HR tools or CI/CD pipelines, are not remote data processing solutions.

In practice: the API your app calls to log users in or load their data is likely part of the product. Your company's marketing tools are not.

4. What is excluded

Article 2 leaves out products already covered by specific EU rules, including:

medical devices and in vitro diagnostic medical devices under Regulations (EU) 2017/745 and 2017/746;
motor vehicles and related systems covered by type-approval rules, and certain civil aviation and marine equipment;
products developed or modified exclusively for national security or defence purposes.

A health app that is not itself a medical device under the MDR is not excluded by this rule. The test is whether the app is certified as a medical device, not whether it deals with health.

5. Some apps are "important products"

Most apps fall into the default category, for which the manufacturer can assess conformity itself. Annex III lists important products with digital elements that face stricter conformity assessment. App-relevant examples include password managers, VPN products, standalone browsers and software that searches for, removes or quarantines malicious software. If your app's core function is one of these, check Annex III before planning the work.

6. The dates that matter

Date	What applies
11 September 2026	Manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix (one month for severe incidents). This applies to apps already on the market. There is no duty to report retroactively a vulnerability that was exploited and known before that date.
11 December 2027	All other obligations: the essential cybersecurity requirements of Annex I, an SBOM, vulnerability handling, a declared support period of generally at least five years, the technical documentation of Annex VII and the EU declaration of conformity.

Date

What applies

11 September 2026

Manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix (one month for severe incidents). This applies to apps already on the market. There is no duty to report retroactively a vulnerability that was exploited and known before that date.

11 December 2027

All other obligations: the essential cybersecurity requirements of Annex I, an SBOM, vulnerability handling, a declared support period of generally at least five years, the technical documentation of Annex VII and the EU declaration of conformity.

Each version placed on the market should have a declared support period. Later downloads of the same version are not new placements, while variants with different components, configurations or functions are separate products.

What app teams should do now

List every app you publish or maintain in the EU, with its platforms and current version.
For each one, note who publishes it under their name. That company is normally the manufacturer.
Set up a way to notice actively exploited vulnerabilities in your dependencies quickly. Without an SBOM per release, the 24-hour deadline is very hard to meet. See how CRA vulnerability reporting works.
Register for ENISA's Single Reporting Platform before you need it. Access requires an EU Login account with multi-factor authentication.
Decide the support period you will declare for each app and plan the updates it implies.

Try it on your own app: the free Shipmark scanner builds a CycloneDX SBOM from a lockfile in the browser and checks it against OSV.dev. Not sure the CRA applies? Use the six-question CRA check.

Sources

Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Articles 2, 3, 13, 14 and Annexes I, III, VII.
European Commission: guidance to support the implementation of the CRA, C(2026) 5252, 27 July 2026.
ENISA: The CRA Single Reporting Platform is launched, 11 September 2026.
ENISA: Single Reporting Platform FAQ.
Summary of the final Commission guidance and Osborne Clarke's analysis.

This guide summarises EU law and non-binding Commission guidance for practical use. It is not legal advice. Related: CRA vulnerability reporting · SBOM for Flutter apps · SBOM for React Native apps.

Originally published on shipmark.eu, where the guide is kept up to date. More guides for app teams: shipmark.eu/guides.