CRA product classes explained: default, important, critical — with examples

Every product in scope of the EU Cyber Resilience Act meets the same essential security requirements. What changes between "default", "important" and "critical" products is not what you must do — it is what you must prove, and who is allowed to check. And in 2026 there is a catch inside that distinction that most guides skip: the delayed harmonised standards are quietly deciding which companies will need a third-party assessment.

The three (really four) classes

The CRA sorts products with digital elements into a default category and two special lists:

Default. Everything in scope that is not on a list. The overwhelming majority of commercial software — B2B applications, most developer tools, most shipped components. Default products carry the full Annex I obligations (this surprises people: "default" is not "light"), but they can self-assess conformity using the internal control procedure, module A (Article 32(1)).

Important — Class I (Annex III). Products whose compromise hurts more because of their security function or their reach. The list is concrete, and worth reading because founders regularly discover themselves on it:

• identity management and privileged access management systems, including authentication readers
• standalone and embedded browsers
• password managers
• anti-malware software
• products with VPN functionality
• network management systems
• SIEM systems
• boot managers
• PKI and digital certificate issuance software
• physical and virtual network interfaces
• operating systems
• routers, modems and switches
• microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities
• smart home virtual assistants and smart home security products (locks, cameras, baby monitors, alarms)
• internet-connected toys with social or location features; certain wearables

Important — Class II (Annex III). A shorter, sharper list: hypervisors and container runtimes, firewalls and intrusion detection/prevention systems, tamper-resistant microprocessors and microcontrollers.

Critical (Annex IV). Hardware with security boxes, smart meter gateways, smartcards and secure elements. If you are here, you already have a regulatory team.

What class actually changes: the conformity route

Article 32 assigns each class its assessment options:

• Default: self-assessment (module A) — or the stricter routes voluntarily.
• Important Class I: here is the catch. Self-assessment is allowed only if you apply harmonised standards, common specifications, or an approved certification scheme in full (Article 32(2)). Otherwise: EU-type examination plus production control (modules B+C) or full quality assurance (module H) — both involving a notified body, i.e., a third party.
• Important Class II: third-party routes (B+C or H), or an EU cybersecurity certification at assurance level "substantial" (Article 32(3)). No pure self-assessment.
• Critical: a European cybersecurity certification scheme where mandated, with fallback to the Class II routes (Article 32(4)).

The 2026 catch: standards are late, and that changes your route

The harmonised standards that would let Class I products self-assess are still being developed at CEN/CENELEC, and their delivery timelines have already slipped. The practical consequence, rarely spelled out: until those standards are published and you apply them in full, a Class I product cannot use the self-assessment route — it needs a notified body. And the rules governing notified bodies only began applying on 11 June 2026 (Article 71), so designated bodies are only now emerging, with capacity that the entire market will compete for as December 2027 approaches.

If your product is on the Class I list, this changes your planning in two ways: watch the standards' publication like a hawk (their arrival may flip you back to self-assessment), and do not leave the notified-body conversation to 2027, when everyone else will be having it too.

Two special cases worth knowing

Open source on the important lists. Article 32(5) creates a pragmatic exception: manufacturers of products qualifying as free and open-source software that fall under Annex III categories may still use self-assessment (module A) — provided the technical documentation is made publicly available when the product is placed on the market. Transparency buys back the lighter route.

"My product is just software, surely classes are a hardware thing." Look at the Class I list again: browsers, password managers, VPNs, operating systems, SIEM, PKI software, anti-malware. Annex III is arguably more about software than hardware.

Common misreadings

Class is not a risk score — a default product with terrible security is still non-compliant, and a Class II product with excellent security still needs its third-party route. Class does not change the dates: reporting (11 September 2026) and full application (11 December 2027) apply to every class alike. And classification is self-executed but not self-invented: it follows the Annex III/IV category definitions, not your marketing copy.

→ Check your product's likely class — and everything else the CRA means for it — in two minutes. Free, with confidence level and cited sources.

---

This article is general information about Regulation (EU) 2024/2847, not legal advice. Sources: Regulation (EU) 2024/2847 (EUR-Lex, Official Journal) — Articles 32, 71 and Annexes I, III, IV; European Commission CRA guidance; status of harmonised standards per CEN/CENELEC standardisation updates. Last reviewed: August 2026.