CRA 1/5: The First CRA Obligation Doesn’t Take Effect in 2027 — It Takes Effect on September 11, 2026

Looking at the CRA’s reporting obligations first makes sense, because they create the earliest and most immediate pressure to act. Before the details set out in Article 14 of the CRA, however, comes the classification: who is affected, what falls under the CRA, and what applies when?

In plain terms: who is affected and what falls under the CRA?

The CRA hinges on a single, deliberately broad term: the product with digital elements (abbreviated PwDE).

A PwDE is any software or hardware product whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (see Art. 2(1)).

This covers physical connections via interfaces, cables, or radio waves as well as logical connections via software interfaces.

The scope chosen here is intentional: smartphones, laptops, routers, firewalls, industrial control systems, smart home devices, IoT sensors, operating systems, password managers, antivirus software — all of these are PwDE within the meaning of the CRA. The short rule of thumb behind it: as soon as a product processes data and can connect — directly or indirectly — to a device or network, it is, in case of doubt, a PwDE.

But software provided free of charge with a commercial background also falls under it, such as a free app for a paid cloud service (see Art. 3(22)). A zero price for the user is not an exclusion criterion; what always matters is the commercial context.

The PwDE concept also includes Remote Data Processing Solutions (RDPS). This means software developed by the manufacturer and operated remotely, without which the product could not perform one of its core functions. A mobile app that necessarily needs a manufacturer-owned cloud backend to perform its core function is therefore classified as a PwDE, including the backend service as an RDPS.

The line here runs cleanly and is practically relevant: a pure SaaS service without a local client does not fall within the CRA scope, but may instead fall under NIS2. Anyone who does not draw this distinction early assigns products to the wrong regime (and the wrong reporting chain — more on that later).

CRA exemptions: what does the CRA explicitly carve out?

The CRA carves out product categories that are already covered by sector-specific EU regulation. These currently include:

• Medical devices under Regulation (EU) 2017/745 and in vitro diagnostics under (EU) 2017/746
• Motor vehicles and their systems under Regulation (EU) 2019/2144 (those in the know are aware that UN R155 and ISO/SAE 21434 apply here)
• Aviation products certified under Regulation (EU) 2018/1139
• Marine equipment under Directive 2014/90/EU
• Spare parts that replace identical components
• Products for national security or defense, as well as products for processing classified information
• Free and Open Source Software (FOSS) that is not supplied in the course of a commercial activity — that is, purely non-commercial open-source projects with no monetization intent

This may sound clearly worded at first, but it brings gray zones in practice.

With FOSS in particular, the distinction is not trivial: an open-source library integrated into a commercial product does not itself fall under the CRA. The due diligence for the integrated components, however, lies with the manufacturer of the final product. (More on this in Article 4 of this series.)

Economic operators from the CRA’s perspective: not only manufacturers are affected

A persistent misconception: the CRA does not address only the manufacturer in the classical sense. The regulation recognizes four categories of economic operators, each carrying its own obligations:

• Manufacturer (Art. 3(13)) is anyone who develops or has PwDE developed and markets them under their own name or trademark — whether for payment or free of charge. Important: this includes white-label models, where one company sells another’s products under its own name.
• Authorized representative (Art. 3(15)) is an EU-based proxy appointed in writing by the manufacturer. This role steps in above all when the manufacturer itself is not based in the EU: the authorized representative is then reachable for the authorities, keeps the technical documentation on hand, and handles correspondence with the market surveillance authorities (see Art. 18). The actual work on the product, however, stays with the manufacturer. Conformity assessment, security updates, and all other core obligations cannot be handed off; the authorized representative is the manufacturer’s local proxy, not their substitute.
• Importers (Art. 3(16)) are EU-based companies that bring a product from a manufacturer established outside the EU into the EU market. Their obligations reach far: before placing on the market, they must ensure that the manufacturer has carried out the conformity assessment, that the CE marking is present, and that the technical documentation is available (Art. 19).
• Distributors (Art. 3(17)) are all further links in the supply chain that make a product available without altering its properties — classic resellers and distributors. They too carry due diligence obligations and must check, before onward distribution, whether the CE marking and required documentation are present (Art. 20).

The decisive special rule is in Art. 21 CRA: anyone who places a product on the market under their own name or trademark, or substantially modifies a product already placed, is automatically deemed a manufacturer — regardless of their actual role in the supply chain. In practice, this often hits importers and distributors who rebrand or modify. The consequence is all-encompassing: manufacturer obligations, including the reporting obligations under Art. 14.

The CRA is therefore not a pure manufacturer regulation, but a supply chain regulation.

Anyone who imports products from third countries and resells them carries, as an importer, considerable shared responsibility for conformity — and cannot rely on the manufacturer alone.

Product classification in the Cyber Resilience Act: four categories, different conformity obligations

The CRA divides PwDE into four categories — this concerns only the type of conformity assessment, not the scope of the substantive CRA obligations, which apply to all classes. For the reporting obligations under Art. 14, this classification is irrelevant anyway; for the rest of the series, it matters all the more.

• The default category covers roughly 90% of all PwDE: all products without an explicit classification as important or critical. Things like smart TVs, network printers, Bluetooth speakers, media player software. Here, self-assessment by the manufacturer suffices (Module A).
• The “Important products, Class I” category (see Annex III) covers PwDE that carry an elevated cybersecurity risk: identity management systems, browsers, password managers, antivirus software, VPN products, network management systems, operating systems, routers, modems, switches, microprocessors with security-related functions, as well as smart home products with security functions and connected toys. For Class I, self-assessment against harmonized standards is generally also possible — prospectively via EN 40000 (in particular EN 40000-1-4), once referenced in the EU Official Journal. Without such standards, third-party assessment becomes due.
• The “Important products, Class II” category (see Annex III) specifically refers to hypervisors, container runtime systems, firewalls, intrusion detection and prevention systems, as well as tamper-resistant microprocessors and microcontrollers. These always require third-party assessment by a notified body, regardless of standards application.
• The “Critical products” category (see Annex IV) covers hardware security modules, smart meter gateways, and smart cards/security elements. These require certification under a European cybersecurity certification scheme, such as the EUCC (European Common Criteria-based Cybersecurity Certification Scheme).

For the record: the Cyber Resilience Act timeline and three dates that count

The CRA entered into force on December 10, 2024, but is not yet mandatory in full breadth. Three dates structure the transition:

• June 11, 2026: The notification procedure for conformity assessment bodies (Chapter IV, Art. 35–51) applies. From here, notified bodies can be engaged for third-party assessments.
• September 11, 2026: The reporting obligations under Art. 14 apply. For all PwDE in scope, including existing products (see Art. 69(3)). This is the focus of this article — more on that shortly.
• December 11, 2027: All CRA requirements apply in full. From this date, only conforming products bearing the CE marking may be made available on the EU market.

An important point lies in Art. 69(3): products placed on the market before December 11, 2027, are generally subject to the remaining CRA requirements only if they are substantially modified after that date. The reporting obligations under Art. 14, by contrast, apply without exception to all products in scope, including legacy products already in the field today. It is precisely this distinction that many manufacturers are unaware of.

The support period in the CRA, and why the reporting obligation does not end at the point of sale

The reporting obligations described in more detail below do not run until the next release, but across the product’s entire support period. This is at least five years, unless the expected use time is shorter (see Art. 13(8)).

For products that experience shows to be long-lived (industrial control systems, network infrastructure, operating systems, and others), it must be set correspondingly longer.

Concretely, this means: anyone bringing a product to market today must, for at least five years, be able to detect, assess, and — where the criteria are met — report vulnerabilities and security incidents.

The reporting obligation in the Cyber Resilience Act is therefore not a one-off compliance act, but an ongoing operational process.

A brief look at the ever-dramatically-staged CRA fines

It is worth being clear, with September 11, 2026, in view: violations of the reporting obligations under Art. 14 fall under the CRA’s highest fine tier (see Art. 64(2)): fines of up to EUR 15,000,000 or, for companies, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.

This is the same sanction level as for violations of the essential cybersecurity requirements in Annex I. To be noted: a reporting failure is therefore treated, in regulatory terms, on a par with placing an insecure product on the market.

A narrowly drawn exception applies to micro and small enterprises (see Art. 64(10)): they are exempt from fines specifically for non-compliance with the 24-hour early warning deadline (see Art. 14(2)(a) and Art. 14(4)(a)). But solely for this one deadline — not for the reporting obligation as a whole, not for the 72-hour deadline, not for the final report. For open-source software stewards, fines under the aforementioned paragraphs are waived for violations of the regulation as a whole (see Art. 64(10)(b) CRA).

What cannot, of course, be reliably predicted at present: whether market surveillance authorities will impose maximum fines immediately from September 2026 is open.

But: experience from the introduction of the EU General Data Protection Regulation (GDPR) suggests that authorities first build capacity and act on a case-by-case basis. The substantive liability to fines, however, exists from day one.

The Article 14 reporting process in the Cyber Resilience Act in detail

Article 14 defines two independent triggers. Separating them precisely is decisive, because in practice there is considerable uncertainty about what actually has to be reported.

• Trigger 1: Actively exploited vulnerabilities (see Art. 14(1)). A vulnerability is reportable if it is actively exploited. That is, if reliable evidence exists that a malicious actor has exploited it in a real system without the system owner’s consent (Art. 3(42)). The key words are “actively” and “malicious”: the mere existence of a known but unexploited vulnerability (a CVE without known exploitation) therefore does not trigger a reporting obligation.
• Trigger 2: Severe security incidents (see Art. 14(3)). An incident is severe if it negatively affects, or can affect, 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 can lead, to the introduction or execution of malicious code in a product or in a user’s network/information system (see Art. 14(5)).

Below is an initial practical decision aid for when to report or not to report:

The CRA reporting obligation in detail: three key deadlines after becoming aware

The CRA’s reporting obligation is structured in three stages with hard deadlines. All deadlines start when the manufacturer becomes aware. Not when the incident occurs, not when the CVE is entered into a database, not when an internal escalation happens.

• Stage 1: Early warning — within 24 hours. Without undue delay, at the latest 24 hours after becoming aware. For vulnerabilities: an indication of the actively exploited vulnerability and, where known, the member states in which the product was made available. For severe incidents: at least a statement of whether unlawful or malicious action is suspected. The deadline is deliberately low-threshold. It is not about a finished analysis, but about the first signal to the authorities that something has happened.
• Stage 2: Detailed notification — within 72 hours. Where not already included in the early warning: general information on the affected product, the nature of the exploitation and of the vulnerability or incident, corrective or mitigating measures already taken, as well as recommended actions for users. Additionally, the manufacturer’s assessment of how sensitive the reported information is.
• Stage 3: Final report. For actively exploited vulnerabilities, at the latest 14 days after a corrective or mitigating measure becomes available; for severe incidents, one month after the detailed notification. Content: a full description of the vulnerability or incident, including severity and impact, information on any malicious actors involved where applicable, as well as details of the corrective measure provided.

A concrete example of the CRA reporting obligation: “the Monday-morning incident”

A customer reports on Monday at 9:15 a.m. that their device is being actively attacked and that an attacker has evidently gained access to the configuration interface. From this moment, the clock is running:

• By Tuesday 9:15 a.m.: early warning to the CSIRT* and ENISA — “We are aware of an actively exploited vulnerability in Product X, which to our knowledge is made available in Germany and Austria.”
• By Thursday 9:15 a.m.: detailed notification — product version, nature of the exploitation (e.g., authentication bypass via API interface), measures already taken (e.g., temporary shutdown of the affected interface), recommended action for users.
• By 14 days after patch availability: final report — full CVE description, severity (e.g., CVSS score), information on the attacker (where known), patch details.

What the example shows: a scenario like this does not require a 24/7 on-call service in the classical sense. But it does require a defined escalation path that holds up outside office hours as well.

• Who decides whether a reported incident triggers the reporting obligation?
• Who has the authority and the information to draft the early warning?
• Who reports to ENISA, and through which channel?

These questions have to be answered and documented before September 2026. Not once things are on fire, because by then it will likely be tight.

*What is the CSIRT? A CSIRT (or Computer Security Incident Response Team) is a specialized organizational unit responsible for the detection, analysis, and coordination of the response to cybersecurity incidents. In the CRA context, the term is more precisely framed: the CRA always refers to “CSIRTs designated as coordinators” — national CSIRTs explicitly designated by the member states as coordinators for the coordinated disclosure of vulnerabilities.

The reporting route in the Cyber Resilience Act: report once (centrally)

Reports under Art. 14 do not go to each national authority individually. The CRA provides for a Single Reporting Platform (SRP) at ENISA (see Art. 16) to serve as the central electronic entry point. From there, ENISA automatically forwards the report to the competent national CSIRT designated as coordinator.

The SRP is meant to go into operation on schedule by September 11, 2026. Manufacturers should register in advance and test technical access. Here too, the 24-hour deadline does not wait for onboarding.

Which CSIRT is competent?

Competence is determined by the manufacturer’s main establishment in the EU — that is, the member state in which the decisions on the products’ cybersecurity are predominantly taken (see Art. 14(7)). For Germany, the competent CSIRT is the BSI-CERT of the Federal Office for Information Security (BSI for short).

For manufacturers without a main establishment in the EU, an order of precedence applies (see Art. 14(7)):

1. Member state of the authorized representative acting for the most of the manufacturer’s products
2. Member state of the importer with the most of the manufacturer’s products
3. Member state of the distributor with the most of the manufacturer’s products
4. Member state in which the most users of the products are located

CRA reporting obligation and the distinction from NIS2: two reporting routes, two organizational units

Anyone already familiar with both processes sees the difference immediately: under NIS2, affected organizations report incidents to their respective national authority — which differs by member state. The CRA, as an EU regulation, runs centrally through ENISA.

Anyone who, as a manufacturer of critical infrastructure, is subject to both regimes (e.g., both as a NIS2 essential entity and as a CRA manufacturer) consequently serves two separate reporting routes, with potentially different deadlines and content. One report does not replace the other.

Special case: the non-EU manufacturer that isn’t interested in CRA compliance?

One of the most critical practical cases: the actual product manufacturer is based outside the EU and effectively ignores CRA compliance. This is not a theoretical scenario — with inexpensive electronics from the Far East in particular, it is the rule: the manufacturer ships, publishes no CVEs, reports nothing, does not respond to vulnerability reports.

Then the EU importer is on the hook. Art. 19(5) obliges them to inform the manufacturer without undue delay of known vulnerabilities; in the case of a significant cybersecurity risk, they must involve the market surveillance authority. In the extreme case — where the manufacturer does not respond and the product presents a significant risk — the importer must act themselves, up to withdrawal from the market.

Practical consequences for importers:

• Active monitoring of vulnerability databases (NVD, the BSI vulnerability database, the European vulnerability database under Art. 12(2) of the NIS2 Directive) for all imported products
• Contractual safeguards against non-EU manufacturers: an obligation to pass on security information, to provide patches, to cooperate on reporting obligations
• Portfolio review: which imported products are CRA-viable? For which is there a manufacturer that will actually fulfill the obligations?
• Caution regarding Art. 21 CRA: anyone who distributes the product under their own name or substantially modifies it is fully deemed a manufacturer — with all reporting obligations, no ifs or buts.

Handling the CRA reporting obligations — what is actually a prerequisite for it?

The reporting obligations mentioned presuppose that the manufacturer even knows what is inside their product and which vulnerabilities exist. That sounds trivial; it is not.

What counts as a vulnerability within the meaning of the CRA, and how to search for them systematically, is the subject of two further articles in our Knowledge Hub CRA specialist article series:

• Article 2 addresses the CRA-compliant cyber risk assessment
• Article 4 covers vulnerability handling and SBOM

A brief preview for technically versed readers: in the CRA context, a vulnerability is always assessed along the CIA triad — Confidentiality, Integrity, Availability. These three dimensions describe in what respect a successful attack can cause harm, and thereby determine the criticality.

For systematic risk assessment, established methods exist: BSI TR-03183 is oriented toward ISO 31000 and provides ready-made asset catalogs and impact tables; from the automotive and vehicle development domain, the TARA methodology (Threat Analysis and Risk Assessment per ISO/SAE 21434) is well known and conceptually transferable.

The CRA does not prescribe a specific method, but accepts any structured approach that documents asset identification, threat analysis, and risk acceptance in a traceable way.

Which product properties are meant to prevent a report from becoming necessary in the first place — that is, which technical requirements the CRA places on the product itself — is explained in the following Article 3 of this series, which details the Essential Cybersecurity Requirements defined in the CRA.

Which documentation must be kept on hand in order to be report-capable when it counts, and how the formal proof of conformity is furnished, is covered in Article 5 on conformity assessment and technical documentation.