How should manufacturers classify a product under the Cyber Resilience Act before planning compliance work?

Why Product Classification Comes First

The cyber resilience Act does not treat all products the same, so manufacturers need a defensible classification before they allocate engineering, documentation, and assurance work. The fastest mistake is to start with controls and only later discover that the product belongs to a stricter category with a different conformity path. That creates rework, delays launch, and can force a redesign of evidence, testing, and governance.

Classification should begin with the product’s intended use and core functionality, then be checked against the CRA’s Annex IV and Annex III lists, alongside the Commission’s published policy context in the EU Cyber Resilience Act. For teams still mapping the regulatory side, Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful because it shows how audit readiness depends on getting the scope right early. In practice, many manufacturers discover the wrong category only after they have already locked in product schedules and supplier commitments.

That matters because category assignment drives whether the product follows the default route or the more demanding important or critical path, which affects technical file depth, oversight expectations, and time to market. Security teams can also use broader risk evidence from the Ultimate Guide to NHIs — Why NHI Security Matters Now to explain why upstream classification is a governance decision, not just a legal checkbox.

How Classification Should Be Worked Through

The practical approach is to classify by function, not by technology stack. A product may contain the same cryptographic module, agent, or embedded service account as another product, yet still fall into a different CRA category because the regulated question is what the product does and how it is marketed. Current guidance suggests documenting the rationale in a traceable matrix so product, legal, security, and compliance teams can review the same evidence set.

A workable sequence is:

• Confirm the product is in CRA scope and identify the exact product version, not a family name.
• Map the primary purpose against Annex IV first, because those products are treated as Critical.
• If Annex IV does not apply, test Annex III to determine whether the product is Important Class I or Important Class II.
• If neither annex applies, record why the product remains Default and preserve the evidence.
• Translate the classification into the applicable conformity route, testing depth, and lead time.

For the control side of the conversation, the NIST Cybersecurity Framework 2.0 is a useful operational reference because it reinforces the idea that governance starts with asset understanding and risk categorisation. The same logic appears in NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where ownership and lifecycle clarity are prerequisites for safe management. If the product includes embedded connectivity, autonomation, or software update capability, it is worth cross-checking against Top 10 NHI Issues because hidden identity and access pathways can change the risk profile. These controls tend to break down when manufacturers classify a platform once at portfolio level, because individual SKUs, firmware variants, and regional bundles may have different CRA obligations.

Common Misclassifications and Edge Cases

Tighter classification discipline often increases upfront analysis cost, requiring organisations to balance faster product delivery against the risk of choosing the wrong conformity route. That tradeoff is real, especially when product teams want a simple “one class fits all” answer for a hardware platform, software appliance, or connected service bundle.

One common edge case is a product that looks benign in isolation but is marketed with security-sensitive functionality, such as remote administration, identity handling, update orchestration, or connectivity to critical infrastructure workflows. Another is a product family where only some variants fall into Annex III or Annex IV. Best practice is evolving here, but current guidance suggests documenting variant-level distinctions rather than assuming the entire line shares one outcome.

Manufacturers should also avoid treating component certificates, supplier claims, or legacy attestations as substitutes for CRA classification. Those inputs can support the analysis, but they do not replace a product-specific assessment. The broader risk picture is consistent with NHIMG’s research, including the 52 NHI Breaches Analysis, which shows how hidden access paths and weak lifecycle visibility can turn an apparently ordinary system into an exposed one. For standards context, CISA cyber threat advisories remain relevant for recognising how quickly product risk can shift once software is deployed in the field. The hard boundary appears when a manufacturer tries to classify a configurable platform without freezing the feature set, because the answer can change with the configuration, distribution channel, or update model.

Related resources from NHI Mgmt Group

• How should organisations prepare for Cyber Resilience Act compliance in product teams?
• Why do Cyber Resilience Act requirements create more risk for product teams than a simple deadline would?
• How should organisations control source-code access under the Cyber Resilience Act?
• Who is accountable when a device or software product fails to meet EU Cyber Resilience Act requirements?