The Cyber Resilience Act product classification challenge
The EU Cyber Resilience Act (CRA) is steadily moving forward, and its reporting obligations are now live. As affected organizations plan their compliance roadmap, many are running into practical hurdles. One such task is categorizing products based on regulatory classifications.
For a company with just a few products, classification takes a few days of careful reading. But for an enterprise managing hundreds of product families, dozens of business units, and decades of legacy software, it becomes a major initiative in its own right.
In this article, I’ll share a practical portfolio framework that helps to establish defensible classifications for hundreds of products in weeks instead of quarters.
Why CRA product classification matters
Categorizing products with digital elements resolves three main questions for each item:
- Is it in the scope of regulation?
- Which class does it fall into?
- Which conformity assessment route does it follow?
That third answer is what ultimately dictates your timeline and compliance costs.
The CRA defines four main product categories: Default, Important Class I, Important Class II, and Critical. I covered the key distinctions between these in a previous article.
The binding technical definitions for Important and Critical products are laid out in Implementing Regulation (EU) 2025/2392, adopted on November 28, 2025.
An important aspect to consider is that classification hinges on a product's core functionality, not its individual components. It means that integrating an Important or Critical sub-component (like a secure element) does not automatically elevate the entire end product into that higher tier.
Another detail that often surprises portfolio managers: "placing on the market" applies to every individual unit shipped. A legacy model launched years ago that remains in production after December 11, 2027 must be compliant for every single unit shipped from that date forward.
Why portfolio scoping stalls – and how to move forward
Scoping an AI portfolio can be a challenging task, especially for large, decentralized organizations. Rather than getting bogged down by the legal text itself, they typically hit roadblocks across next common areas:
We address each bottleneck using a streamlined six-step classification framework. The core strategy is simple: spend minutes on obvious cases so you can focus expert hours where they matter most.
Consolidate product families
Combine individual product variants into broader families that share the same core functionality, hardware platform, and software baseline. Start with an export from your PLM or ERP system – don't worry if the data is incomplete at first, as you can refine it as you go. Each family needs a brief summary outlining key CRA attributes, such as operating system, firmware, codebase, connectivity, architecture, key features, and intended use. This condenses your catalog into a manageable list of core families far smaller than the total SKU count.
Pass 1: filter out what is not in scope
Go through the register with a simple yes/no checklist for each family:
- Does the product has digital elements or transfer the data? If no, it is out of scope.
- Is it covered by explicit CRA sector exclusions (e.g., medical devices, automotive, aviation, marine)? If yes, it is out of scope.
- Is it distributed or sold in the EU market? If no, it is out of scope.
- Will all shipments permanently end before December 11, 2027? If yes, it is out of scope (document this decision carefully, as roadmap schedules can change).
Be sure to evaluate remote data processing thoughtfully: companion apps or cloud endpoints often fall within scope, even if managed by a separate engineering team.
Pass 2: fast-track the clear default products
With core functionalities identified in step 1, compare them directly against the 26 Important and Critical product categories in Annex III and Annex IV of the EU CRA. If there is clearly no overlap, the business unit signs off using a standard rationale template. If there is a potential match or ambiguity, route the product to the next pass.
Pass 3: deep-dive the ambiguous and higher-class candidates
Any product that isn't clearly in the Default tier moves to an expert review queue. For each item, build a concise technical comparison against the official criteria in Implementing Regulation (EU) 2025/2392, paired with a recommended classification. This phase requires the most hands-on effort and cross-functional alignment.
Effective evaluations require a blend of expertise: deep technical knowledge of product capabilities, regulatory insight into legal interpretations, and, sometimes, legal judgment for complex edge cases.
Make decisions consistent and documented
Maintain clear, documented rationales for every assessment. As complex cases are resolved, capture outcomes and underlying logic in a central knowledge base. Teams can then apply these precedents to similar future cases.
Investing time in creating unified templates before these steps is highly recommended, as it streamlines the process and minimizes the effort required prior to a formal audit.
Prioritize and plan conformity routes
Rank the categorized product families based on regulatory risk level, overall business impact, and upcoming launch or shipping deadlines. This prioritization helps to define a clear compliance pathway, allocate budgets, and set schedules for each item.
At this stage, it makes sense to initiate conversations with external auditors or certifying bodies for high-risk or critical products, as third-party assessments often require significant lead time to book.
A product's classification reflects its current design and feature set. As functionality evolves, new capabilities added in later releases can easily push a product into a higher regulatory tier – a phenomenon known as "classification drift."
Defining portfolio families and product classes is a continuous, iterative process. Rather than conducting massive annual audits, integrate light classification checks directly into your ongoing product lifecycle and engineering workflows.
Typical triggers for re-evaluating a product family might include:
- Adding a new feature related to security, access control, or network management.
- Changing the intended use or target audience, such as shifting from consumer to industrial markets.
- Updating marketing claims, since how a product is described and sold clearly reflects its intended purpose.
- Adding new integrations such as companion mobile apps or cloud services.
- The publication of updated EU Commission guidance, implementing acts, or harmonized standards.
- Any substantial modification to a product that is already on the market.
However, each case requires nuanced review. Some changes can affect a product’s class, while others affect its scope or obligations without changing the class.
To get a quick preliminary estimate of your product's regulatory tier and compliance requirements, try our online Star assessment tool.
Common pitfalls in Cyber Resilience Act product classification
Our regulatory experts have run classification programs for enterprises of different sizes, spanning from industrial tech to consumer goods. What we have found is that regardless of the industry, the core challenges these organizations face are almost entirely universal.
These bottlenecks are common, but they are also avoidable. A clear, standardized approach to CRA product classification ensures you meet regulatory demands without slowing down your engineering and legal teams.
Where to start CRA product classification
This is exactly the case where perfection shouldn't delay progress. Start your Cyber Resilience Act product tiering process now by aligning your foundational product data and setting up a small, decisive review board. We typically begin by running a limited trial for our clients, such as a single production line. The key is to start small, build momentum, and establish repeatable patterns before scaling across the organization. Here are the immediate steps you can take to get moving:
- Select a pilot product line: Choose a single business unit or representative product family to test the six-step process. Running a quick pilot helps refine decision templates, iron out workflow bottlenecks, and build a baseline knowledge base of precedents.
- Introduce the six-step classification framework: Define and align the framework steps with your organization's operational activities, ensuring it fits naturally into existing engineering and product workflows.
- Form a cross-functional working group: Assemble a lightweight review team spanning engineering, legal/compliance, and product management.
- Scale with confidence: Use the pilot insights and documented rationales to roll out CRA product classification sprints across the rest of your business units, ensuring consistent evaluations across the entire portfolio.
How Star can help
If you're facing upcoming deadlines across a broad product catalog, Star can help streamline the path forward. We lead classification sprints for global manufacturers, turning raw product registers into fully documented, audit-ready classifications with clear conformity plans. In addition, we offer regulatory and compliance awareness training services designed to equip your engineering, legal, and product management teams with the practical knowledge needed to navigate EU Cyber Resilience Act requirements. Contact us for a scoping discussion to see how we can assist your team.
FAQ
A scalable approach to CRA product classification starts by grouping products into families with shared core functionality, hardware platforms, and software baselines. Teams can then screen each family against the CRA's scope and classification criteria, fast-track clear cases, and send ambiguous or higher-risk products for expert review. Standardized templates and documented decisions help maintain consistency across business units.
