Product-specific CRA work begins with architecture rather than labels. The manufacturer should establish what is placed on the market, which software and remote services are part of the product, what interfaces and trust boundaries exist, which Annex I requirements apply to the actual risks, whether the product's core functionality places it in an important or critical category, and what evidence demonstrates the resulting security decisions. These guides focus on those differences instead of repeating a generic CRA checklist.
Start With the Product Boundary, Not the Marketing Name
CRA analysis should begin by identifying the hardware or software product placed on the Union market and the remote data processing solutions that form part of the product definition. A commercial label such as IoT platform, smart appliance or enterprise software does not determine the legal boundary on its own. The manufacturer should identify the supplied product, embedded software, companion components and manufacturer-controlled remote processing that the product depends on to perform its functions.
Connection Architecture Changes the Security Problem
Products with digital elements can communicate directly or indirectly with devices or networks. Product-specific implementation should document physical interfaces, local wireless links, Internet connectivity, cloud APIs, administrative channels, update services and companion applications. Those paths create different attack surfaces and determine where authentication, confidentiality, integrity, resilience and secure-update controls need to operate.
Core Functionality Drives Annex III and Annex IV Classification
A product is not classified as important or critical merely because its marketing category sounds security-sensitive. The CRA classification rules look to the product's core functionality and the categories in Annexes III and IV. Commission Implementing Regulation (EU) 2025/2392 adds technical descriptions for those categories, making product-function analysis central to the conformity route.
The Same Annex I Requirement Can Need Different Engineering
Annex I applies across product categories, but the implementation evidence should match the actual architecture and risk. Authentication for a smart lock involves device ownership, household roles and remote actuation. Authentication for desktop software may focus on account sessions and privileged local functions. Secure updating for embedded equipment can involve bootloaders, signed firmware and recovery paths, while a cloud-connected application may rely on staged software deployment and service rollback.
Remote Services Can Be Part of the Product Security Case
Where manufacturer-controlled remote data processing is designed and developed for the product and its absence would prevent the product from performing one of its functions, that remote processing can fall within the CRA product definition. Product-specific reviews should therefore map cloud control planes, device registries, remote APIs and other dependencies rather than assessing only the physical device or downloadable client in isolation.
Component Risk Looks Different Across Product Types
An IoT device may depend on a radio stack, bootloader, real-time operating system and cloud SDK. A desktop product may depend on package ecosystems and operating-system APIs. An industrial controller can combine proprietary firmware, fieldbus libraries and hardware components. The CRA vulnerability-handling case should preserve product-specific component inventory, dependency relevance and remediation paths instead of relying on one generic software inventory process.
Support and Updating Must Match the Deployment Model
The practical support obligation changes with how products are deployed and maintained. Consumer connected devices may remain unattended in homes for years, while enterprise software can be centrally managed and industrial equipment can have tightly controlled maintenance windows. The manufacturer should document how security updates reach the actual installed base, what user action is required, what happens when an update fails and how supported versions are identified.
Product Evidence Should Reconstruct a Real Release
A product-specific technical file should allow a reviewer to reconstruct the security state of the product actually placed on the market. That can include architecture, interfaces, trust boundaries, component versions, security requirements, test results, update mechanism, risk-treatment decisions, conformity classification and the relationship between device, application and remote service versions.
Conformity Assessment Depends on Classification and Standards Coverage
Products outside the important and critical categories can generally use the Article 32 route available to their category, while important and critical products have stricter pathways. For class I products, availability and full application of relevant harmonised standards, common specifications or qualifying certification can affect whether internal control is available. Product-specific classification should therefore happen before the manufacturer commits to an assessment plan.
Use Product Guides as Engineering Maps, Not Legal Shortcuts
A product guide can identify likely interfaces, risks and evidence patterns, but it cannot replace the product's own cybersecurity risk assessment. Two products sold under the same commercial category can have different architectures, remote dependencies and core functionalities. Manufacturers should use the product-specific pages to structure analysis and then verify the final conclusion against the Regulation and current technical descriptions.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.