How to Classify IoT Products under the CRA

CRA categories with IoT context

CRA category classification hinges on whether your product is Default (Class I), Important (Class II) (Annex III), or Critical (Annex IV). The Commission can amend Annex III and will publish technical descriptions for the Annex III/IV categories, so IoT manufacturers should treat classification as a living process, something to revisit as acts and schemes evolve.

All classes must meet the same 13 essential cybersecurity requirements in Annex I. Your classification only changes how you prove it: self-assessment for lower risk (Article 32(1), Annex VIII Module A), and mandatory third-party assessment for higher risk (Article 32(2)–(4), Annex VIII Modules B+C or H, or a European cybersecurity certification scheme). The depth of Annex VII evidence you need to show also increases with risk.

Conformity assessment modules (Annex VIII, in plain English):

• Module A – Internal Control: the self-assessment route where you ensure compliance, prepare technical documentation, apply the CE mark, and issue the declaration of conformity.

• Module B – EU-Type Examination: a notified body assesses your technical design and vulnerability handling and issues a certificate if compliant.

• Module C – Conformity to Type: you manufacture in line with the certified design from Module B and keep the CE/DoC in order.

• Module H – Full Quality Assurance: a notified body audits, approves, and regularly surveils your entire quality system for design, development, production, and vulnerability handling (its ID appears with the CE mark).

• European cybersecurity certification schemes (Article 32(1)(d), (4)): third-party certificates (assurance level at least “substantial”) that, once available, can be used instead of B/C/H.

Products move into Important when they primarily perform cybersecurity-critical functions (e.g., authentication, endpoint or network protection) or central/system functions whose disruption could affect many other products or user safety (e.g., network management, virtualisation, some data processing roles). These are the simplest signs that an IoT element sits above Default.

For IoT stacks, Annex III explicitly names building blocks you likely ship or integrate, operating systems, routers/modems/switches, network management systems, boot managers, PKI/digital certificate issuance, VPNs, browsers, password managers, and microprocessors/microcontrollers/ASIC/FPGAs with security-related functionalities. Smart-home security devices and assistants appear too. If your device includes these functions, classification often escalates beyond Default.

• For Important “Class I” products: third-party conformity assessment (Annex VIII Modules B + C or H) is mandatory (Article 32(2)).

• For Important “Class II” products: third-party assessment is always mandatory (Article 32(3), Annex VIII Modules B+C or H, or certification at “substantial” level).

• For Critical products (Annex IV): third-party assessment is always mandatory, either through a European cybersecurity certification scheme once designated, or (until then) via the third-party modules used for Class II (Article 32(4), Annex VIII).

Annex IV lists Critical categories; for these, the Commission can require a European cybersecurity certification (e.g., EUCC) at an assurance level of at least “substantial”, but only after an EU scheme exists and is formally designated for that category. Until a scheme is designated, conformity must be demonstrated via Annex VIII third-party routes (Module B+C or Module H). Once a scheme is designated and a certificate is obtained, it provides a presumption of conformity for the covered requirements.

Core vs. supporting functionality

Think of “core functionality” as the capability a buyer expects your product to deliver on day one and rely on throughout its life. That judgement flows from the intended purpose and reasonably foreseeable use/misuse you define, plus how you present the product in datasheets and marketing.

If security is what you’re selling, regulators will treat it as the core. If security is merely supportive (e.g., encrypted transport for a temperature probe), that alone doesn’t move you out of Default. Use the rules below to avoid over- or under-classifying mixed-purpose devices.

• Advertised capability = core If your datasheet markets outcomes like “prevents intrusions”, “manages credentials”, or “protects endpoints”, treat those as primary security functions and expect them to be important unless you can clearly justify otherwise.

• Aggregation ≠ automatic category upgrade An IoT hub that only aggregates/forwards data can remain Default. The same hub could become Important if it manages network configuration, routing, or access control (i.e., central/system functions).

• Cloud/control plane counts If a cloud or control-plane service is necessary for the product to perform its intended purpose and is provided by/for the manufacturer (e.g., device management backend, policy/credential orchestration), evaluate that functionality—this often nudges the product toward Important.

• Embedded Annex III component ≠ automatic category upgrade Shipping a secure element, OS, crypto library, or MCU with security features does not by itself move the whole device to Important; escalate only if the product’s core purpose is that Annex III/IV function (e.g., credential manager, PKI issuer, VPN gateway).

Need a practical overview of what the Cyber Resilience Act requires? Visit Tributech’s CRA Guide to navigate all essential requirements, implementation details, and regulatory alignment with confidence.

Triggers for reclassification

Classification isn’t a one-time ceremony. It’s a standing control to revisit when the product meaningfully changes. A useful heuristic: if a release changes what users can safely do or introduces functions that sit in Annex III/IV, pause and re-run the decision. Reassess when the product’s role expands into security-critical or central/system functions, when the intended purpose shifts, or when supportive security features become primary. Reclassification is also relevant if normal operation starts to depend on a control plane or cloud service provided by/for the manufacturer.

Classification readiness checklist

Make CRA classification part of your product architecture, not an afterthought. Keep it lightweight, repeatable, and tied to every release. Focus on:

• Define core functionality: Write down what the product is supposed to do (intended purpose and foreseeable use/misuse).

• Map functions to product classes: Compare against Annex III and Annex IV. If your product or subsystem performs a listed security-critical or central/system function, record whether it falls into Default, Important I, Important II, or Critical.

• Note regulatory updates: Classification isn’t static. The Commission can amend Annex III/IV and publish new technical descriptions. Keep a watch on these changes and be ready to adjust classification.

• Build your CRA map: Document your product’s class and link it to the right conformity assessment route (Module A, B+C, H, or EU certification). This tells you whether self-assessment is enough or if third-party partners (e.g. notified bodies, certification authorities) are required.

• Plan next steps: Once the CRA map is clear, identify the external partners you’ll need (testing labs, notified bodies, certification schemes) and build your timeline around them. Ensure that your own assessment is verified, either through your compliance department if the expertise exists in-house, or by engaging a consultant specialized in CRA.

After that, you can move on to broader CRA obligations like support-period planning, SBOMs, and supplier due diligence.

From Compliance to Advantage

Treat classification as a design control, not an afterthought. Define intended purpose and foreseeable use, map product functions against Annex III/IV, and keep evidence proportional to risk and class. Use Annex VII documentation as a living file that evolves with each release, and verify the classification whenever core functions or dependencies change. Build the Declaration of Conformity and CE path early to align technical, legal, and design decisions.

By integrating classification into development planning, you achieve predictable launches, fewer audit surprises, and stronger customer trust, turning CRA compliance into a measurable advantage.