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.
Top comments (0)