Smart-home security products combine cybersecurity with physical-world consequences. A compromised account or API can unlock a door, suppress an alarm, expose a camera stream or interfere with monitoring. CRA implementation should therefore model device identity, household roles, remote control, local fallback, sensor and media data, cloud dependencies, ownership transfer and security updating as one product system. For products whose core functionality matches Annex III class I, the manufacturer must also apply the class I conformity-assessment rules.
Not Every Smart-Home Product Is Automatically Class I
Annex III class I category 17 is specific to smart-home products with security functionalities. Commission Implementing Regulation (EU) 2025/2392 describes these as products that protect consumers' physical security in residential settings and can be controlled or managed remotely, plus hardware and software that centrally control those products. A connected light bulb or convenience sensor should not be placed in category 17 solely because it operates in a home.
Smart Locks Turn Cyber Authorisation Into Physical Access
For a smart lock, authentication and authorisation directly control entry to a physical space. The security model should distinguish owner, household member, administrator, temporary guest and automation privileges; document local and remote unlock paths; protect credential enrolment and revocation; and test what happens when cloud connectivity, the companion application or a battery fails. The CRA does not mandate one lock architecture, so the evidence should show why the selected design manages the identified risks.
Security Cameras Add Confidentiality and Surveillance Risk
A security camera can expose live video, stored recordings, audio, location context and household activity. Product-specific analysis should map camera-to-cloud streams, local storage, account sharing, playback permissions, export functions and remote administration. Testing should verify that one household or tenant cannot access another product's media and that object-level API authorisation matches the intended account and device ownership model.
Baby Monitoring Systems Combine Availability, Privacy and Safety Context
Baby monitoring systems can combine cameras, microphones, speakers, environmental sensors and remote notifications. The threat model should consider unauthorised viewing or audio access, impersonation through two-way audio, loss or delay of monitoring, weak pairing and account recovery. Because the CRA category expressly includes baby monitoring systems, classification and conformity planning should be documented early rather than deferred until final product testing.
Alarm Systems Need Integrity Across Sensors, Control and Notifications
A connected alarm system can depend on sensors, a control panel or hub, local radio links, cloud services and mobile notifications. Security evidence should cover arming and disarming authority, sensor enrolment, anti-replay or message-integrity controls where relevant, tamper handling, loss of connectivity, notification paths and update behaviour. A secure cloud login alone does not demonstrate that the complete alarm chain resists manipulation.
Centrally Controlling Hardware and Software Can Fall in the Same Category
The 2025 technical description is not limited to the endpoint device. It also includes hardware and software that centrally control qualifying smart-home security products. A manufacturer of a security hub or control application should therefore analyse whether its core functionality places it in the Annex III category instead of assuming only locks, cameras or alarms are relevant.
General-Purpose Smart-Home Virtual Assistants Are a Separate Class I Category
Annex III class I category 16 separately lists smart-home general-purpose virtual assistants. The 2025 technical description covers products that communicate on the public Internet, process natural-language demands and provide access to services or control connected devices in residential settings. Manufacturers should distinguish that category from category 17 smart-home security products rather than combining all household control software into one classification bucket.
Model Household Roles and Shared Access Explicitly
Smart-home products are often intentionally shared. The security model should define primary owner, co-owner, resident, child or restricted user, guest, installer and service roles where relevant. Evidence should show how access is granted, limited, expired and revoked and what happens when the primary account is recovered or transferred. Shared use should be designed as an explicit authorisation model rather than implemented through password sharing.
Pairing and Ownership Transfer Are High-Risk Transitions
Commissioning binds a physical device to a person, household or cloud account, while resale or tenancy changes can require that relationship to be removed safely. Test how ownership is established, how local physical access affects claiming, whether previous users retain cloud permissions after reset and how stored media or credentials are erased. These transitions are especially important for locks, cameras and alarms because stale access can have immediate physical consequences.
Remote Commands Need End-to-End Authorisation
A remote unlock, camera configuration change or alarm disarm request may pass through an application, identity service, API gateway, message broker and device. The manufacturer should identify where the final authorisation decision is made and verify that identifiers cannot be substituted to control another household's device. Sensitive actions can also justify stronger re-authentication, notification or audit evidence according to the product's risk assessment.
Class I Changes the Conformity-Assessment Decision
For a product whose core functionality places it in Annex III class I, Article 32(2) applies. Internal control under Module A is available only within the conditions set by that Article, including the relevant role of harmonised standards, common specifications or qualifying European cybersecurity certification schemes. Where the relevant conformity references are not applied, are only partly applied or do not exist for the relevant requirements, the manufacturer must use Module B followed by Module C or Module H for those requirements.
Smart-Home Evidence Should Connect Cyber Controls to Physical Outcomes
A strong technical file should connect the cybersecurity risk assessment to real product behaviours: who can unlock a door, view a stream, silence an alarm, enrol a sensor, reset a device, transfer ownership or install firmware. Preserve device and app versions, cloud API behaviour, role definitions, pairing tests, security-update evidence, component records and the class I conformity-route decision so the security case can be reconstructed for the product placed on the market.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.