The Cyber Resilience Act distinguishes products with digital elements (PDEs) into three regulatory tiers. The default tier — roughly 90 per cent of products — permits self-assessment under conformity assessment Module A. The "important" tier in Annex III imposes additional rigour, with Class I products requiring application of harmonised standards or third-party assessment, and Class II products always requiring Notified Body involvement. The "critical" tier in Annex IV requires European cybersecurity certification under Article 8 in addition to conformity assessment. The categories described in those annexes were drafted at a high level. The Commission has now provided the operational detail. Commission Implementing Regulation (EU) 2025/2392, signed on 28 November 2025 and published in the Official Journal on 1 December 2025, fixes the technical descriptions of each category.
Why did the technical descriptions matter?
When Regulation (EU) 2024/2847 was published in November 2024, the lists in Annexes III and IV used short product-category labels — "operating systems for servers, desktops and mobile devices," "firewalls, intrusion detection and prevention systems," "smart meter gateways within smart metering systems" and so on. The labels are intuitive but imprecise. Manufacturers struggled to determine whether a microcontroller with a TLS stack qualified as a "secure element," whether a developer-focused VPN library was a "VPN" within the Annex III meaning, or whether a managed firewall service was a "firewall." The implementing regulation closes those gaps by issuing technical descriptions — paragraph-level definitions that nail down what is in and out of each category.
What does the regulation actually contain?
The text is structured as an annex of category-by-category definitions. For each Annex III and Annex IV product category, the regulation provides:
- the operational definition of the core functionality that triggers categorisation
- examples of products that are inside the category
- examples of adjacent products that are outside the category
- where applicable, technical specifications (protocols, standards, deployment contexts) that distinguish in-scope from out-of-scope variants
For example, the "firewalls, intrusion detection and prevention systems" entry under Annex III Class II clarifies that the category covers PDEs whose primary function is to filter network traffic based on configurable rules and to detect or prevent malicious activity at network or host level. It explicitly includes managed firewall appliances and dedicated software firewall products. It excludes general-purpose operating systems that happen to include a host firewall feature, and it excludes pure rule-management tools that do not themselves enforce traffic policy. Similar precision applies to "operating systems," "VPN products," "password managers," and other categories.
Which Annex III and Annex IV categories are most disputed?
Three categories generated the heaviest consultation comment and now receive significant clarifying text. First, "smart home products with security functionalities" — Annex III Class I — was widely seen as overbroad. The implementing regulation narrows it to PDEs whose primary or substantial function is to enable physical access control (smart locks), monitor a residence (cameras, motion sensors), or coordinate other security functions in a home environment (alarm panels). General-purpose smart speakers without those primary functions are out. Second, "internet-connected toys" — Annex III Class I — receives a definition keyed to network connectivity capability and target user age, addressing manufacturer concerns that simple Bluetooth-only toys with no internet capability would be miscategorised. Third, the Annex IV category covering "smart meter gateways" is sharpened to align with the EU Electricity Directive definitions, removing ambiguity about whether downstream displays and applications attached to the gateway are themselves critical products.
| Tier | Annex | Class | Conformity assessment | Notable examples | |------|-------|-------|------------------------|-----------------| | Default | n/a | n/a | Module A (self-assessment) | Most software products, IoT without critical function | | Important | Annex III | Class I | Module A if harmonised standards applied, else Module B+C or H | Password managers, VPNs, smart locks, network management | | Important | Annex III | Class II | Module B+C or Module H (third-party required) | Firewalls, IDS/IPS, tamper-resistant microcontrollers | | Critical | Annex IV | n/a | EU cybersecurity certification + Module B+C or H | Smart cards, secure elements, smart meter gateways |
How does this interact with conformity assessment?
The Article 32 conformity assessment regime depends entirely on accurate categorisation. A product erroneously self-assessed under Module A that should have been Class II under Annex III is non-conforming, regardless of whether the underlying technical controls would have passed a Notified Body review. The implementing regulation therefore has the effect of converting categorisation from a strategic decision exposed to argument into a documented determination evidenced against the technical description. Manufacturers must produce a categorisation memorandum, available to market surveillance authorities, showing why each PDE sits in the tier it does. Where a product line includes variants, the assessment must be performed per variant.
# Categorisation memorandum structure
product_id: Acme-Gateway-Pro
primary_functionality: |
Network traffic inspection and policy enforcement at perimeter,
with stateful rule engine and integrated IPS module.
core_function_match: |
Annex III Class II - firewalls, intrusion detection and prevention systems
Reg 2025/2392 Annex section 5: "PDEs whose primary function is to filter
network traffic based on configurable rules..." [matches]
adjacent_categories_considered:
- Annex III Class I VPN: NOT primary function (VPN is optional module)
- Annex III Class I Network management: NOT primary function
classification: Annex III Class II Important
conformity_route: Module H (quality management system assessment by Notified Body)
notified_body_reference: TBD pending designation in 2026
What about products with overlapping functions?
Implementing Regulation 2025/2392 follows the "primary or substantial function" test from the CRA itself. A product is in a category if that category's function is its primary or substantial function. Where multiple Annex III categories apply, the product takes the higher classification — Class II prevails over Class I for important products, and Annex IV (critical) prevails over Annex III. Where a product has a critical function alongside ordinary functions, the entire product becomes a critical product because the conformity assessment must cover the critical function.
What is the timeline for compliance?
Annex III and Annex IV classification mattered formally from the date the implementing regulation took effect (in the days following its 1 December 2025 publication), but the consequences for conformity assessment only crystallise when the substantive CRA obligations apply on 11 December 2027. Between now and then, manufacturers must complete categorisation, decide the conformity route, and produce or commission technical documentation against the Annex I essential cybersecurity requirements. For Class II and critical products, this means engaging a Notified Body — and Notified Body designation under Article 47 only begins on 11 June 2026, with capacity expected to grow through 2027.
How Safeguard Helps
Safeguard builds the product inventory that underpins CRA categorisation, including SBOMs, deployment characterisation, and functional descriptors that map directly to the technical descriptions in Implementing Regulation 2025/2392. The platform's categorisation workflow records the memorandum for each PDE — primary function, adjacent categories considered, classification rationale, conformity route — in the format market surveillance authorities will expect. Where a product line spans variants with different classifications, Safeguard tracks variant-level categorisation independently. As Notified Bodies are designated from June 2026, the platform integrates with their evidence intake processes so that Module B+C and Module H assessments can draw from a single source of truth maintained in the CI/CD pipeline.