CRA important products Class I are the product categories listed in Annex III whose primary function places them on a more demanding conformity route. Class II and critical products have additional third-party or certification requirements, while most default products can use self-assessment.
Start with primary function
Classification is not a judgment about whether a product feels risky. Start with the intended purpose and primary function, then compare it with the categories in Annex III and Annex IV. A secondary feature does not automatically decide the category, and a marketing label does not override the actual function. Record the rationale and any uncertain boundaries so the selected route can be reviewed.
| Class | Illustrative products | Conformity implication |
|---|---|---|
| Default | Ordinary smart plugs, lights, appliances, sensors, most apps | Self-assessment generally available |
| Important Class I | Routers, operating systems, VPNs, password managers, browsers, smart-home security products | Conditional self-assessment route; otherwise third party |
| Important Class II | Hypervisors, container runtimes, firewalls, IDS/IPS, tamper-resistant processors | Third-party conformity assessment |
| Critical | Hardware security boxes, smart meter gateways, smartcards | Applicable EU certification requirements need review |
These examples are an initial orientation. A product-specific classification should use the full annex wording, current specifications and the functions actually offered. Do not present a short quiz as a binding legal determination. If a family contains products with different primary functions, it may require more than one classification and conformity plan.
Smart home does not always mean default
Security cameras, smart door locks, baby monitors and alarm systems belong to the Class I smart-home security-function category described in the brief. An ordinary connected light or smart plug is typically a default candidate. A product that combines those functions needs a careful assessment rather than inheriting the classification of whichever feature is easiest to document.
Connected toys with interactive or location features and health or children’s wearables are also relevant Class I examples. Explain the intended user, data flows, security function and necessary remote processing. A change to the product’s intended purpose can change the classification analysis, so include the rationale in release and product-management review.
Class I is a conditional route
The Class I self-assessment route depends on fully applying the relevant harmonised standards, common specifications or other permitted route conditions. If the applicable conditions are not met, third-party involvement is required. Do not claim that a standards document is harmonised merely because a draft is available or because a related standard is used under another directive.
As of the October 2026 brief, no harmonised CRA standard is cited and the EN 40000 series is in drafting. Verify the current Official Journal position when making a real route decision. Draft standards can inform engineering work, but they do not automatically create the legal effect of a cited harmonised standard. Book external review early if the route depends on third-party capacity.
Class II and critical products
Class II includes product functions such as firewalls, intrusion detection and prevention systems, hypervisors and container runtimes, alongside the specified tamper-resistant processors. Third-party conformity assessment is required. The precise scope and evidence should be agreed with an appropriately designated body. Do not assume any security consultancy or testing lab can perform every statutory assessment.
Critical products in Annex IV require a review of the applicable EU cybersecurity certification arrangements and route. A generic security test report is not a substitute. Establish which scheme, assurance level and transitional arrangements apply to the product at the time of assessment. If those details are unresolved, keep the route as an open project dependency rather than inventing certainty.
Translate the class into a project plan
The selected route affects independent review, testing, timing and cost. Default products still need the essential requirements, risk assessment, technical documentation and continuing vulnerability-handling process. Self-assessment does not mean no evidence or no accountability. A Class I or Class II project may need the same engineering work plus external assessment coordination.
Roja prepares evidence and helps remediate product code; we do not certify products or act as a notified body. Test labs conduct agreed testing, and the relevant conformity body handles its authorised role. Check designation, accreditation and scope directly. The scope checker gives a first indication; the readiness assessment documents the actual reasoning and remaining questions.
Build evidence that survives a release
Begin with a named product and a reproducible release reference. A marketing model number is not enough when several firmware branches, mobile applications and remote services jointly implement its functions. Record the hardware revision, firmware version, build identifier and necessary remote processing. Decide which older versions remain supported. The CRA work should refer to this boundary consistently, so a reviewer can understand which product a statement describes.
Assign responsibilities before collecting documents. Engineering should own technical facts and remediation. A product owner should agree the intended use, support commitment and customer information. An incident contact should receive vulnerability disclosures and have the authority to escalate them. The manufacturer remains accountable for conformity and reporting even when an external team prepares evidence or drafts. Outsourcing a task does not transfer the underlying obligation.
Retain both the conclusion and the evidence that supports it. An applicability decision without a release reference becomes difficult to defend after a dependency upgrade. A technical file without its underlying test results becomes difficult to update. A useful record links the requirement, the artifact, the reviewer, the decision and its date. Keep open questions visible instead of marking an item complete because a template exists.
Common mistakes to avoid
Do not use a scan score as a compliance decision. Vulnerability matches can be incomplete or inaccurate, and a component version alone does not establish exploitability in the product. Equally, a finding that appears irrelevant needs a documented technical rationale. The evidence should explain whether the affected code is present, reachable and exposed through the supported configuration, and who reviewed that conclusion.
Do not confuse a project completion date with a continuing duty. New releases, new public vulnerabilities and changes to the intended use can change the evidence. Plan how the inventory, risk assessment and customer information will be updated. Check that the incident contact still works and that an on-call substitute can make decisions when the primary owner is unavailable.
Do not assume that company size or a non-EU address removes the obligations. The relevant questions include the product, the economic-operator role and how it reaches the EU market. A distributor, importer, authorised representative and manufacturer can have different responsibilities. Borderline interpretations need qualified review. This guide explains the engineering workflow and does not provide legal advice.
A practical review meeting
Bring the product owner, release engineer and security contact together with the current evidence. Walk through a single supported version rather than discussing a hypothetical future product. Ask which assumptions can be checked immediately, which require a build or test, and which require an external conformity or legal specialist. Finish with a short list of actions, owners and dates. A small, reviewed evidence set is more useful than a large unmaintained folder.
Use the CRA guide to connect this topic to the complete lifecycle. Review the product classes before choosing a conformity route, and connect the release SBOM to the Article 14 reporting workflow. If you need a starting inventory, the free Snapshot is a bounded first step.
Frequently asked questions
Is this a substitute for a product-specific assessment?
No. Use the guide to organise the engineering work. The product boundary, applicable legal interpretation and conformity route need a documented review.
Does a small team still need a process?
Yes. Assign a product owner, incident contact and substitute. The micro and small enterprise fine exception for 24-hour early warnings does not remove the duties.
Can Roja help with the practical work?
Yes. Our engineers validate inventory, triage findings, prepare reporting drafts and help build the technical evidence. The manufacturer reviews and remains accountable.
Where should we check the requirements?
Start with Regulation (EU) 2024/2847 on EUR-Lex and ENISA guidance for the Single Reporting Platform. Check the current text and your product facts before making a decision.
Sources
General engineering information, reviewed on the date above. Product-specific interpretations and current standards should be checked before a conformity decision. Roja helps manufacturers prepare for the Cyber Resilience Act. We do not certify products or provide legal advice.