Guide

Cyber Resilience Act reporting obligations for software and SaaS manufacturers

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

Since 11 September 2026, Article 14 of the Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, a notification within 72 hours, and a final report after that. Reports go through ENISA's Single Reporting Platform and reach ENISA and the coordinating CSIRT of the member state where the manufacturer has its main establishment at the same time; in Germany that is CERT-Bund at the BSI. The obligation also covers products already on the market. The rest of the CRA applies from 11 December 2027.

The timeline to December 2027

The Cyber Resilience Act is Regulation (EU) 2024/2847. It applies directly in every member state and becomes applicable in stages.

One point matters for existing products. Products placed on the market before 11 December 2027 are only subject to the other requirements if they undergo a substantial modification after that date (Article 69(2)). The reporting obligation in Article 14 applies to them regardless (Article 69(3)), and according to the Commission's guidance even after the support period ends. There is no retroactive reporting. But if you only learn of exploitation after 11 September 2026, even of an older vulnerability, the obligation applies.

Who counts as a manufacturer

Under Article 3(13), a manufacturer is anyone who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its own name or trademark, whether for payment, monetisation or free of charge. A product with digital elements is a software or hardware product together with its remote data processing solutions, including components placed on the market separately (Article 3(1)).

Such products are in scope if their intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1)). For software, that can mean apps, desktop programs, agents, command-line tools, libraries and SDKs you supply commercially.

Exclusions include medical devices, certain vehicle, aviation and marine equipment, and products developed exclusively for national security or defence (Article 2). Free and open-source software has special rules, which we leave aside here.

Does SaaS fall under the CRA?

The short answer: a pure SaaS application that your customers use exclusively in a browser is not, on its own, a product with digital elements. It can, however, be part of a product, and many SaaS vendors also ship software.

The key is the concept of remote data processing in Article 3(2): data processing at a distance for which the software is designed and developed by the manufacturer, or under its responsibility, and without which the product could not perform one of its functions. Recital 12 makes clear that cloud solutions are only covered if they meet this definition, and that cloud services such as SaaS, PaaS and IaaS fall under the NIS2 Directive.

On 27 July 2026, the Commission published guidance on applying the CRA (C(2026) 5252). It is not binding, but it sets out the Commission's reading: software executed remotely and merely accessed by the user is not, on that basis alone, a product with digital elements. That is typically the case for web applications and progressive web apps used exclusively in a browser. A locally installed client, by contrast, is a product. If that client relies on a backend that meets the definition of remote data processing, the backend is part of the product.

Two questions for your backend

According to the guidance, a backend only counts as remote data processing under the CRA if the answer to both questions is yes:

• Would a function of the product fail without this processing? Not only core functions count. The guidance mentions file synchronisation, configuration, update distribution, and identity and access management, among others. Purely statistical telemetry does not count.
• Was the software developed by you or under your responsibility? In-house or contracted development to your specifications: yes. A third-party SaaS service you merely license: no. Treat it like a component, with a risk assessment and due diligence.

Classification is case by case; record the outcome for each product with reasons. Borderline cases belong with your legal counsel, and only the Court of Justice of the EU can interpret the CRA with binding effect.

What has to be reported

Actively exploited vulnerabilities

A vulnerability is actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission (Article 3(42)). According to the BSI, a published exploit, proof-of-concept code or port scans are not enough. A vulnerability that is exploitable but has not been exploited does not trigger the obligation.

For vulnerabilities in third-party components, the guidance says: if the vulnerability is actively exploited in your product, you report it. If the vulnerable code is not reachable in your product, or has not been exploited there, there is no obligation to report. You can still report voluntarily (Article 15), and you must pass the vulnerability on to whoever manufactures or maintains the component (Article 13(6)).

Severe incidents

Under Article 14(5), an incident affecting the security of the product 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
• has led, or is capable of leading, to the introduction or execution of malicious code in the product or in a user's systems.

One example is a compromised build or update pipeline. According to the BSI, a ransomware attack on your office IT is not automatically a severe incident under the CRA. What matters is whether the security of the product is affected.

When the clock starts

The deadlines run from the moment you become aware. According to the Commission's guidance, that is when a prompt initial assessment gives you a reasonable degree of certainty that active exploitation or a severe incident has occurred. So the initial assessment must not be left waiting.

The deadlines at a glance

The CSIRT may ask for an intermediate status report (Article 14(6)). You must also inform affected users and, where appropriate, all users about the vulnerability or incident and the measures they can take themselves, where appropriate in a structured, machine-readable format (Article 14(8)).

Under Article 64(2), breaches of Articles 13 and 14 can be fined up to EUR 15 million or up to 2.5% of worldwide annual turnover, whichever is higher. Under Article 64(10), micro and small enterprises cannot be fined for missing the 24-hour early warning. All other deadlines still apply to them.

The reporting channel: ENISA's platform and the BSI

Reports are filed exclusively through the Single Reporting Platform (CRA-SRP) operated by ENISA. Since 11 September 2026, mandatory notifications must be submitted there. You report once, and the CSIRT and ENISA see it at the same time.

• Competent CSIRT. What counts is the member state of your main establishment, where cybersecurity decisions about your products are predominantly taken, or failing that the establishment with the most employees (Article 14(7)). Manufacturers without an EU establishment follow a fixed order.
• Germany. The coordinating CSIRT is CERT-Bund at the BSI. In mid-October 2026 the Bundestag passed the CRA implementation act, which according to the BSI also makes the BSI the market surveillance authority.
• Access. According to the BSI, advance registration is not mandatory, but you need an EU Login account. Reports are submitted by a named Assigned Representative, primary and secondary.
• Language. The BSI asks for reports to be written in English.

Reporting as such does not expose you to increased liability (Article 17(4)). If a vulnerability is particularly sensitive, for example because no update exists yet, you can say so, and the CSIRT can delay further dissemination for the time strictly necessary (Article 16(2)). The CSIRTs offer helpdesk support on the reporting obligations, in particular for SMEs (Article 17(6)).

How the CRA relates to NIS2

NIS2 and the CRA regulate different things. NIS2 covers the cybersecurity of entities, meaning your organisation and its network and information systems. That includes cloud service providers from medium size upwards. The CRA covers the security of products. We explain whether NIS2 applies to you in a separate article.

Both can apply at once, for example to a software vendor that is an entity under NIS2 and whose product is affected by an incident. According to the BSI, such an incident must then be reported twice: under NIS2 via the BSI portal and under the CRA via the CRA-SRP. Each report can reference the other; a simplification via the so-called Digital Omnibus is so far only a proposal. The deadlines are similar, the triggers are not: a significant incident under NIS2, an actively exploited vulnerability or severe product incident under the CRA.

What to prepare now

The eight steps below build the process in advance. Some become mandatory in December 2027 anyway, but they already help you recognise a reportable event in time.

1. Determine scope. List every product and version in the EU with its CRA classification and reasoning, using the two questions for SaaS. Record your main establishment under Article 14(7).
2. Assign roles. Who decides whether an event is reportable? Who are the primary and secondary representatives on the platform? Deadlines run over weekends too, so put deputies and availability in writing. Set up the EU Login account before you need it.
3. Reporting workflow and templates. A short decision tree and English text blocks for all three reporting stages. Record when and why you became aware.
4. Coordinated vulnerability disclosure policy. The CRA requires a policy on coordinated vulnerability disclosure (Article 13(8) and Annex I, Part II, point 5). It sets out how outsiders report findings, how you respond and when you publish. ISO/IEC 29147 and 30111 provide orientation.
5. Contact point for vulnerabilities. An easy-to-find contact address for reports (Annex I, Part II, point 6) and a single point of contact that must not rely solely on automated tools (Article 13(17)). A security.txt on your website also makes the address machine-discoverable.
6. SBOM. A software bill of materials in a commonly used, machine-readable format that covers at least the top-level dependencies (Annex I, Part II, point 1). Without one, you can hardly tell within 24 hours whether an exploited flaw in a library affects your product. The BSI's non-binding technical guideline TR-03183-2 describes SBOM requirements, with a mapping to SPDX and CycloneDX.
7. Vulnerability management and testing. Remediate vulnerabilities without delay, ship security updates separately from feature updates where technically feasible, and test the security of the product effectively and regularly (Annex I, Part II, points 2, 3 and 7). From December 2027, a support period of generally at least five years applies (Article 13(8)).
8. Rehearse. Run the workflow once with a realistic scenario and a stopwatch, from suspicion to user notice.

The checklist

How we can help

Legal interpretation is a matter for your legal counsel. For two building blocks, we can provide technical support within a scope agreed in writing.

More: SaaS penetration testing, compliance readiness, NIS2 readiness, vulnerability assessment and the penetration testing process.

Frequently asked questions

Sources

• EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
• European Commission: Guidance on the application of the CRA, C(2026) 5252, 27 July 2026
• European Commission: Cyber Resilience Act, Reporting obligations
• European Commission: Cyber Resilience Act, Summary of the legislative text
• ENISA: CRA Single Reporting Platform
• ENISA: List of CSIRTs designated as coordinators
• BSI: CRA Single Reporting Platform (German)
• BSI: CRA implementation act passed (German)
• BSI: TR-03183 Cyber Resilience Requirements for Manufacturers and Products
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)