NEWVenvera speaks your language: the full platform, in English, German, Spanish and Bulgarian.See what’s new →
Who Must Comply With the Cyber Resilience Act?
Learn

Who Must Comply With the Cyber Resilience Act?

·Alexander Sverdlov

If you are working out who must comply with the Cyber Resilience Act, the short answer is that scope follows the product, not the industry. Regulation (EU) 2024/2847, the Cyber Resilience Act or CRA, sets horizontal cybersecurity rules for products with digital elements sold in the EU. It entered into force on 10 December 2024. Its vulnerability and incident reporting duties apply from 11 September 2026, and its full set of obligations from 11 December 2027. Whether it reaches you depends on what you make or sell and where it lands on the market, not on the sector you file your accounts under.

This guide walks the scope question in order: what a product with digital elements is, the three economic operator roles that carry duties, how classification decides your conformity route, what is carved out, and what a manufacturer actually has to do. First, the facts at a glance.

What triggers scopeA product with digital elements - any hardware or software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network - placed on the EU market in the course of a commercial activity.
Who carries dutiesManufacturers (primary duty-holder), importers, and distributors. Re-branding or substantially modifying a product moves an importer or distributor into the manufacturer role.
Governing lawRegulation (EU) 2024/2847
Entered into force10 December 2024
Reporting duties apply (Art. 14)11 September 2026 - report actively exploited vulnerabilities and severe incidents.
Full obligations apply11 December 2027 - essential requirements, conformity assessment, CE marking.
Classification tiersDefault (self-assess), important class I and class II (Annex III), and critical (Annex IV).
Maximum penaltyUp to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher (Art. 64), for breaching the Annex I essential requirements or the Article 13 and 14 obligations.
Decision flowchart for whether the Cyber Resilience Act applies to a product, covering the data connection test, the EU market test, and sector carve-outs

What counts as a product with digital elements

The CRA reaches any product with digital elements, meaning any hardware or software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or a network. That definition is deliberately broad. It goes well past obvious internet of things gadgets and pulls in firmware, operating systems, libraries, and software sold as a product. If your product can talk to another device or a network, and you place it on the EU market in the course of a commercial activity, the starting assumption is that the CRA applies.

There are limits. A product with no data connection, or one made available outside any commercial activity, sits outside the regulation. Software as a service is generally out of scope for the CRA and handled under NIS2 instead, unless it is the remote data-processing component of a product you also distribute. Free and open source software supplied outside a commercial activity is treated more lightly, with a separate, lighter set of duties for open-source software stewards who monetise or systematically support it. The flowchart above walks the gating questions the definition turns on.

The three economic operators who must comply

The CRA assigns duties to economic operators along the supply chain. Three roles carry the weight, and one product can involve all three. Find where you sit before you read the obligations.

The three CRA economic operators, manufacturer, importer, and distributor, with the core duty each one carries

The manufacturer is the primary duty-holder. It designs or produces the product, or has it made, and markets it under its own name or trademark. The manufacturer carries the essential requirements, runs the conformity assessment, affixes the CE marking, and reports vulnerabilities and incidents. The importer places a product from a third-country manufacturer on the EU market, and must verify that the manufacturer completed conformity assessment, that the CE marking is affixed, and that the technical documentation is present. The distributor makes the product available further down the chain and must check that the CE marking and documentation are in place and act with due care. Critically, an importer or distributor that markets a product under its own name or trademark, or substantially modifies one already on the market, takes on the full manufacturer obligations.

Product classification decides your conformity route

Not every in-scope product faces the same assessment. The CRA sorts products into risk tiers, and the tier decides whether you can self-assess or must bring in a third party. The default category covers most products, and the manufacturer can use internal control to self-assess against the essential requirements. The important categories, class I and class II, are listed in Annex III. The critical category is listed in Annex IV and may require a European cybersecurity certification.

CRA product classification tiers from default self-assessment through important class I and class II to critical, with the conformity route rising at each tier

The examples make the tiers concrete. Annex III class I covers products such as identity and password managers, standalone browsers, VPN products, network management systems, SIEM systems, boot managers, routers, modems and switches for non-industrial use, operating systems, and connected home or child-monitoring products with sensitive functions. Class II covers products performing highly significant security functions, such as hypervisors and container runtime systems, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers. Annex IV critical products are trust anchors such as hardware devices with security boxes, smart meter gateways, smartcards and secure elements, and, under the implementing acts, hardware security modules and tamper-resistant chips.

The route escalates with the tier. Default products can be self-assessed using internal control. Important class I products can be self-assessed only where the manufacturer applies the relevant harmonised standards or a European certification scheme in full; otherwise a third-party assessment is needed. Class II products need third-party assessment. Critical products may have to hold a certificate under a European cybersecurity certification scheme. Classifying each product early tells you how much external assessment to budget for.

What is carved out of scope

Some products with digital elements are already regulated for cybersecurity under dedicated EU rules, and the CRA steps back to avoid double regulation. Products covered by those sector regimes are outside the CRA.

Products carved out of the Cyber Resilience Act because they fall under sector rules: medical devices, motor vehicles, civil aviation, and marine equipment

The main carve-outs are medical devices covered by Regulations (EU) 2017/745 and 2017/746, motor vehicles under EU type-approval law, civil aviation products under the EASA framework, and marine equipment. Products developed exclusively for national security or defence, and products specifically designed to process classified information, are also excluded. If your product falls squarely inside one of these regimes, the sector rules govern its cybersecurity and the CRA does not add a second layer. Check the boundary carefully, because a component or accessory may not inherit the parent product's exemption.

Manufacturer, importer, distributor: who does what

The clearest way to read your duties is side by side. The manufacturer carries the full set of substantive obligations. The importer and distributor carry verification and due-care duties designed to keep non-conformant products off the market.

Split of Cyber Resilience Act obligations across manufacturer, importer, and distributor, with the manufacturer carrying the substantive duties

In practice, a manufacturer that gets its own house in order eases the burden downstream, because importers and distributors are largely checking that the manufacturer did its job. This is also where CRA compliance software earns its place: keeping the risk assessment, technical documentation, declaration of conformity, and vulnerability records in one auditable system the whole chain can point to.

What a manufacturer must do to comply

For manufacturers, the obligations are concrete. Start with a per-product cybersecurity risk assessment that informs design and documentation. Meet the Annex I Part I essential requirements: ship secure by default, with no known exploitable vulnerabilities, protection from unauthorised access, confidentiality and integrity of data, data minimisation, availability and resilience against denial of service, a limited attack surface, and the ability to be updated securely. Run the Annex I Part II vulnerability-handling processes: identify and document components in a software bill of materials, operate a coordinated vulnerability disclosure policy, issue security updates with advisories, and test regularly.

Then the market-placement duties. Provide a support period during which vulnerabilities are handled, reflecting how long the product is expected to be in use and at least five years unless the product's lifetime is shorter. Complete the conformity assessment for your product's tier, affix the CE marking, and draw up an EU declaration of conformity. Keep the Annex VII technical documentation and retain it, along with the declaration, for at least ten years after the product is placed on the market or for the support period, whichever is longer. Give users clear information and instructions, including the support end date.

The Article 14 reporting clock, precisely

Once the reporting duties apply on 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents to the CSIRT designated as coordinator in the Member State of their main establishment and to ENISA, through the single reporting platform ENISA operates. The clock runs in three steps, and the final step differs by report type:

Early warningWithin 24 hours of becoming aware.
NotificationWithin 72 hours, with the details known at that point.
Final reportFor an exploited vulnerability: within 14 days of a corrective or mitigating measure becoming available. For a severe incident: within one month of the 72-hour notification.

Frequently Asked Questions

Does the CRA apply to software sold as a standalone product?

Yes. Software placed on the EU market in the course of a commercial activity is a product with digital elements if its intended or foreseeable use includes a direct or indirect data connection. Software as a service delivered purely as a service is generally handled under NIS2 rather than the CRA, but software you distribute - including firmware, applications, and libraries sold as products - is in scope.

Is open source software covered?

Free and open source software supplied outside a commercial activity sits outside the manufacturer duties. A separate, lighter regime applies to open-source software stewards, meaning organisations that monetise or systematically support open-source components. A commercial product that bundles open-source components is fully in scope, and the manufacturer that ships it carries the duties for the whole product.

When do I actually have to be compliant?

In two stages. The Article 14 duties to report actively exploited vulnerabilities and severe incidents apply from 11 September 2026 to all in-scope products already on the market. The full set of obligations - essential requirements, conformity assessment, CE marking, and technical documentation - applies from 11 December 2027.

Do importers and distributors need to run a conformity assessment?

No. The manufacturer runs the conformity assessment. Importers verify it was done, that the CE marking is affixed, and that the technical documentation is present; distributors act with due care to check the same. But an importer or distributor that re-brands a product under its own name or substantially modifies it becomes the manufacturer for CRA purposes and inherits the full duties.

What are the penalties for non-compliance?

Article 64 sets three tiers. Breaching the Annex I essential requirements or the Article 13 and 14 obligations can draw fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other operator obligations carry up to EUR 10 million or 2%, and supplying incorrect or misleading information to notified bodies or market surveillance authorities up to EUR 5 million or 1%.

Working out your CRA scope with Venvera

Scope and classification are the first things to get right, because the conformity route and the cost follow from them. The Venvera CRA module maps the product-with-digital-elements test, the economic operator roles, and the Annex III and Annex IV classification into a structured gap assessment, so you can see for each product whether it is in scope and which route it takes. Because the CRA overlaps with security controls you may already run, the crosswalk engine lets you reuse evidence from NIS2, DORA, and ISO 27001 rather than starting from zero.

If you want a fast read on where you stand, run a free compliance check and use the scope questions above as your starting point. The CRA sits alongside your other obligations rather than replacing them, so the controls you already operate for NIS2 or ISO 27001 give you a head start on the essential requirements.

Primary sources

This guide is drawn from the regulation and official EU guidance: Regulation (EU) 2024/2847 (the full CRA text, including Article 14, Article 64, and Annexes I, III and IV); and the European Commission's Cyber Resilience Act policy pages and legislative summary. Product classification detail reflects the Commission implementing act specifying the technical descriptions of the Annex III and Annex IV categories. Always confirm the current text before relying on a specific date or figure.

Alexander Sverdlov

Alexander Sverdlov

CEO & Founder

Alexander is the founder of Venvera and a 20+ year veteran of European cybersecurity and compliance. He has led security and risk programmes for regulated financial institutions, fintechs and SaaS companies operating under DORA, NIS2, GDPR, ISO 27001 and the EU AI Act. Before Venvera, he founded Atlant Security, an offensive security consultancy that ran penetration tests, red-team exercises and ISO 27001 readiness programmes for clients across the EU and the Middle East. He writes on the cross-framework realities of running modern compliance: how to map one control to many obligations, where the spreadsheets fall apart, and what regulators are actually asking for once the auditor sits down.

More articles by Alexander

RELATED POSTS