"Our smart fridge runs on Linux, so it is an important product class I under the CRA, because operating systems are on the list." I hear this regularly in advisory conversations. The logic behind it is understandable and still wrong. Because the Cyber Resilience Act classifies products not by their technical architecture, but by their core functionality.
How does the CRA classify products?
The Cyber Resilience Act (CRA) divides products with digital elements into four categories, each triggering different conformity duties.
Standard products form the broad mass. For them: self-assessment against the CRA baseline requirements, no mandatory third-party check. This covers most connected everyday devices, household appliances, simple IoT sensors, connected toys.
Important products class I include, per Annex III CRA, among others browsers, password managers, smart home products with security functions, and operating systems for general purposes (and here is the source of the misunderstanding). For important products class I a third-party conformity assessment may be required if no harmonised standards are used.
Important products class II, that is firewalls, intrusion detection systems, and industrial routers, require an external conformity assessment by a notified body.
Critical products finally, like certain hardware security modules or smart meter gateways, are subject to certification by ENISA (the EU Agency for Cybersecurity) or under a European cybersecurity scheme.
For the full overview see our CRA summary.
Why core functionality decides
The misconception arises because manufacturers read the lists in the CRA annexes as component lists, when they are actually product category lists. The difference is fundamental.
Take the smart fridge. It runs on an embedded Linux system, has a Wi-Fi connection, shows content on a touchscreen. Technically it contains a fully-fledged operating system. The question the CRA asks, however, is not: "Which components are built in?" It is: "What is the primary function of this product?"
The answer is unambiguous. The smart fridge cools food. The operating system is an aid. It enables networking, interface, and control, but it is not what the user buys the device for. Classification follows purpose, not architecture.
The clearest counter-example is the smartphone. Every modern smartphone integrates a fully-fledged operating system (Android or iOS), which as a standalone product would unambiguously fall into the important products class I category "operating systems for general purposes". And yet a smartphone is not an important product class I under the CRA. It is a standard product, because its core function is communication and application execution, not providing an operating system.
A different picture emerges for an industrial gateway used primarily as a network security component. It filters traffic, controls access, monitors connections, and as a side effect outputs temperature data. Here it would have to be seriously examined whether classification as an important product class II (firewalls, industrial routers) applies, because network control is the primary function.
EU guidance on the CRA is clear on this point. What is decisive is the intended use of the overall product, as it emerges from product description, marketing, and typical use.
Myth vs. fact
Myth: If a product integrates a component listed in the CRA annexes as important products class I or class II, for example an operating system, the overall product automatically inherits that classification.
Fact: The CRA classifies the overall product based on its core functionality. An integrated component that would have a higher class on its own does not automatically pull the end product up, as long as it does not define the primary function of the device. A smart fridge remains a standard product. A smartphone remains a smartphone.
Concrete consequences for product classification
Correct classification is not a formality. It decides which conformity assessment you must carry out, what costs arise, and what your market launch looks like. Three recommendations.
1. Define the core functionality in writing, from the user's perspective. What does someone buy when they buy your product? Phrase this sentence the way it would appear in your product manual or in an advertisement. This sentence is your starting point for classification and should be anchored in your technical documentation. Courts and market surveillance authorities will, in doubt, look exactly there.
2. Document your classification decision and its reasoning. The CRA leaves interpretive room in borderline cases. That is not a free pass for arbitrariness, but an invitation to careful reasoning. Record which annexes you checked, why you excluded which categories, and which function you classified as primary. This documentation protects you in market surveillance reviews and is anyway part of the technical documentation the CRA requires. For more on conformity assessment requirements, see our article on CE marking under the CRA.
3. Get a legal opinion for real borderline cases. Not every classification question is trivial. A connected device with access control function, an industrial PC with a firewall module, a smart home hub with a security sensor integration. Here the line between standard and important products class I can be fluid. The conformity duties differ significantly, as do the possible fines for misclassification. For more on sanctions, see our article on CRA penalties and fines.
What does this mean for your CRA roadmap?
The classification of your products is one of the first and most important steps in any CRA compliance roadmap, and determines how much time and resources you need to plan in.
For important products class I without harmonised standards, and for all important products class II, an external conformity assessment by a notified body is required. The capacity of these bodies is limited. Anyone starting late risks waiting times that endanger a timely market launch.
Two deadlines are particularly relevant here:
- 11 September 2026: The reporting duties for actively exploited vulnerabilities and severe security incidents enter into force, regardless of product class.
- 11 December 2027: Full CRA applicability kicks in. From that date, only compliant products may be placed on the market.
Anyone who has not yet finished classifying their product portfolio risks not starting the necessary conformity assessments in time. Our CRA compliance roadmap provides a structured overview of the necessary steps up to both deadlines.
Frequently asked questions
Does the classification principle also apply to software products? Yes. For software too, classification follows the primary function of the overall product. An application that primarily acts as a password manager is an important product class I, even if it offers simple notes functionality on the side. A word processor that contains an integrated password safe remains a standard product, as long as the password safe is a secondary function.
What happens if we misclassify our product? Misclassification can be treated as placing a non-compliant product on the market. That can lead to fines up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher. Market surveillance authorities can also order recalls. A conservative classification in doubt is therefore not caution, it is sound judgment.
Can a classification change due to a software update? In principle yes. If an update introduces a new core function, for example if a household appliance gains a primary security monitoring function, that can trigger a reclassification and a new conformity process. That is the core of the term "substantial modification" in the CRA. A change that fundamentally alters the security properties or the intended use of the product triggers the full conformity process anew.
Do we have to prove the classification to authorities? Yes. The technical documentation manufacturers must produce under the CRA also covers the justification of product classification. Market surveillance authorities can request this documentation. An undocumented or weakly justified classification is therefore a compliance risk, even if the classification is substantively correct.
How does the CRA treat products with multiple equivalent primary functions? This is a genuine grey area that the CRA does not fully resolve. EU guidance recommends, in such cases, treating the most security-relevant function as the decisive one, which in doubt leads to a higher classification. For true hybrid products I strongly recommend a legal opinion.
Conclusion
An operating system inside a fridge does not turn the fridge into an operating system, at least not in the sense of the Cyber Resilience Act. Classification follows the core functionality of the overall product, not the component list. That sounds simple but has far-reaching practical consequences. Wrong classification means wrong conformity assessment, wrong conformity assessment means regulatory risk.
Anyone wanting to take a structured approach to classifying their product portfolio should start early, not when the deadline is already approaching. A systematic CRA compliance platform helps document product classifications, manage conformity evidence, and monitor changes in the product portfolio on an ongoing basis. Start with a free CRA assessment and clarify where your products stand.
Every Friday I debunk a CRA myth here.