CRA reporting obligations: what to ask your software suppliers

Since 11 September 2026, the reporting obligations in Article 14 of the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, have required manufacturers of software and connected products placed on the EU market to report actively exploited vulnerabilities and severe incidents. They file through the Single Reporting Platform that ENISA launched the same day, for products already on the market too, including those Swiss vendors sell into the EU. The legal deadlines run to national CSIRTs and ENISA, not to customers, so buyers still have to agree with each supplier how fast they hear about a flaw and who installs the fix.

This post covers the duty and its gaps, open source, the Swiss angle, supplier questions and a timetable.

What the CRA reporting obligations require

The CRA reporting duty is decided law: Article 71(2) applies the Regulation from 11 December 2027 but brings Article 14 forward to 11 September 2026.

Who reports. The manufacturer: whoever develops a product with digital elements, or has it developed, and markets it under its own name or trademark (Article 3(13)).

What is reported. An actively exploited vulnerability, one with “reliable evidence that a malicious actor has exploited it in a system without permission of the system owner” (Article 3(42)). And a severe incident: one that harms or could harm the product’s protection of sensitive or important data or functions, or has brought or could bring malicious code into it or a user’s systems (Article 14(5)).

When.

Step	Actively exploited vulnerability	Severe incident
Early warning	24 hours from awareness	24 hours from awareness
Notification	72 hours from awareness	72 hours from awareness
Final report	14 days after a corrective or mitigating measure is available	One month after the 72-hour notification

The first two deadlines read “without undue delay and in any event within” the stated time, so the hours are a ceiling, not a target.

How. Through ENISA’s Single Reporting Platform to the CSIRT designated as coordinator, with ENISA normally notified at the same time (Article 14(1)). As of 6 October 2026, ENISA’s FAQ, updated on 3 October 2026, says the platform launched with no API and in English only, requires EU Login with multi-factor authentication, and takes no voluntary reports yet.

The Commission’s non-binding guidance C(2026) 5252, published on 27 July 2026, starts the clock once an initial assessment gives a reasonable degree of certainty of exploitation or a severe incident (paragraph 213), and rules out retroactive reports of exploitation known before 11 September 2026 (paragraph 217).

Article 64(2) sets fines for breaches of Article 14 of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, under rules each Member State lays down. Article 71(2) does not bring Article 64 forward, and the Commission’s FAQ says the enforcement provisions apply from 11 December 2027.

Does CRA reporting cover software you bought years ago?

Yes. Article 69(3) applies Article 14 to all in-scope products, including those “placed on the market before 11 December 2027”. The CRA’s other requirements reach them only if substantially modified from that date (Article 69(2)).

Reporting also outlives support. The guidance (paragraph 210) says that for products placed on the market before 11 December 2027, or whose support period has ended, the manufacturer must still notify but need not meet the vulnerability handling obligations of Annex I Part II. The Commission’s CRA FAQ (version 1.4 of 4 September 2026, entry 5.3) says the same of the first group. Both are non-binding.

That reaches beyond old versions: no product placed on the market before 11 December 2027, which today means every in-scope product you run, carries a CRA duty on its vendor to ship a fix unless substantially modified from that date. The duty to patch comes from your contract, and each version’s end-of-support date is a procurement fact, not a detail.

Does the CRA make suppliers tell their customers?

Not on a fixed clock. The deadlines above are owed to the CSIRT and ENISA.

Customers get Article 14(8): the manufacturer must inform impacted users, and where appropriate all users, with the measures they can take, “where appropriate in a structured, machine-readable format”. No hour deadline is set; if users are not informed “in a timely manner”, the CSIRTs may inform them. The guidance lets manufacturers “limit the disclosure of detailed information to the relevant users or customers concerned” (paragraph 220), so make sure your contacts are on the supplier’s file.

Installing the fix stays with you. “The manufacturer is not responsible under the CRA if the user does not install security updates”, says the Commission FAQ.

More applies from 11 December 2027, decided but not yet applicable, and only to products placed on the market or substantially modified from that date: a software bill of materials (SBOM), security updates “without delay” and free of charge (unless agreed otherwise for a tailor-made product), a coordinated vulnerability disclosure policy (Annex I Part II), a single point of contact for users and a support period of at least five years unless expected use is shorter (Article 13). All of it can go into contracts now.

Who reports for open-source software?

When the upstream is a manufacturer

Under recital 18, free and open-source software that its manufacturer does not monetise is out of scope. The guidance treats a free download with optional paid services as not placed on the market (paragraphs 56 and 57), and a free community edition and a paid edition of the same code as different products (paragraphs 52, 53 and 76). The paid edition is placed on the market, and its maker is a manufacturer bound by Article 14 since 11 September 2026. For the community edition, a publisher that is a legal person is treated as a steward, with narrower reporting only from 11 December 2027. On that reading, if you run a community edition, the manufacturer’s reporting and user-information duties attach to the paid edition, and your signal is the project’s own advisories.

When the upstream is a steward

A steward is a legal person, other than a manufacturer, that systematically supports free and open-source software intended for commercial activities (Article 3(14)). From 11 December 2027, it reports exploited vulnerabilities only to the extent it is involved in development, and severe incidents only on the development systems it provides (Article 24(3)).

When your organisation is the manufacturer

If you place a product built on open-source components on the EU market under your own name or trademark, and charge for it or otherwise monetise it, you are its manufacturer. An actively exploited vulnerability in an integrated component is yours to notify, and also its manufacturer’s if the component was placed on the market; one that cannot be exploited in your product is not reportable for it (Commission FAQ). A product made only for your own use is not placed on the market. From 11 December 2027, Articles 13(5) and 13(6) add due diligence on components and upstream reporting of their flaws.

Open source is easier to watch, if someone watches it

None of this makes open source the riskier choice. A proprietary vendor’s advisory reaches you when the vendor publishes it. An open-source project’s patched release is public, usually with its advisory and the change itself, so anyone can check which versions are affected and what the fix does.

What the CRA does not give a community edition is someone obliged to watch those signals for you. That is an operating task, not a licence question: track each project’s advisories against the versions you run, plan the fix with a backup and a rollback, and keep a record of who approved what. Run that way, an open-source app gives you more evidence about its security than most closed products.

What the CRA means for Swiss vendors and buyers

The CRA does not apply in Switzerland as such, but it binds Swiss manufacturers for products they make available on the EU market. Without an EU main establishment, they report to the coordinating CSIRT of the Member State of their authorised representative, importer or distributor, in that order, or else where most users are (Article 14(7)). Swiss buyers should ask whether a product is also made available in the EU, and whether Article 14(8) notices reach them.

A Swiss counterpart is announced, not enacted. On 25 September 2026, the Federal Council instructed the DDPS to draw up, by June 2027, a consultation draft for a federal Cybersecurity Act modelled on the CRA, covering the cyber resilience of products with digital elements (Motion 24.3810) and hosting and cloud providers (Motion 25.3011).

Questions to put to software suppliers and managed operators

Software suppliers

• Are you the manufacturer under the CRA, and which entity files? Outside the EU, ask for the authorised representative and the coordinating CSIRT (Article 14(7)).
• How, and how fast, will you tell us? Named recipients, channel, machine-readable advisories, and the same notice outside the EU. The law sets no hour deadline, so the contract should.
• When does support end for the version we run? After it, in the Commission’s reading, the CRA requires reports but no vulnerability handling.
• Which open-source components do you integrate, and can you share an SBOM? From 11 December 2027, manufacturers must draw up an SBOM for new products, but sharing it with users is their choice (Annex II, point 9), so ask for it in the contract, and ask how upstream fixes are tracked.
• Where are your disclosure policy and security contact? Both are required for new products from 11 December 2027.

Managed operators and hosting providers

In the guidance’s reading, a service provider that installs open-source software on a customer’s server without substantially modifying it does not place it on the market (Example 19). Recital 12 leaves cloud services designed outside a manufacturer’s responsibility out of the CRA, unlike a product’s remote data processing solution, and puts SaaS, PaaS and IaaS under the NIS2 Directive when their provider is at least medium-sized. So ask an operator how advisories become changes.

• Which advisories do you track for our apps, and from where?
• How long from an upstream fix to a plan, and from approval to deployment? Ask who approves an emergency change and what the rollback is.
• How do you notify us of an incident, and under which contract term? NIS2 may apply to the operator, to you, or to both (NIS2 and DORA).
• What record do we get? Advisory, plan, approval and deployment, readable by your auditors.

What to do, and by when

Legal dates come from the CRA; the others are our suggested timetable.

1. Since 11 September 2026, if you place a product on the EU market under your own name: register on the platform, name a primary assigned representative, determine your coordinating CSIRT and rehearse a 24-hour early warning.
2. By 30 November 2026: map your products and their makers. Record each product’s version, edition (community or paid), maker and role (manufacturer, steward or neither), support status and advisory channel, and subscribe to it.
3. By 31 December 2026: send the supplier questions and set your own patch target. Send them to your most critical suppliers and file the answers; decide how fast you patch actively exploited vulnerabilities, who approves emergency changes, and who watches the advisories of each open-source project you run.
4. At every renewal and tender: write it into the contract. A named contact for Article 14(8) notices, a notice time in hours, machine-readable advisories, the support end date, an SBOM on request from 11 December 2027, and notice if the supplier’s CRA role changes.
5. From June 2027: follow the Swiss consultation (the draft is due to the Federal Council by then) and answer it if you build or sell products in Switzerland.
6. Before 11 December 2027: prepare for full application, including SBOMs, disclosure policies, support periods and CE marking for new products.

How Pilae fits

The CRA puts a legal clock on vendors. For the open-source apps you run, Pilae puts a contractual one on the operator. We operate open-source and source-available apps on your premises or on dedicated machines in Pilae Cloud in Switzerland and the EU, and watching upstream is part of the service, whichever edition you run.

• Every advisory, matched to your versions. Upstream advisories for every app you run are tracked against your versions, and a fix is planned as soon as it is published.
• Critical fixes within hours. The Pilae Agent writes the plan with a verified backup and a rollback and puts a critical fix on your desk within hours. It is applied in your agreed window, or at once if you approve an emergency change.
• A record your auditors can read. Advisory, plan, approval and result are kept in the console and exportable to your SIEM.
• Roles in writing. Under managed operations, your contract’s responsibility matrix says who plans, approves and applies. A flaw in an app belongs with its upstream project: we help coordinate and protect our customers meanwhile (disclosure policy).
• No lock-in. Every plan includes a written exit plan, with your data back in open formats.

That answers the operator questions above in writing, before you sign. If you are weighing a proprietary product against an open-source one and the CRA is part of the question, talk to an engineer: we go through the apps you run and what operating them properly would involve.

This post is general information, not legal advice. For the official text, read Regulation (EU) 2024/2847 on EUR-Lex.