Since 11 September 2026, any manufacturer of software or connected hardware made available on the EU market must send a first report on actively exploited vulnerabilities and severe security incidents in those products within 24 hours of becoming aware of them. The duty comes from Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847, the “CRA”), applies more than a year before the rest of the regulation, covers products already on sale and binds manufacturers outside the EU. A Turkish studio with a game on European app stores, a SaaS company whose app depends on its own backend, or a start-up selling smart devices in Germany may already be on the clock.
What applies now, and what comes later
The CRA is a staged regulation. Most of its design and conformity rules start in December 2027, but reporting was pulled forward:
| Date | What applies | Basis |
|---|---|---|
| 11 June 2026 | Chapter IV (notification of conformity assessment bodies) | Art. 71(2) |
| 11 September 2026 | Article 14 reporting obligations of manufacturers | Art. 71(2) |
| 11 December 2027 | The rest of the regulation, including essential cybersecurity requirements, manufacturer obligations under Article 13 and the reporting duties of open-source software stewards | Art. 71(2), Art. 24(3) |
The trap is in Article 69. Products placed on the market before 11 December 2027 are generally subject to the CRA only if substantially modified after that date, but Article 69(3) provides that Article 14 “shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027”. Legacy app versions and devices already in the field are covered by the reporting duty today. According to the Commission’s CRA FAQ, as summarised in ENISA’s SRP FAQ, the trigger is awareness: an exploitation you already knew of before 11 September 2026 need not be reported retrospectively, but one you learn of after that date must be, even if the flaw is old.
Are you a “manufacturer” of a “product with digital elements”?
The CRA applies to products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Art. 2(1)). A product with digital elements is “a software or hardware product and its remote data processing solutions” (Art. 3(1)). A manufacturer is anyone who develops or manufactures such products, or has them developed, and markets them under its own name or trademark, “whether for payment, monetisation or free of charge” (Art. 3(13)). Free-to-play games and free apps are not excluded simply because they are free.
The SaaS question turns on “remote data processing” (Art. 3(2)): processing at a distance, designed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. Recital 11’s example is a mobile application that needs an API or database provided by the manufacturer: that backend is part of the product. Recital 12 draws the other side: websites that do not support a product’s functionality and cloud services designed outside a manufacturer’s responsibility are out of scope, and the NIS2 Directive applies to cloud services such as SaaS, PaaS and IaaS. In practice:
- a pure browser-based SaaS with no product you ship is generally outside the CRA (NIS2 may apply to medium-sized and larger cloud providers);
- a desktop or mobile app, a game client, firmware or a device is a product, together with the backend you provide (or have built under your responsibility) that it needs to perform its functions;
- free and open-source software you publish but do not monetise is generally not a commercial activity (recital 18), but open-source components you integrate remain your concern: Article 13(5) requires due diligence when integrating them (from 11 December 2027), and an exploited flaw in them is reportable by you today (see below).
Products covered by the EU medical devices and in vitro diagnostics regulations (2017/745 and 2017/746) and products covered by the vehicle type-approval Regulation 2019/2144 are excluded, as are products certified under the civil aviation regulation and marine equipment (Art. 2(2) to (4)).
What has to be reported
Article 14 covers two events. An actively exploited vulnerability is one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner” (Art. 3(42)). A bug found by your own testers or reported through your bug bounty, with no evidence of malicious exploitation, is not reportable (recital 68 and the Commission’s FAQ), although you may report it voluntarily (Art. 15). The Commission’s FAQ also confirms that if the exploited flaw sits in an integrated third-party component, you must still report it as the manufacturer of the final product.
A severe incident having an impact on the security of the product is one that negatively affects, or is capable of affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or could lead to malicious code running in the product or on a user’s systems (Art. 14(5)). Recital 68 gives the example most relevant to software companies: an attacker who manages to introduce malicious code into the release channel you use to ship security updates.
The clock: 24 hours, 72 hours, final report
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of becoming aware, naming the Member States where you know the product is available | Within 24 hours, also stating whether unlawful or malicious acts are suspected |
| Notification | Within 72 hours: product, nature of the exploit, corrective measures taken and measures users can take | Within 72 hours: nature of the incident, initial assessment, measures |
| Final report | No later than 14 days after a corrective or mitigating measure is available | Within one month after the 72-hour notification |
The 24- and 72-hour deadlines are outer limits: the text says “without undue delay and in any event within” 24 or 72 hours. The receiving CSIRT may also ask for an intermediate status report (Art. 14(6)).
Where a Turkish manufacturer reports
All notifications go through ENISA’s Single Reporting Platform (SRP), operational since 11 September 2026, addressed to the national CSIRT designated as coordinator and simultaneously accessible to ENISA (Art. 14(1), (7)). The question is which CSIRT. A manufacturer with an EU main establishment reports where its product cybersecurity decisions are predominantly taken. A Turkish company with no EU main establishment follows the cascade in Article 14(7), “based on the information available to the manufacturer”:
- the Member State where the authorised representative acting for the highest number of your products is established;
- failing that, where the importer placing the highest number of your products on the market is established;
- failing that, where the distributor making the highest number of your products available is established;
- failing that, the Member State where the highest number of your users are located.
Under the last option, later notifications may go to the CSIRT you first reported to. ENISA warns that a notification sent to the wrong CSIRT may be invalidated, so document the analysis now. An authorised representative is optional (Art. 18(1)), but appointing one gives you a predictable reporting country.
From ENISA’s SRP FAQ: the people who submit for you register as “Assigned Representatives” (an SRP user role, not to be confused with the CRA’s authorised representative), each needing a personal EU Login account with multi-factor authentication; at launch the platform is English-only and offers no API. ENISA advises registering on the SRP only when a notification is needed, but an EU Login account can be created in advance.
Users, voluntary reports and liability
You must also inform the impacted users, and where appropriate all users, of the vulnerability or incident and of mitigation steps they can take, where appropriate in a machine-readable format (Art. 14(8)); if you do not do so in time, the CSIRT may inform them itself. Anyone may report vulnerabilities, threats, incidents and near misses voluntarily (Art. 15), although ENISA says the SRP will support this only in a later phase. Notifying does not by itself expose the notifier to increased liability (Art. 17(4)). For how a security incident interacts with product liability and data protection, see our piece on incident response across the AI Act, KVKK and the new product liability rules.
Penalties and the Turkish angle
Breaches of Articles 13 and 14 can lead to administrative fines of up to EUR 15 million or, for an undertaking, 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher (Art. 64(2)). Member States set the detailed rules, and company size, including start-ups, is a factor (Art. 64(5)). Article 64(10)(a) states that administrative fines do not apply to manufacturers qualifying as micro or small enterprises for a failure to meet the 24-hour early warning deadline; it does not cover the 72-hour notification or the final report. As drafted, that derogation refers to the fines in paragraphs 3 to 9, while Article 14 breaches are fined under paragraph 2, so its exact reach may need clarification.
Turkish law does not change this picture. Türkiye’s Cybersecurity Law No. 7545 (Official Gazette of 19 March 2025, No. 32846) is a separate national regime, covered in our note on the Cybersecurity Presidency and the two-hour rule; complying with it does not satisfy the CRA, and vice versa. A single incident may also trigger the KVKK 72-hour breach notice, which our data-breach response plan covers.
Where to start
- Inventory: every app, game client, firmware, device and SDK available to EU users, including old versions, and the backends they need.
- Reporting country: run the Article 14(7) cascade, record the result, decide on an authorised representative.
- SRP access: personal EU Login accounts with MFA for at least two people, created before an incident.
- Triage rule: who decides that “reliable evidence” of exploitation exists, since awareness starts the clock.
- On-call: a 24/7 security, engineering and legal rota, covering weekends and Turkish holidays.
- Templates: early warning, 72-hour notification, final report and user notice, mapped to the SRP fields.
Our data protection and cybersecurity practice can turn this into a short internal procedure.
Does the CRA reporting duty apply to a pure SaaS product?
Generally not, if the service is not part of a product you ship; recital 12 notes that the NIS2 Directive applies to SaaS. But if your app cannot perform one of its functions without your backend, that backend is “remote data processing” and part of the product, and an exploited flaw in it is reportable.
We have no EU office or representative. Which CSIRT do we report to?
Under Article 14(7), the Member State of your authorised representative, then importer, then distributor (each judged by the highest number of your products), and finally the Member State with the highest number of your users, based on the information available to you.
Do we have to report vulnerabilities in versions released years ago?
Yes, if the product is in scope and you become aware of active exploitation on or after 11 September 2026. Article 69(3) applies Article 14 to products placed on the market before 11 December 2027.
Sources. Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 2024/2847, 20.11.2024: Arts. 2, 3(1), 3(2), 3(13), 3(42), 13(5), 14, 15, 17, 18, 24(3), 64, 69 and 71, recitals 11, 12, 18 and 68; European Commission, CRA reporting obligations and FAQs on the Cyber Resilience Act (v1.4, sections 1.2 and 5); ENISA, CRA Single Reporting Platform FAQ; Cybersecurity Law No. 7545, Official Gazette No. 32846, 19.03.2025.
This article is general information and not legal advice; a specific situation should be assessed with counsel.
Author
More from Vircon Insights
The EU AI Act in Turkish Law: A Concordance of Terms and Obligations for Providers and Deployers
October 11, 2026Technopark and R&D Centre Incentives for a Turkish Startup: Law 4691, Law 5746 and the Three Per Cent Venture Obligation
October 13, 2026How to Hold a Valid Board Meeting in a Turkish Company: Quorum, Circular Resolutions, Electronic Meetings and Void Decisions
October 11, 2026Can a Foreign Fund Invest Directly in a Turkish Company? The Closing Mechanics Nobody Explains to the Investor
October 10, 2026Trade Mark Strategy for a Turkish Startup: Classes, TÜRKPATENT, the EU and the Madrid Protocol
October 10, 2026The Turkish Equivalent Of…: A US–Türkiye Corporate Law Concordance for Founders, Investors and Counsel
October 9, 2026Related Practice Areas
IT Law
SaaS, software licensing, cloud services and IT contracts.
View service →Privacy & Cybersecurity
KVKK and GDPR compliance, breach response, cybersecurity governance.
View service →Gaming & Esports Law
Studio funding rounds, chain of title, publishing and platform agreements, esports.
View service →