Who Actually Has to Report Under Cyber Resilience Act Article 14 from 11 September 2026?

In one week, a European reporting duty switches on for software you shipped in 2019 and stopped thinking about in 2021.

Most of the Cyber Resilience Act does not apply until December 2027. One clause does not wait, and it reaches backwards into everything you have already sold.

The reporting clock has been covered to death. The harder question is the one almost nobody has answered: on 11 September, who is holding the obligation, and for which products.

Which CRA Is This? The Cyber Resilience Act, Not the Credit Rating Agencies Regulation

The Cyber Resilience Act is Regulation (EU) 2024/2847. If your search results are returning credit-rating supervision material, you have the wrong CRA.

Article 1 sets the subject matter: rules for making products with digital elements available on the market, essential cybersecurity requirements for their design and development, and requirements for manufacturers' vulnerability handling processes.

It is product law. The obligated person is an economic operator in a supply chain, not a supervised financial entity.

What Exactly Switches On on 11 September 2026, and What Stays Off Until December 2027?

Article 71(2) is short. The Regulation applies from 11 December 2027. However, Article 14 applies from 11 September 2026, and Chapter IV, Articles 35 to 51, from 11 June 2026.

So on 11 September the Regulation does not enter into application. Article 14 does.

The cadence, stated once. Article 14(2) requires an early warning within 24 hours of awareness, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. Article 14(4) mirrors the 24-hour and 72-hour steps for severe incidents, with a final report within one month. Both tracks go simultaneously to the CSIRT designated as coordinator and to ENISA.

What stays off until 11 December 2027: the essential cybersecurity requirements in Annex I, the Article 13 manufacturer duties including the cybersecurity risk assessment, technical documentation and the support period of at least five years, and conformity assessment and CE marking.

You can be obliged to report an actively exploited vulnerability next week in a product not yet required to meet a single Annex I requirement. That asymmetry is the whole story.

One caution on plumbing. Article 14 routes notifications through the single reporting platform that Article 16 requires ENISA to establish. Article 14(9) obliged the Commission to adopt delegated acts by 11 December 2025, and Article 14(10) permits implementing acts on notification formats. Build to the content fields Article 14 itself lists and treat the format as subject to change.

Is Your Product a 'Product With Digital Elements', and What Does Article 2 Carve Out?

Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.

Read the last clause twice. A component you ship separately is a product in its own right, with its own reporting surface. The SDK. The library. The firmware image.

Article 3(2) pulls your backend in. Remote data processing means processing at a distance for which the software is designed and developed by the manufacturer, or under its responsibility, and the absence of which would prevent the product from performing one of its functions. Your cloud service is part of the product, not adjacent to it.

Article 2(1) sets the connection test: the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

The Article 2 carve-outs are narrow: products covered by Regulation (EU) 2017/745 on medical devices, Regulation (EU) 2017/746 on in vitro diagnostics or Regulation (EU) 2019/2144; products certified under Regulation (EU) 2018/1139; equipment under Directive 2014/90/EU; identical spare parts made to the same specifications; and products developed or modified exclusively for national security or defence, or designed to process classified information.

Article 2(5) allows sectoral limitation, but only where the Commission adopts a delegated act saying so. Until one exists for your sector, you are in scope.

Are You a 'Manufacturer' Under Article 3(13) Even If You Give the Software Away?

Yes. Article 3(13) defines a manufacturer as a person 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.

Free of charge is written into the definition. Your community edition and your no-cost developer tier carry your trademark, so you are their manufacturer.

Two more routes catch people who never thought they were in the role. Article 21 makes an importer or distributor a manufacturer, subject to Articles 13 and 14, where it places a product under its own name or trademark, or substantially modifies a product already on the market. White-labelling moves the reporting duty to the label. Article 22 extends the same logic to anyone else carrying out a substantial modification, for the part affected, or for the whole product where the modification affects its cybersecurity as a whole.

Do Open-Source Software Stewards, Importers and Distributors Report Too?

Three different answers, and the differences are load-bearing.

Open-source software stewards. Article 3(14) defines one as a legal person, other than a manufacturer, whose purpose is systematically providing support on a sustained basis for the development of specific free and open-source products with digital elements intended for commercial activities, and that ensures the viability of those products. Foundations, in practice. Not an individual maintainer with a weekend project.

Article 24(3) is the provision to read closely. Article 14(1), the actively exploited vulnerability track, applies to stewards to the extent that they are involved in the development of the products. Article 14(3) and (8), the severe incident track and user notification, apply to the extent that severe incidents affect network and information systems provided by the steward for that development.

That second limb is narrower than most readers assume. It reaches the steward's own build and hosting infrastructure, not third-party downstream deployments.

Article 64(10) then provides that, by way of derogation from paragraphs 3 to 9, the administrative fines referred to in those paragraphs do not apply to any infringement by open-source software stewards, nor to microenterprises or small enterprises that miss the 24-hour deadline in Article 14(2)(a) or 14(4)(a). The obligation exists. The penalty framing differs.

Importers and distributors that do not rebrand. Not Article 14 filers. They carry a feeder duty instead. Article 19(5) requires an importer, on becoming aware of a vulnerability, to inform the manufacturer without undue delay, and where the product presents a significant cybersecurity risk to immediately inform the market surveillance authorities of the Member States where it was made available. Article 20(4) says the same for distributors.

That feeder duty is what product teams under-build. Your channel is a source of awareness, and awareness starts your clock. If a distributor emails a vulnerability report to a regional sales inbox, the clock is running and your PSIRT does not know it.

Does Article 14 Reach the Products You Shipped Years Ago? (Article 69(3))

This is the sentence that changes your inventory.

Article 69(2) sets the general transitional rule: products placed on the market before 11 December 2027 are subject to the requirements of the Regulation only if, from that date, they are subject to a substantial modification. That is the grandfathering everyone has planned around.

Article 69(3) removes Article 14 from it. By way of derogation from paragraph 2, the obligations laid down in Article 14 apply to all products with digital elements falling within the scope of the Regulation that have been placed on the market before 11 December 2027.

Read with Article 71(2), the effect is that you hold two different product inventories.

→ The Annex I inventory: what you place on the market from 11 December 2027, plus anything older you substantially modify. This drives CE marking, technical documentation and support periods.

→ The Article 14 inventory: everything in scope you have ever placed on the Union market. This drives reporting, and it goes live first.

The second list is longer, older and much worse maintained. Discontinued lines. Firmware in devices you stopped supporting three years ago. An OEM build shipped under a partner's hardware. A library version pinned by customers who never upgraded.

None of those carry an Annex I duty or a mandated support period until they are substantially modified. All of them are notifiable if you become aware of an actively exploited vulnerability in them. Awareness is the trigger, not the support commitment.

Which CSIRT Is Yours, and How Is 'Main Establishment' Determined?

Article 14(7) routes the notification on a criterion most companies have never computed.

Notifications go via the single reporting platform, using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment in the Union, and are simultaneously accessible to ENISA.

Main establishment has a bespoke meaning here. It is the Member State where the decisions related to the cybersecurity of the manufacturer's products with digital elements are predominantly taken. If that Member State cannot be determined, it is the one where the manufacturer has the establishment with the highest number of employees in the Union.

That is not your place of incorporation and not your GDPR main establishment. If your product security function makes its calls out of Dublin while the legal entity sits in Luxembourg, the routing follows the decisions.

Where a manufacturer has no main establishment in the Union, Article 14(7) sets a four-step cascade, applied in order and on the basis of information available to the manufacturer:

→ (a) the Member State where the authorised representative acting for the highest number of your products is established → (b) failing that, the Member State of the importer placing the highest number of your products on the market → (c) failing that, the Member State of the distributor making available the highest number of your products → (d) failing that, the Member State where the highest number of your users are located

Where you land on (d), you may send notifications about later vulnerabilities and incidents to the same CSIRT you first reported to. That stickiness attaches to the (d) branch only.

Notice what (b) and (c) demand: a per-product count of units, broken down by importer and distributor Member State, available at three in the morning on a Sunday. Most non-EU manufacturers cannot produce that today. Determine the routing in advance and record the basis.

What Trips the Clock: An 'Actively Exploited Vulnerability' or a 'Severe Incident'?

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

Compare Article 3(41), an exploitable vulnerability: one with the potential to be effectively used by an adversary under practical operational conditions. Only the first triggers Article 14(1).

A published proof of concept is not a trigger. A high CVSS score is not a trigger. Reliable evidence of exploitation in a system, without the owner's permission, is. And the text says "in a system", not "in a customer's system".

The severe incident test sits in Article 14(5). An incident is severe where it negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems.

"Is capable of" does the heavy lifting. Capability, not realised harm. A severity rubric that grades only actual impact will under-report by design.

Anything below the threshold has a home in Article 15 voluntary reporting, which Article 15(5) protects: it shall not result in additional obligations that would not otherwise have applied. Article 14(8) separately requires you to inform impacted users, and where appropriate all users, of the mitigations they can deploy.

The stakes sit in Article 64(2). Non-compliance with Articles 13 and 14 attracts administrative fines of up to EUR 15 000 000 or, for an undertaking, up to 2.5 % of total worldwide annual turnover, whichever is higher.

Where This Leaves You

Three determinations, none of them drafting exercises.

→ Your Article 14 product inventory, which under Article 69(3) is everything you have ever placed on the Union market, not your CE-marking roadmap → Your CSIRT designated as coordinator, derived from Article 14(7) and documented before you need it → Your awareness intake, wide enough to catch a distributor's email and a steward's disclosure

Scoping is where compliance teams lose their first quarter. Aigis GRC answers it as structured data: one organizational profile, deterministic mapping against 245+ regulations across 28 jurisdictions, every obligation traced to a verbatim quote from the source legal text with article-level citation.

See how the obligation model works on the platform, how reporting triggers bind to your risk register, and where the Article 19 and 20 feeder duties land in third-party risk.

Answer once. Assess everything. Start at agrc.ai.

FAQ: Article 14 Scope Questions Product and Compliance Teams Keep Asking

Does the whole Cyber Resilience Act apply from 11 September 2026? No. Article 71(2) provides that the Regulation applies from 11 December 2027, with Article 14 applying from 11 September 2026 and Chapter IV, Articles 35 to 51, from 11 June 2026. Only the Article 14 reporting obligations switch on in September.

Do I have to report vulnerabilities in products I sold years ago? Yes, where they are in scope. Article 69(2) would otherwise grandfather products placed on the market before 11 December 2027, but Article 69(3) derogates from that and applies the Article 14 obligations to all in-scope products placed on the market before that date.

Is an open-source software steward really caught by Article 14? Partly. Article 24(3) applies Article 14(1) to stewards to the extent they are involved in the development of the product, and applies Article 14(3) and (8) to the extent severe incidents affect network and information systems the steward provides for that development. Article 64(10) disapplies the administrative fines referred to in Article 64(3) to (9) to infringements by stewards.

Which CSIRT do I notify if my company has no EU establishment? Article 14(7) sets an ordered cascade based on information available to you: the Member State of the authorised representative covering the highest number of your products, then the importer, then the distributor, then the Member State with the highest number of your users. If you land on the final step, you may keep reporting to that same CSIRT designated as coordinator thereafter.