Skip to main content
FOSSA Logo

CRA Product Classification Explained: Default, Important, and Critical

July 14, 2026 · 9 min read·Andy Drukarev
CRA Product Classification Explained: Default, Important, and Critical

Before you can CE-mark a product with digital elements, you have to know which EU Cyber Resilience Act (CRA) risk tier it falls into, because that decides whether you can self-assess or must bring in a notified body. This post explains how the CRA's four product classes work, lists the products the regulation names in Annex III and Annex IV, and walks through how to classify your own product.

Not sure which class applies to you? The free CRA Readiness Assessment walks you through classification and then assesses your readiness against the CRA's essential requirements for that tier.

Why Classification Is the First Thing to Get Right

The CRA applies to virtually every product with digital elements placed on the EU market, but it does not treat them all the same. It scales the obligations to the risk a product carries: a note-taking app and a firewall protecting critical infrastructure face very different conformity requirements.

Getting your class wrong can mean either over-engineering compliance or, far more dangerous, self-assessing a product that legally required an independent audit. And because the conformity assessment route affects how much lead time you need before the December 2027 full-compliance deadline, classification is the natural first step in any CRA program.

First: Confirm the CRA Applies at All

Classification only matters for products in scope, so start there. The CRA covers products with digital elements, meaning hardware or software (including their remote data processing solutions) made available on the EU market in the course of a commercial activity. A few boundaries are worth knowing:

  • Pure SaaS and cloud services are generally out of scope; they're regulated under NIS2 instead. The exception is a remote data processing solution: cloud functionality designed by (or on behalf of) the manufacturer that the product needs to perform one of its functions. That backend is in scope as part of the product.
  • Products covered by equivalent sectoral rules are carved out: medical devices under the MDR/IVDR, civil aviation equipment, motor vehicles under the type-approval regime, and marine equipment.
  • Products developed exclusively for national security or defence are excluded, as are spare parts made to the same specifications as the components they replace.
  • Non-commercial open source software is exempt. The regulation also introduces a lighter-touch open source software steward role for the foundations and organizations that sustain OSS used in commercial products, with proportionate duties focused on security policy and vulnerability handling. But integrating open source into a commercial product makes it your responsibility as the manufacturer, including SBOM and due-diligence obligations.

If your product is in scope, it lands in one of four classes.

The Four CRA Product Classes

Default Category

The large majority of products with digital elements: standard SaaS-connected devices, business software, web apps, photo editors, games, most smart appliances. Anything that doesn't have the core functionality of a category listed in Annex III or Annex IV falls here. The manufacturer can demonstrate conformity through internal control (self-assessment) against the Annex I essential requirements.

Important (Class I)

Products whose compromise has an elevated security impact, listed in Annex III. The categories include:

  • Identity management systems and privileged access management software and hardware, including authentication and access control readers
  • Standalone and embedded browsers
  • Password managers
  • Software that searches for, removes, or quarantines malicious software
  • Products with the function of a virtual private network (VPN)
  • Network management systems
  • Security information and event management (SIEM) systems
  • Boot managers
  • Public key infrastructure and digital certificate issuance software
  • Physical and virtual network interfaces
  • Operating systems
  • Routers, modems intended for the connection to the internet, and switches
  • Microprocessors, microcontrollers, and ASICs/FPGAs with security-related functionalities
  • Smart home general-purpose virtual assistants
  • Smart home products with security functionalities, such as smart door locks, security cameras, baby monitors, and alarm systems
  • Internet-connected toys with social interactive features or location-tracking
  • Personal wearables used for health monitoring or intended for children

Self-assessment is allowed only if the manufacturer fully applies the relevant harmonized standards, common specifications, or a European cybersecurity certification; otherwise a third-party assessment is required.

Important (Class II)

Higher-impact products, also listed in Annex III, where the regulation names four categories:

  • Hypervisors and container runtime systems that support the virtualized execution of operating systems and similar environments
  • Firewalls, intrusion detection systems, and intrusion prevention systems
  • Tamper-resistant microprocessors
  • Tamper-resistant microcontrollers

These always require a third-party conformity assessment by a notified body. Harmonized standards don't unlock self-assessment at this tier.

Critical

Products with systemic importance to the EU, listed in Annex IV:

  • Hardware devices with security boxes
  • Smart meter gateways within smart metering systems, and other devices for advanced security purposes including secure cryptoprocessing
  • Smartcards or similar devices, including secure elements

In addition to third-party assessment, the Commission can require these to hold a European cybersecurity certificate under an adopted certification scheme at assurance level "substantial" or higher.

Note that none of these lists are frozen: the Commission publishes technical descriptions for the Annex III and IV categories and can update the lists via delegated acts, so it's worth re-checking your classification as implementation guidance evolves.

How to Classify Your Product, Step by Step

In practice, classification comes down to four questions:

  1. Is it in scope? A product with digital elements, placed on the EU market commercially, not carved out by a sectoral regulation (see above).
  2. Does its core functionality match an Annex IV category? If yes, it's Critical. The test is the product's intended purpose and core functionality, not whether it merely contains a matching component.
  3. Does its core functionality match an Annex III category? If yes, it's Important, at the class the annex assigns (Class I or Class II).
  4. Otherwise, it's Default.

Two subtleties trip teams up. First, integration direction matters: a laptop doesn't become Class I because it ships with a browser, but the browser itself is a Class I product for its manufacturer. Second, intended purpose matters: a general-purpose microcontroller isn't automatically Class I; the security-related functionality has to be part of what the product is for. When your product plausibly straddles a boundary, document the reasoning behind the class you chose; that analysis belongs in your technical documentation either way.

What Each Tier Means for Conformity Assessment

The classification tier determines three practical things:

  • Who assesses conformity. The CRA reuses the EU's standard conformity modules: Default products (and standards-compliant Class I products) use Module A (internal control, i.e. self-assessment). Class II and non-standards-compliant Class I products need a notified body via EU-type examination (Module B + C) or a full quality assurance route (Module H). Critical products may additionally need a European cybersecurity certification.
  • How much lead time you need. Third-party assessments depend on notified body capacity, which is expected to be constrained as the December 2027 deadline approaches. If you're Class II or Critical, start early.
  • How much documentation rigor is expected. Every tier must meet the same Annex I essential requirements, including vulnerability handling, 24-hour vulnerability reporting, and a machine-readable SBOM in your technical documentation, but higher tiers face independent scrutiny of that evidence.

Find Your Class (and Your Gaps)

The free CRA Readiness Assessment walks you through product classification and then scores your readiness against the Annex I requirements for that tier, with a downloadable executive report and a prioritized 30/60/90-day remediation plan.

Launch the CRA Readiness Assessment

CRA Product Classification FAQ

What are the CRA product classifications?

The Cyber Resilience Act sorts products with digital elements into four tiers by risk: Default (the majority of products), Important Class I, Important Class II, and Critical. The tier determines the conformity assessment route a manufacturer must follow before affixing the CE marking.

What is the difference between Important Class I and Class II?

Important Class I products, such as password managers, VPNs, routers, and operating systems, can be self-assessed, but only if the manufacturer fully applies the relevant harmonized standards; otherwise a third-party assessment is required. Important Class II products, such as firewalls, intrusion detection/prevention systems, and hypervisors, always require a third-party conformity assessment by a notified body.

Which CRA products need a third-party conformity assessment?

Important Class II and Critical products require third-party involvement. Important Class II products need assessment by a notified body. Critical products may additionally be required to obtain a European cybersecurity certificate under an adopted certification scheme. Default and (standards-compliant) Important Class I products can be self-assessed.

Where are the CRA important and critical products listed?

The categories of Important products are set out in Annex III of Regulation (EU) 2024/2847, and Critical products in Annex IV. The Commission can update these lists via delegated acts, so manufacturers should track changes as the regulation is implemented.

Does the CRA apply to SaaS and cloud services?

Generally no. Pure SaaS and cloud services fall under NIS2 rather than the CRA. The exception is "remote data processing solutions": cloud functionality designed by or on behalf of the manufacturer that a product with digital elements needs to perform one of its functions is in scope as part of that product.

What if my product isn't listed in Annex III or Annex IV?

If a product with digital elements does not have the core functionality of any category listed in Annex III or Annex IV, it falls into the Default category. It must still meet all of the CRA's Annex I essential requirements, but the manufacturer can demonstrate conformity through self-assessment.

This post is directional guidance for planning, not legal advice; consult qualified counsel for a formal conformity determination. Primary sources: Regulation (EU) 2024/2847 (EUR-Lex), the European Commission's CRA policy page, and ENISA.

Subscribe to our newsletter

Get the latest insights on open source license compliance and security delivered to your inbox.