CRA Product Classification: Default, Class I, Class II, Critical

CRA classification decides everything downstream under the Cyber Resilience Act — whether you need a notified body, what the assessment costs, and how long it takes. Get it wrong in one direction and your conformity assessment is invalid. Get it wrong in the other and you have bought an assessment you never needed.

Most of the difficulty in Regulation (EU) 2024/2847 is concentrated in a single provision, Article 7(1), which contains two rules that pull in opposite directions.

The four CRA classification tiers

Take the CRA classification annexes in order — Annex IV first, then class II, then class I. The highest tier that fits governs.

CRA classification rule one: core functionality, not the presence of a feature

Article 7(1) says a product is an important product where it has the core functionality of a product category set out in Annex III.

Not “contains”. Not “includes”. Has the core functionality of. A product that happens to bundle password management is not an Annex III class I product on that basis alone — the question is whether password management is what the product exists to do.

The Regulation does not define “core functionality”. Assess it against the intended purpose you have recorded and against how the product is marketed — what it is sold as being for. Where your own marketing leads on a capability that matches an Annex III category, that is strong evidence the capability is core, whatever the engineering view.

Where it is genuinely borderline, Article 7(2) gives the criteria the Commission used to build the list, and reasoning against them is defensible. A category is in Annex III because it meets at least one of:

• (a) the product primarily performs functions critical to the cybersecurity of other products, networks or services — securing authentication and access, intrusion prevention and detection, end-point security, network protection; or
• (b) the product performs a function carrying a significant risk of adverse effects in intensity and ability to disrupt, control or damage a large number of other products, or users’ health, security or safety, through direct manipulation — such as a central system function including network management, configuration control, virtualisation or the processing of personal data.

A product satisfying neither is unlikely to have the core functionality of an Annex III category, and saying so with reference to Article 7(2) is a much better record than an unexplained “not applicable”.

CRA classification rule two: integration does not propagate upward

This is the relief valve, and it is frequently overlooked.

Article 7(1) states expressly that the integration of a product with digital elements which has the core functionality of a product category set out in Annex III shall not in itself render the product in which it is integrated subject to the third-party conformity assessment procedures.

So a washing machine containing an embedded operating system does not become an Annex III class I product because class I item 11 is “operating systems”. The embedded operating system is a class I product if it is placed on the market separately. The washing machine is assessed on its own core functionality.

The same logic covers a device with a network interface (item 10), a product bundling a TLS library, or an appliance running a hypervisor internally. Integration alone does not move the host product up a tier.

What it does not do is let you avoid classifying the component. If you also sell that operating system, library or module on its own, it is a product with digital elements in its own right and it carries the full obligations.

CRA classification, Annex III class I — the 19 categories

1. Identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers
2. Standalone and embedded browsers
3. Password managers
4. Software that searches for, removes, or quarantines malicious software
5. Products with the function of virtual private network (VPN)
6. Network management systems
7. Security information and event management (SIEM) systems
8. Boot managers
9. Public key infrastructure and digital certificate issuance software
10. Physical and virtual network interfaces
11. Operating systems
12. Routers, modems intended for connection to the internet, and switches
13. Microprocessors with security-related functionalities
14. Microcontrollers with security-related functionalities
15. ASICs and FPGAs with security-related functionalities
16. Smart home general purpose virtual assistants
17. Smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems
18. Internet connected toys covered by Directive 2009/48/EC that have social interactive features (for example speaking or filming) or location tracking features
19. Personal wearable products worn or placed on a human body that have a health monitoring purpose and to which Regulation (EU) 2017/745 or (EU) 2017/746 do not apply, or personal wearable products intended for use by and for children

Three qualifiers in that list do real work.

Items 13, 14 and 15 are limited to processors, controllers and programmable devices with security-related functionalities. A general-purpose microcontroller without them is not class I on that basis.

Item 12 qualifies modems by “intended for the connection to the internet”. Routers and switches carry no such qualifier.

Item 19 draws the boundary with the medical device regime expressly, and it is the boundary most likely to be argued. A wearable with a health monitoring purpose is class I here only if the Medical Device Regulation and the In Vitro Diagnostic Regulation do not apply to it. Where they do, the product is outside the CRA entirely under Article 2(2). The two outcomes are mutually exclusive and your determination has to say which applies — a consumer fitness tracker that is not a medical device is class I; a device that is a medical device is not a CRA product at all.

The second limb of item 19 has no medical qualifier whatever: personal wearable products intended for use by and for children are class I regardless of whether they monitor health.

Annex III class II — the 4 categories

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

Class II never has a self-assessment route. Whatever the standards position, these products go to a notified body or a certification scheme at assurance level at least “substantial”.

CRA classification, Annex IV — the 3 critical categories

1. Hardware devices with security boxes
2. Smart meter gateways within smart metering systems as defined in Article 2, point (23) of Directive (EU) 2019/944, and other devices for advanced security purposes, including for secure cryptoprocessing
3. Smartcards or similar devices, including secure elements

Article 8(1) lets the Commission determine by delegated act which of these must obtain a European cybersecurity certificate — but only where a scheme covering them exists and is available. No such act has been adopted, and Article 8(1) provides expressly that in its absence, Annex IV products take the class II routes.

CRA classification: record what you rejected, not only what matched

This is the part organisations skip, and it is the part an assessor will ask about.

A classification record showing only the category that matched does not demonstrate that the others were examined. For each category considered, record one of three outcomes: matches, does not match, or — the valuable one — considered and rejected, with reasons.

Where you rejected a category because the matching functionality is integrated rather than core, say so and cite Article 7(1). That reasoning is defensible; an unexplained absence is not.

CRA classification can change without the product changing

Two events move a product between tiers with no engineering work at all.

A change of intended purpose. Marketing an existing capability to a new sector, or describing a general-purpose component as providing a security function, can bring a product into an Annex III category. Under Article 3(30) that is also a substantial modification — the definition’s second limb is “a modification to the intended purpose for which the product has been assessed” — which means it can pull a legacy product into the full Regulation under Article 69(2). No code changes; the obligations do.

A delegated act under Article 7(3). The Commission may amend Annex III by adding a category to either class, moving a category from one class to the other, or withdrawing one. Such an act shall, where appropriate, provide a minimum transitional period of 12 months — in particular where a category is added to class I or II, or moved from class I to class II — before the conformity assessment procedures start applying.

No delegated act under Article 7(3) exists as at 14 August 2026. When one appears, the whole portfolio has to be reclassified and the transitional period diarised.

The technical descriptions — Article 7(4)

Article 7(3) is not the only power over the annexes, and the other one has been used. Article 7(4) lets the Commission specify, by implementing act, the technical description of each Annex III and Annex IV category — and Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 does exactly that.

Its Annex I carries the technical description of every class I and class II category; its Annex II covers the three critical categories. It also gives illustrative examples of products whose core functionality meets each description — expressly not an exhaustive list, so a product absent from an example is not thereby outside the category.

That act is now the authoritative source for what each category means, and any CRA classification recorded before 1 December 2025 should be re-run against it.

Before CRA classification, qualify the product

Classification only matters if the product is in scope. Two scope questions are answered wrongly more often than any classification question.

Is your cloud back end part of the product? Article 3(1) includes remote data processing solutions in the definition of a product with digital elements. Article 3(2) sets the test: the software is designed and developed by the manufacturer or under its responsibility, and its absence would prevent the product performing one of its functions. One, not all. If both hold, the back end is inside the product boundary and every downstream obligation reaches it.

Are you selling a component separately? A software or hardware component placed on the market on its own is a product in its own right, whatever it is destined to be integrated into.

A worked CRA classification example

Take a password manager with a cloud synchronisation service, bundling an embedded runtime and a third-party cryptographic library.

• In scope — software product, direct logical connection, no Article 2 exclusion applies.
• The sync back end is inside the boundary — designed under the manufacturer’s responsibility, and without it cross-device synchronisation, one of the product’s functions, does not work.
• Annex IV — considered, rejected. Not a smartcard, secure element or security box.
• Class II — considered, rejected. No network protection or virtualisation function.
• Class I item 3, password managers — matches. This is what the product exists to do and how it is marketed.
• Class I item 1, identity and privileged access management — considered, rejected. Stores credentials for a single user; does not manage identities or privileged access for an organisation. Recorded because the boundary is arguable.
• Class I item 11, operating systems — considered, rejected. The embedded runtime is integrated, and under Article 7(1) integration does not propagate classification upward.
• Class I item 9, PKI — considered, rejected. Consumes certificates; does not issue them.

Determination: important, class I. On the standards position as at 14 August 2026 that means a notified body, unless the product qualifies as free and open-source software and its technical documentation is published at placing on the market under Article 32(5).

That determination, and what it costs, is worked through in CRA conformity assessment. The Regulation as a whole is covered in the EU CRA guide, and the deadline that arrives first — Article 14 reporting from 11 September 2026, which reaches products already on the market — in the CRA reporting deadline.

The EU CRA Toolkit carries the qualification and classification procedures with a per-category rationale record that captures the rejections as well as the match, and a substantial modification assessment for the changes that move a product between tiers.