In brief. The European Commission has published detailed definitions of which products with digital elements are treated as “important” or “critical” under the EU's Cyber Resilience Act ("CRA"). This matters because the category a product falls into changes the conformity assessment procedure, including how much testing, documentation and (in some cases) third party assessment is needed before it can be made available on the EU market.
At a glance:
- Classification turns on what the product is mainly for (“core functionality”), not every feature or component it contains.
- The new annexes add practical definitions for the CRA’s 'important' and 'critical' categories (which attract stricter conformity assessment), helping businesses classify products earlier and more consistently.
Baseline CRA duties still apply to all in‑scope products, including a cybersecurity risk assessment and proportionate “secure by default” / lifecycle security obligations.
1. What is the Cyber Resilience Act (CRA)?
As noted in our earlier Cyber Monthly Wrap-up (UK, EMEA and the US) – November 2024, the EU’s Cyber Resilience Act ("CRA") is a product security regime for software, hardware and connected devices placed on the EU market.1
It requires manufacturers (and, in some cases, importers and distributors) to address cybersecurity risks from the design stage onwards and to manage vulnerabilities and security updates across a product’s lifetime.
Because it applies to products placed on the EU market, UK‑based businesses can be in scope despite the UK’s withdrawal from the EU.
2. What's new?
On 28 November 2025, the European Commission adopted Commission Implementing Regulation (EU) 2025/2392, published on 1 December 2025 (the "Implementing Regulation").2 It entered into force on 21 December 2025 and applies directly across the EU.
The Implementing Regulation does not amend the CRA itself. Instead, it provides the technical descriptions for the CRA’s categories of “important” and “critical” products (listed at a high level in CRA Annex III and Annex IV).
Why this matters: Whether a product is categorised as “important” or “critical” determines which conformity assessment route applies under the CRA, and therefore testing, documentation and (in some cases) third-party conformity assessment or certification required before a product can be placed on the EU market.
3. What the implementing regulation clarifies for product classification
A. Product categorisation depends on core functionality (not embedded components)
The Implementing Regulation reiterates the CRA's core approach: classification depends on a product's core functionality – what it is fundamentally designed to do.3
Two practical clarifications follow from that:
1. Embedding a component that might itself fit an “important” or “critical” description does not automatically re‑classify the wider product.
2. A product is not classified in a category merely because it can perform some functions associated with that category — the question remains what the product is mainly “for”.
The Commission illustrates this with examples in Recitals (3) – (5):
• Embedded browser / news app: embedding a browser component in a news app does not by itself make the app subject to the conformity route for products whose core functionality is a browser. However, the manufacturer must still assess the security of the overall product, taking account of integrated components as appropriate.4
• SOAR vs SIEM: Security orchestration, automation, and response (SOAR) software that can carry out SIEM‑type functions is not necessarily a SIEM if its core functionality is different.5
• Smartphones: a smartphone is not generally treated as an operating system or password manager just because it integrates those components, because that is not its core functionality.6
Irrespective of whether the product is ultimately classified as “important” or “critical”, Recital (6) emphasises that manufacturers must carry out a comprehensive cybersecurity risk assessment and implement the CRA’s essential cybersecurity requirements proportionately (i.e. the baseline “secure by default” and lifecycle security obligations in Annex I to the CRA).
Taken together, these examples highlight that classification is not purely a “feature checklist”: it turns on design intent and core functionality, while still requiring a defensible, product‑level security assessment that takes account of integrated components as appropriate.
B. Technical descriptions clarify how “important” and “critical” categories should be interpreted
Under the CRA, Annex III lists categories of “important” products and Annex IV lists categories of “critical” products. The Implementing Regulation fills in the detail by setting out the technical descriptions of those categories in its own Annex I (important) and Annex II (critical).
- Annex I (important products): The definitions spell out what functionality counts. For example, “standalone and embedded browsers” includes both full browser applications and embedded browsers intended for integration; “identity management systems” extends beyond authentication servers to cover privileged access management tools and biometric readers; and “password managers” includes local, enterprise and hardware based solutions.
- Annex II (critical products): Annex II performs the same “definition” function for critical categories. For example, “hardware devices with security boxes” are described by reference to securely storing/processing sensitive data or performing cryptographic operations with physical tamper evidence/resistance/response; smart meter gateways are described by their role in securing communications within smart metering systems; and secure elements/smartcards are described by their tamper‑resistant design and role in storing or managing credentials/cryptographic operations.
Some tamper‑resistant hardware definitions use Common Criteria vulnerability levels (“AVA_VAN”) as a recognised way to express designed resistance to exploitability. It is part of those specific category definitions, not a general rule that any well‑secured IT product becomes “critical”.
| Key point (how to read Annex I/II alongside the “core functionality” recitals) |
|---|
The Implementing Regulation can describe certain components as “important” or “critical” when they are placed on the market in their own right. However, the mere fact that such a component is integrated into another product does not automatically re‑classify the product with digital elements as a whole. Recital (3) makes clear that classification still turns on what the product with digital elements as a whole is mainly designed to do (its core functionality). The manufacturer must, however, assess the security of the product as a whole, taking account of integrated components where appropriate. |
4. At a glance: What to do, what to watch, what to plan
| Immediate actions | Common watch-outs | Planning points |
|---|---|---|
Consider and document what each product is mainly for. Describe its core purpose (ideally in 1-2 sentences) and keep it as the anchor for classification. | Don’t let an embedded component drive classification by accident. A product can include 'important' and 'critical' category components without being classed in that category overall. However, you should consider the implications of embedding functionality from elsewhere (e.g. through use of libraries) that natively would have a higher classification. | Build classification into the product roadmap early. If a product is likely to be “important” or “critical”, allow time for more evidence, documentation and (in some cases) independent assurance before launch decisions are locked in. The consequences should be communicated to your development teams early-on, to enable the software development lifecycle to accommodate the additional requirements. |
Map core functionality to Annex I/II definitions. Use the Implementing Regulation’s technical descriptions as the matching exercise, not just the CRA’s category labels. | Expect grey areas for multi‑function products. Platforms and modular products may sit close to several category descriptions; the Regulation’s examples are illustrative and non‑exhaustive. | Prepare a short internal “classification note”. Record what you considered and why your classification fits, so the position is consistent across legal, R&D, product and marketing teams. |
Run (or refresh) baseline CRA lifecycle security work for all in‑scope products. This includes a cybersecurity risk assessment and proportionate “secure by default” / lifecycle obligations, whatever the category. | Keep marketing claims aligned. If sales materials describe a product as a “security platform”, “identity solution” or “critical security device”, or otherwise stress the security-related aspects of the product, that can undermine the argument that its main purpose is something else. | Know what’s in your product. The CRA expects manufacturers to maintain an inventory of the software components in a product (often called a software bill of materials (“SBOM”)) as part of vulnerability management and the technical documentation, and it may need to be provided to market surveillance authorities on request. |
5. Our view
5.1 The Implementing Regulation is a technical but important step in the CRA’s implementation. It does not change the CRA's Annex III/IV lists of 'important' and 'critical' categories, but it translates high‑level category labels into criteria that can be applied when designing, documenting and launching products for the EU market.
5.2 For UK businesses selling into the EU, this clarification allows earlier and more confident compliance planning, reducing the risk of late re‑classification disrupting product launch timelines, assurance strategy and costs.
5.3 In practice, the hardest cases rarely sit cleanly within one category. Modular, multi‑function offerings and products built around integrated components often raise classification questions with no obvious “right answer”. The Implementing Regulation helps, but it does not remove the need for careful interpretation and a coherent written rationale.
5.4 While the deadline for products to be compliant seems some way away (11 December 2027 ), earlier obligations in relation to vulnerability and incident reporting will apply from 11 September 2026. In the context of the software development lifecycle, and the need to embed compliance from the outset of a product's design, this is not actually long at all. A key takeaway for the EU CRA more generally is therefore that legal, compliance, governance and R&D teams need to be working together now in order to manage the roadmap to compliance, to avoid the need for development teams to try to retrofit compliance to existing products as the deadline approaches.
Footnotes
1 https://www.hsfkramer.com/notes/cybersecurity/2024-posts/cyber-monthly-wrap-up-uk-emea-us-november-2024
2 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32025R2392&qid=1764577062755
3 Article 7(1) and Article 8(1) CRA; Recitals 2 – 7 Implementing Regulation.
4 Recital 3 Implementing Regulation.
5 Recital 5 Implementing Regulation.
6 Recital 5 Implementing Regulation.
Andrew Moir
Partner, Intellectual Property and Head of Cyber Security and Data, London
Peter Dalton
Partner, London
Sabesh Asokan
Associate, London
Key contacts
Andrew Moir
Partner, Intellectual Property and Head of Cyber Security and Data, London
Peter Dalton
Partner, London
Sabesh Asokan
Associate, London
Disclaimer
The articles published on this website, current at the dates of publication set out above, are for reference purposes only. They do not constitute legal advice and should not be relied upon as such. Specific legal advice about your specific circumstances should always be sought separately before taking any action.