Purpose
The Cyber Resilience Act (Regulation (EU) 2024/2847) horizontally covers all products with digital elementsthat are made available on the Union market. Whether a product is covered, which role the client assumes and which importance class the product falls into determines the entire set of obligations — from the reporting obligation from 11.09.2026 to the conformity assessment route from 11.12.2027. This skill carries out the initial assessment and provides the CRA product inventory.
⚠️ Currency (as of 2026-07): The regulation entered into force on 10.12.2024 and applies in stages. Since 11.06.2026 the provisions on conformity assessment bodies and notified bodies have applied. From 11.09.2026 — in seven weeks — the reporting obligations for actively exploited vulnerabilities and serious security incidents will apply. Only from 11.12.2027 will the regulation apply in full, including the essential cybersecurity requirements, CE marking, conformity assessment and technical documentation.
Practical consequence of the staging: Anyone who only builds the product inventory in 2027 is already in breach of obligations regarding the reporting requirement. The reporting obligation attaches to the product — without a reliable inventory, it cannot be determined within 24 hours in an emergency whether a report must be made at all.
Sanctions framework: For infringements of the essential cybersecurity requirements and the central manufacturer and reporting obligations up to EUR 15 million or 2.5% of worldwide annual turnover, whichever amount is higher (Art. 64 CRA).
Inputs
- Client's product list with a short technical description (hardware, software, embedded systems, firmware)
- Distribution channel and market access (in-house development, purchased, white label, import from a third country, pure resale)
- Brand under which the product is made available and registered office of the legal entities
- Third-party components used, in particular open-source software and its origin
- Existing sectoral approvals or conformity assessments (MDR, type approval, aviation approval, radio equipment law)
- Planned or completed making available on the Union market and its date
- Information on remote processing solutions that are required for the functioning of the product
Sub-agent architecture
Three conceptual roles structure the analysis. A scope reviewer clarifies whether a product with digital elements within the meaning of Art. 3 CRA exists at all and whether a sector exclusion under Art. 2 CRA applies; that role decides first, because without scope every further assessment is omitted. A role analyst then determines whether the client is a manufacturer, authorised representative, importer, distributor or administrator of open-source software, and in particular reviews the change of role in the case of an own brand and substantial modification. A classification reviewer then assigns the product to the standard category, the important products under Annex III or the critical products under Annex IV and derives from this the permissible conformity assessment route. The result of the three roles is merged into a single product inventory that lists the role, class, deadlines and responsible person for each product.
Procedure
1. Product with digital elements? (Art. 3 CRA)
Covered is any software or hardware product including its remote data processing solutions whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network.
Typical covered hardware: smartphones, laptops, smartwatches, smart home devices, firewalls, routers, microprocessors, intelligent metering systems (smart meters). Typical covered software: accounting software, mobile applications, computer games, operating systems, libraries. The CRA makes no distinction between B2B and consumer business; both are covered.
Review steps:
a) Does the product contain digital elements (software or firmware) that operate independently or embedded? b) Is there a data connection — also indirectly via another device or a cloud? c) Is a remote processing solution functionally part of the product, so that the product does not fulfil its function without it? Then it must also be reviewed. d) Is the product for a fee or free of charge made available on the Union market in the course of a commercial activity ? Being free of charge alone does not exempt it.
2. Review sectoral exclusions (Art. 2 CRA)
Excluded are products that are already regulated equivalently by specific Union legal acts, in particular:
- Medical devices and in vitro diagnostic medical devices under the MDR or IVDR
- Motor vehicles and their systems under Union type-approval law
- Civil aviation under the relevant Union law
- Marine equipment under the Marine Equipment Directive
- Products that were developed exclusively for the purposes of national security, defence or the processing of classified information were developed
[unverifiziert - prüfen] The exact scope of the exclusions and the treatment of spare parts as well as of products that are also high-risk AI systems under the AI Act must be verified against the Official Journal text of Art. 2 CRA. Sectoral approval is not a blanket free pass: it exempts only to the extent that the exclusion reaches.
The exclusion must be documented on a product-specific basis with reasons, not across the board for a portfolio.
3. Determine role (Art. 13 CRA)
| Role | Characteristic | Core obligations |
|---|---|---|
| Manufacturer | develops or has developed and markets under its own name or own brand | full set of obligations including reporting obligation under Art. 14 CRA |
| Authorised representative | representative of a manufacturer in the Union appointed in writing | contractually transferred obligations, in particular documentation and contact with authorities |
| Importer | places a product from a third country on the Union market for the first time | verification and assurance obligations; action in the event of non-conformity |
| Distributor | makes available without being a manufacturer or importer | duties of care; notification in the event of known risks |
| Open-source software steward | sustainably supports the development of free and open-source software in the course of a business activity | attenuated, separate set of obligations (see step 4) |
Change of role: Anyone who makes a product available under their own name or own brand or substantially modifies it, is regarded as a manufacturer with the full set of obligations. White-label procurement, OEM constellations, rebranding and far-reaching firmware adjustments are the most common triggers in practice. [unverifiziert - prüfen] The legal basis for the change of role is Art. 22 CRA.
4. Open-source software stewards (Art. 24 CRA)
The CRA creates for open-source stewards a separate, lighter category. It covers legal persons that sustainably support the development of free and open-source software intended for commercial activities — typically foundations.
Delimitation:
- Not covered: purely private or non-commercial contributors without a business activity
- Open-source software steward: separate, reduced regime (cybersecurity policy, cooperation with market surveillance authorities, reporting in accordance with Art. 14 CRA)
- Full manufacturer: anyone who monetises open-source software and makes it available on the market as a product — the open-source origin then does not exempt them
For companies, the practically more important question is the opposite direction: Anyone who integrates open-source components into their product is responsible for those components as a manufacturer. Responsibility does not move to the upstream project with the licence.
5. Classification by importance classes (Annex III and Annex IV CRA)
The CRA recognises three levels:
- Standard products — the large majority; conformity assessment in principle by internal control
- Important products under Annex III, divided into Class I and Class II — products with increased cybersecurity relevance such as identity and access management, password managers, network interfaces, operating systems, routers, firewalls, microprocessors with security-related functions. Class II is subject to the stricter assessment route
- Critical products pursuant to Annex IV — the smallest group with the highest level of requirements; for them a European cybersecurity certification may be required
The classification is product-related, not company-related and must be justified in writing for each product. It directly controls whether a notified body must be involved — and thus the lead time before 11.12.2027.
6. Timeline and existing products (Art. 71 CRA)
| Date | What applies |
|---|---|
| 10.12.2024 | Entry into force |
| 11.06.2026 | Provisions on conformity assessment bodies and notified bodies |
| 11.09.2026 | Reporting obligations pursuant to Art. 14 CRA — 24 hours / 72 hours / final report |
| 11.12.2027 | full applicability: essential requirements, CE marking, conformity assessment, technical documentation |
For the inventory, this results in a dual timeline: reporting capability must be in place by 11.09.2026, conformity by 11.12.2027. [unverifiziert - prüfen] The treatment of products placed on the market before 11.12.2027, as well as the scope of the transitional arrangement for substantial changes, must be verified against the Official Journal text.
7. Product inventory, responsibilities and German authority interface (Art. 52 CRA)
The result of the review is a CRA product inventory, which states for each product: name and version, captured yes/no with justification, role, class pursuant to Annex III/IV, support period, responsible person, reporting channel and deadlines.
The German interface is the BSI (bsi.bund.de). [unverifiziert - prüfen] On the linkage with the AI Act: under the AI-MIG, the BSI is the notifying authority for Annex III No. 1 of the AI Act (biometrics) only on a transitional basis, until the market surveillance authority is designated pursuant to Art. 52 (2) CRA ; because of Art. 52 (14) CRA , the authority competent under the AI Act simultaneously performs the CRA market surveillance tasks for overlapping products. Both statements must be checked against the promulgated statutory text and the Official Journal text before use in a client-specific context.
Sources
Statute
- Regulation (EU) 2024/2847 (Cyber Resilience Act) — full text with annexes
- Art. 2 CRA (scope and exclusions), Art. 3 CRA (definitions), Art. 13 CRA (obligations of manufacturers), Art. 14 CRA (reporting obligations), Art. 22 CRA (change of roles)
[unverifiziert - prüfen], Art. 24 CRA (open-source software stewards)[unverifiziert - prüfen], Art. 52 CRA (market surveillance), Art. 64 CRA (penalties), Art. 71 CRA (entry into force and application)[unverifiziert - prüfen] - Annex III CRA (important products, classes I and II), Annex IV CRA (critical products), Annex I CRA (essential requirements)
- Directive (EU) 2022/2555 (NIS2) — demarcation of entity-related obligations
- Regulation (EU) 2024/1689 (AI Act) — overlap for high-risk AI systems
Guidelines
- European Commission, Cyber Resilience Act — policy page and FAQ on implementation
- BSI — implementation of the Cyber Resilience Act in Germany
- ENISA, publications on the implementation of the CRA
Case law: Regarding the Cyber Resilience Act, no case law is apparent (as of 07/2026). The substantive obligations largely apply only from 11.12.2027. Decisions on product safety and product liability law can at most be drawn on by analogy and must be expressly labelled as an analogy.
Output format
CRA-ANWENDUNGSBEREICH — PRÜFUNG — <Produkt> — <Datum>
I. Produkt mit digitalen Elementen? [ja / nein — Begründung, Art. 3 CRA]
Fernverarbeitungslösung erfasst? [ja / nein]
II. Bereichsausnahme (Art. 2 CRA) [keine / MDR / Kfz / Luftfahrt / … ]
III. Rolle [Hersteller / Bevollmächtigter /
Einführer / Händler / OSS-Verwalter]
Rollenwechsel geprüft [Eigenmarke / wesentliche Änderung]
IV. Einstufung [Standard / Anhang III Klasse I /
Anhang III Klasse II / Anhang IV]
Konformitätsbewertungsweg [interne Kontrolle / notifizierte Stelle]
V. Quelloffene Komponenten [Liste / Verantwortung beim Mandanten]
VI. Fristen 11.09.2026 Meldepflichten
11.12.2027 vollständige Geltung
VII. Deutsche Behördenschnittstelle [BSI — Zuständigkeit prüfen]
VIII. Sanktionsrisiko (Art. 64 CRA) [bis 15 Mio. EUR / 2,5 %]
Risikoeinstufung: 🟢 / 🟡 / 🔴
Empfehlung: <…>
Nächste Schritte: <…>
Risks / typical mistakes
- Inventory built too late — the reporting obligation applies from 11.09.2026, not only from 11.12.2027. Without a product inventory, it cannot be determined within 24 hours in an incident whether a reporting obligation exists.
- Software underestimated — pure software is a product with digital elements. Accounting software, apps and games are covered; the notion that the CRA affects only hardware is the most common application error.
- Sectoral exemption assumed across the board — a sectoral approval under MDR or type-approval law exempts only insofar as the exemption under Art. 2 CRA extends, and must be justified on a product-specific basis.
- Change of role overlooked — white label, rebranding and substantial firmware changes turn distributors and importers into manufacturers with the full set of obligations, including the reporting obligation.
- Open-source origin misunderstood as an exemption — anyone who integrates open-source components into a marketed product is liable for them as a manufacturer. Art. 24 CRA relieves the steward, not the integrator.
- Remote processing solution excluded — functionally necessary cloud components form part of the product and must be assessed as well.
- Classification under Annex III not justified — the class assignment governs the conformity assessment route. An unjustified classification as a standard product may cost the entire lead time to the notified body.
- Company-related instead of product-related review — the CRA attaches to the product, NIS2 to the entity. The two reviews must be conducted separately.
- Sanction framework confused — Art. 64 CRA provides for up to EUR 15 million or 2.5% ; the frameworks of the AI Act (3%) and NIS2 differ.
- ⚠️ Article numbers adopted without verification — some of the numbers given here are
[unverifiziert - prüfen]and must be verified against the Official Journal text of Regulation (EU) 2024/2847 before use in a client-facing context.