Default, Important, or Critical: How to Classify Your Product Under the CRA

Before you can pick a conformity route, budget for a notified body, or even estimate what CRA compliance will cost, you have to answer one question: which category does the regulation put your product in? The answer determines whether you can self-assess under Module A, whether a third party must examine your product, and whether European cybersecurity certification enters the picture.

The conformity routes themselves are covered in a separate post. This one is about the classification decision that feeds them — because it is the decision most teams get wrong first, and because a lot of the classification guidance floating around the internet still reflects the 2022 Commission proposal rather than the regulation that was actually adopted. Several product categories moved between classes before the final text. If your classification memo cites a list that puts operating systems in Class II, it is out of date.

The Four-Tier Structure

The Cyber Resilience Act (Regulation (EU) 2024/2847) sorts products with digital elements into four tiers:

Default — every in-scope product that does not have the core functionality of a category listed in Annex III or Annex IV. This is the large majority of the market: business SaaS, mobile apps, games, most consumer IoT, embedded firmware without a security function.
Important, Class I — products with the core functionality of one of the categories in Annex III, Class I (Article 7).
Important, Class II — products with the core functionality of one of the categories in Annex III, Class II (Article 7).
Critical — products with the core functionality of one of the categories in Annex IV (Article 8).

Every tier carries the same essential cybersecurity requirements (Annex I), the same reporting obligations (Article 14), and the same documentation duties. What changes is how you are allowed to demonstrate conformity — and therefore how much the demonstration costs.

The Core-Functionality Test

Article 7(1) is precise about the trigger: a product is important if it "has the core functionality" of a product category set out in Annex III. Two words in that sentence do most of the work.

"Core" means the classification looks at what the product fundamentally is, not at every feature it contains. A project-management tool that includes a password-protected login is not a password manager. A firmware image that verifies a signature at startup is not a boot manager. Conversely, naming matters not at all: if your "workspace security add-on" is, functionally, a password manager, it has the core functionality of Annex III, Class I, item 3.

The integration rule. Article 7(1) states explicitly that integrating an important product into something else does not, by itself, make the host product important. If your smart coffee machine embeds an off-the-shelf operating system (Class I) and a microcontroller with security functions (Class I), the coffee machine does not inherit Class I status. The OS vendor and the chip vendor carry the stricter route for their products; you carry the default route for yours — plus due diligence on the components you integrated (Article 13(5)).

Technical descriptions. The regulation required the Commission to adopt an implementing act by 11 December 2025 specifying the technical description of each Annex III and Annex IV category (Article 7(4)). When you classify, work from the adopted technical descriptions, not just the category names — they are what turns "network management systems" from a label into a testable definition.

Annex III, Class I: The Long List

Class I contains nineteen categories. Grouped for readability, they are:

Security software and identity. Identity management systems and privileged access management software and hardware (including authentication and access-control readers, including biometric readers); password managers; malware detection, removal, or quarantine software; SIEM systems; public key infrastructure and digital certificate issuance software.

Network functionality. Products with a VPN function; network management systems; physical and virtual network interfaces; routers, modems intended for connection to the internet, and switches.

Platform software. Operating systems; standalone and embedded browsers; boot managers.

Silicon with security functions. Microprocessors, microcontrollers, and ASICs/FPGAs — in each case where they have security-related functionalities.

Consumer categories. Smart home general-purpose virtual assistants; smart home products with security functionalities (smart door locks, security cameras, baby monitors, alarm systems); internet-connected toys with social-interaction or location-tracking features; and personal wearables with a health-monitoring purpose that fall outside the medical device regulations, or wearables intended for use by children.

Note where operating systems sit: Class I, not Class II. That is one of the changes from the proposal that older summaries still get wrong.

Annex III, Class II: Short and Strict

Class II contains four categories:

Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments.
Firewalls, intrusion detection and prevention systems.
Tamper-resistant microprocessors.
Tamper-resistant microcontrollers.

The pattern: Class II products either sit underneath everyone else's security (virtualisation) or are the security boundary (firewalls, IDS/IPS, tamper-resistant silicon). Compromise one and you compromise everything built on it.

Annex IV: Critical Products

Annex IV lists three categories:

Hardware devices with security boxes.
Smart meter gateways within smart metering systems, and other devices for advanced security purposes, including secure cryptoprocessing.
Smartcards or similar devices, including secure elements.

These are hardware categories with the highest systemic trust assumptions — the components that entire infrastructures assume to be uncompromisable.

What Each Tier Means for Conformity

The consequences live in Article 32:

Default products may use internal control (Module A) — self-assessment, no third party (Article 32(1)).
Class I products may use Module A only if they apply, in full, harmonised standards, common specifications, or a European cybersecurity certification scheme at assurance level at least "substantial" covering the applicable requirements. Otherwise — including where those standards simply do not exist yet — the product must go through EU-type examination plus conformity to type (Modules B + C) or full quality assurance (Module H), both involving a notified body (Article 32(2)).
Class II products cannot self-assess at all: Modules B + C, Module H, or a European cybersecurity certification scheme at assurance level at least "substantial" (Article 32(3)).
Critical products must obtain a European cybersecurity certificate under a scheme the Commission designates by delegated act — but only once such a delegated act applies and a suitable scheme is actually available. Until then, Annex IV products follow the Class II routes (Articles 8(1) and 32(4)).

One carve-out worth knowing: manufacturers of products qualifying as free and open-source software that fall under Annex III categories may use any Article 32(1) procedure — including Module A — provided the technical documentation is made available to the public when the product is placed on the market (Article 32(5)).

The Mistakes We See Most

Classifying from an outdated list. The adopted regulation moved several categories relative to the 2022 proposal. Check your sources cite Regulation (EU) 2024/2847, not COM(2022) 454.

Treating "has security features" as "is a security product". Almost every product authenticates users and encrypts traffic. The test is core functionality, not feature presence. Document why your product's core functionality does or does not match a category — the reasoning belongs in your technical documentation alongside the risk assessment.

Assuming component classification propagates upward. It does not (Article 7(1)). But remember the mirror image: it also does not propagate downward. If you build a firewall out of default-class components, your firewall is still Class II.

Ignoring that the lists can change. The Commission can amend Annex III and Annex IV by delegated act (Articles 7(3) and 8(2)), with a minimum 12-month transition when a category is added to Annex III or moved from Class I to Class II. Classification is a decision you revisit, not a decision you archive.

Rounding up "to be safe". Choosing a heavier route than required is legal — Article 32 sets floors, not ceilings — but it can burn six figures and months of schedule. Being conservative about ambiguity is sensible; being conservative about a product that plainly is not listed in any annex is just expensive.

Document the Decision

Whatever you conclude, write it down: the category candidates you considered, the core-functionality reasoning, the date and the version of the technical descriptions you worked from. The classification rationale is the first thing a notified body or market-surveillance authority will probe, because everything downstream — the conformity route, the DoC, the CE marking — stands on it.

How Seentrix Fits In

Seentrix computes the classification from structured product facts — what the product is, what its core function is, which annex categories it matches — and derives the permitted conformity routes from that classification, so the route you follow can never silently drift from the category you documented. The classification rationale is stored with the product and lands in the technical-file skeleton automatically.

The judgment call — what your product's core functionality genuinely is — remains yours. What the platform guarantees is that once you have made that call, every downstream artefact stays consistent with it.