Your CRA conformity assessment route depends on product classification. Default products can usually use internal control. Important and Critical products may need a Notified Body or, for Critical products when the regulation's specific conditions are met, an EU cybersecurity certificate.
Summary
- CRA classification starts with scope: the product must have digital elements and a direct or indirect logical or physical data connection to a device or network.
- Products with core functionality listed in the Important-product list are Important products, split into Class I and Class II.
- Products with core functionality listed in the Critical-product list are Critical products.
- Default products can use internal control, based on Module A.
- Important Class I products can stay with internal control only when the relevant standards, common specifications, or certification schemes are fully applied.
- Critical products use either the certification route or, where that route is not available and applicable, the standard third-party routes.
Tip: As a working estimate rather than a CRA-stated figure, about 90% of products fall into the Default category. Check the Critical and Important lists first. If your product is not listed, you are usually Default.
Start here only if the product has digital elements and a direct or indirect data connection.
The highest-risk tier. A "yes" here means certification or one of the third-party assessment routes.
These products usually need a third-party or certification route.
This tier also covers identity systems, SIEM, PKI, network interfaces, security-enabled chips, certain toys, and certain wearables.
For a quick first-pass scope screen, use the free CRA applicability checker. Treat the result as a starting point, then document the legal classification separately.
The four CRA product categories
The CRA classifies products with digital elements into four tiers based on cybersecurity risk: Default, Important Class I, Important Class II, and Critical. Tier assignment turns on whether the product's core functionality matches the Important and Critical product lists.
Internal control based on Module A is available when the product is otherwise in CRA scope.
No Important or Critical core-functionality match.Module A remains available only with full use of the relevant standards, specifications, or schemes.
Important Class I list.Use Module B+C, Module H, or an applicable certification scheme.
Important Class II list.Use certification when certification conditions are met; otherwise use the third-party assessment routes.
Critical list.Default products
The vast majority of products fall here. If your product is in CRA scope but its core functionality is not listed in the Important or Critical product lists, it is Default.
Conformity assessment: Self-assessment (Module A) is sufficient.
Examples:
- Simple IoT sensors
- Basic consumer electronics
- Standard business software
- General-purpose applications
- Embedded devices whose intended purpose or reasonably foreseeable use includes a data connection but no Important or Critical core functionality
Important Class I
Products with elevated risk due to their function or user base.
Conformity assessment: Internal control is available only if you fully apply the relevant harmonised standards, common specifications, or European cybersecurity certification schemes at assurance level at least substantial. Where those do not yet exist, or you do not fully apply them, use Module B+C or Module H.
Full Important Class I list:
- (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 digital elements 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 the connection to the internet, and switches
- (13) Microprocessors with security-related functionalities
- (14) Microcontrollers with security-related functionalities
- (15) Application specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) 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 (e.g. speaking or filming) or that have location tracking features
- (19) Personal wearable products to be worn or placed on a human body that have a health monitoring (such as tracking) purpose and to which Regulation (EU) 2017/745 or (EU) No 2017/746 do not apply, or personal wearable products that are intended for the use by and for children
Important Class II
Higher-risk products requiring mandatory third-party assessment.
Conformity assessment: Use Module B+C, Module H, or, where available and applicable, a European cybersecurity certification scheme at assurance level at least substantial.
Full Important Class II list:
- (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
Critical products
The highest-risk category covers hardware devices with security boxes, smart meter gateways and other advanced security devices, and smartcards or similar devices.
Conformity assessment: Use the certification route where certification conditions are met. If those conditions are not met, use one of the third-party assessment routes.
Full Critical list:
- (1) Hardware Devices with Security Boxes
- (2) Smart meter gateways within smart metering systems as defined in 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
Conformity assessment routes by category
Each tier maps to a specific set of conformity-assessment modules: Default normally uses internal control, Important Class I can use internal control only with full standards or scheme coverage, Important Class II uses a third-party or certification route, and Critical uses certification where available or the fallback third-party routes.
Internal production control is available when the product has no Important or Critical core-functionality match.
Notified Body: not requiredUse Module A only with full standards, common specifications, or certification scheme coverage. Otherwise use Module B+C or Module H.
Notified Body: required when Module B+C or H is usedUse a third-party route, or an applicable European cybersecurity certification scheme at assurance level at least substantial.
Notified Body: required for B+C or H; scheme rules apply for certificationUse the certification route when certification conditions are met. Otherwise use the third-party assessment routes.
Notified Body: depends on the available routeModule A is internal control: technical file, EU Declaration of Conformity, CE marking. No external auditor involved.
Module B+C splits the work: a Notified Body examines a type specimen and issues a certificate (Module B); the manufacturer then ensures all production conforms to that type (Module C).
Module H replaces the product-by-product approach with an audit of the manufacturer's quality management system. Better suited when you have a large product portfolio.
For Critical products, certification is not an add-on to Module B+C or Module H. It is the Critical route where certification conditions are met; otherwise, the product uses the third-party assessment routes.
Classifying products that fall into multiple categories
Not every product is a clean fit. These are the most common edge cases.
Multi-function products
Rule: Focus on the product's core functionality. A product whose core functionality matches an Important-product category is Important, but integrating a Class I component into a host product does not, by itself, make that host Important.
Example: A smart home hub that includes:
- Basic automation control (Default)
- VPN functionality (Important Class I)
- Security camera integration (Important Class I)
Classification: Important Class I if the VPN or security-camera functionality is part of the product's core functionality.
Embedded components
Rule: Consider whether security-relevant components are placed on the market separately or give the host product the core functionality of an Important-product category.
Example: A consumer device containing:
- General-purpose microcontroller → Default
- Microcontroller "with security-related functionalities" → Important Class I
Key question: Does the microcontroller perform security functions (encryption, authentication, secure boot)?
Intended-use considerations
Several listed categories specify intended use or product context, for example items referencing "connected toys covered by Directive 2009/48/EC" or health monitoring wearables that reference Regulations 2017/745 and 2017/746.
If your product could be used in these contexts but isn't specifically intended for them, the classification may not apply. Document your intended use clearly.
Operating systems
Operating systems are listed in the Important Class I list. The practical question is whether the product placed on the market is an operating system, or whether firmware is only part of a wider product whose core functionality is something else:
| OS Type | Classification |
|---|---|
| Operating system placed on the market as a product | Important Class I |
| Firmware inside a wider product | Classify the wider product by its core functionality |
Example: A custom Linux distribution sold as an operating system is Important Class I. Firmware inside a simple connected sensor may still leave the sensor in Default if the sensor has no Important or Critical core functionality.
Software vs hardware
Classification considers the product as placed on the market:
- Standalone software: Classified based on software function
- Hardware with embedded software: Classified based on combined functionality
- Software component sold separately: Classified independently
Industry-specific guidance
Many IoT devices are Default unless their core functionality matches a listed category.
- VPN functionality: Important Class I
- Smart home security devices: Important Class I
- Tamper-resistant security features: Important Class II
Most software is Default unless the product itself provides a listed function.
- Browsers, password managers, anti-malware: Important Class I
- Firewalls and IDS/IPS: Important Class II
- Operating systems: Important Class I
Classification depends on the security function and how the component is placed on the market.
- Check security functions in processors and microcontrollers
- Check whether the component is sold separately
- Check whether the security function is core to the product
Products covered by MDR or IVDR are excluded from CRA scope. Companion software or non-medical functions may still need a separate CRA scope analysis.
Common classification mistakes
Important: Classification is based on product function, not market sector, company size, or product complexity. Always check the Important and Critical product lists.
A smart door lock sold to consumers can still be Important Class I because classification follows function, not target market.
Business or industrial use does not lower the tier. Classification still turns on CRA scope and the Important or Critical core-functionality lists.
Size and complexity do not determine classification. A small security microcontroller may be Important Class I, while a complex product without listed functions may be Default.
ISO 27001 is an organisational security-management standard. CRA classification and conformity assessment remain product-specific.
Product classification checklist
- Product has digital elements and a direct or indirect data connection
- Product will be placed on the EU market
- Product is not covered by one of the sector or security exclusions
- Hardware device with a security box
- Smart meter gateway or other advanced security device
- Smartcard or similar device, including secure elements
Any match means Critical.
- Hypervisor or container runtime system
- Firewall, intrusion detection, or prevention system
- Tamper-resistant microprocessor or microcontroller
Any match means Important Class II.
- Review the full list of 19 categories
- Check multi-function implications
- Check security-related functionality in components
Any listed category match means Important Class I.
- Product is in CRA scope
- No Important or Critical core-functionality match
- Classification rationale is documented
No listed-category match means Default.
- Module A for Default, or Class I with full standards, specifications, or scheme coverage
- Module B+C or H for Class I without full coverage, Class II, and Critical fallback routes
- Certification conditions for Critical products
Frequently Asked Questions
Does a smart home router fall under Important Class I or Default?
Important Class I is the likely classification. Routers intended for connection to the internet are in the Important Class I category. Internal control remains available only if the relevant harmonised standards, common specifications, or certification schemes are fully applied; otherwise, use Module B+C or Module H. See CRA conformity assessment routes.
Does the CRA apply to SaaS products with no physical hardware?
It depends on whether the software is a product with digital elements in CRA scope. A remote data processing solution is covered when it is designed by or under the responsibility of the manufacturer and is necessary for a product with digital elements to perform a function. Scope also requires a direct or indirect logical or physical data connection to a device or network.
If my product has both Default and Class I functions, which category applies?
The higher tier wins when the higher-risk function is the product's core functionality. A product whose core functionality matches the listed Important-product categories takes the Important tier. Simply integrating a Class I component into a host product does not, by itself, escalate that host to Important-product conformity routes. Document why the listed function is or is not core to the product placed on the market.
Does ISO 27001 certification affect my CRA product classification?
No. CRA classification is determined by the product's core functionality against the Important and Critical product lists. ISO 27001 addresses organisational information security management; it does not change whether a product is Default, Important Class I, Important Class II, or Critical under the CRA. See CRA vs ISO 27001.
When does CRA product classification need to be determined?
Determine classification before placing the product on the EU market. Classification sets the conformity assessment route that supports the EU Declaration of Conformity and CE marking. Manufacturers must complete conformity assessment before making the product available as compliant. See the CRA implementation timeline.
Where do I find a Notified Body for CRA conformity assessment?
Use NANDO as the live registry for designated Notified Bodies. CRA-specific designations are still being published, so check directly for bodies designated under Regulation (EU) 2024/2847. Important Class I products need a Notified Body only when the manufacturer cannot rely fully on the relevant harmonised standards, common specifications, or certification schemes.