CRA smart home devices are connected household products whose hardware, software and necessary remote functions fall within the Cyber Resilience Act product scope. A smart plug is usually a default-class candidate, while smart-home products with security functions, including security cameras, smart locks and baby monitors, are Class I examples.
Start with the actual product function
| Product | Likely class | Important qualification |
|---|---|---|
| Ordinary connected light or plug | Default | Confirm the intended primary function |
| Security camera | Class I | Smart-home security-function category |
| Smart door lock | Class I | Self-assessment is conditional on the applicable route |
| Baby monitor or home alarm | Class I | Review product functions and Annex III wording |
This is an orientation, not a classification decision. A shared chipset does not make all models legally identical. Record whether the family includes a hub, device firmware, a mobile application and required cloud processing. A camera that depends on remote analysis may need that remote function included in its product-boundary review. Manufacturers outside Europe have the same scope question when selling in-scope products into the EU.
Embedded stacks and evidence
Yocto and Buildroot products need release-linked package inventories and evidence for vendor patches. ESP-IDF and Zephyr builds need a review of modules, bundled sources and configuration-dependent inclusion. Android-based devices can combine an operating-system image with application code. Companion apps and necessary remote services should be documented according to the agreed boundary. Do not describe one firmware scan as evidence for the entire connected system.
Radio products also need a separate review of RED cybersecurity obligations and relevant EN 18031 standards. That route already matters under the delegated act from 1 August 2025 and does not automatically establish CRA conformity. Coordinate evidence where it is reusable, but record the legal purpose of each assessment. Testing, statutory conformity assessment and engineering remediation have distinct owners.
Illustrative scenario: a connected door lock
This scenario is illustrative, not a customer case. A small manufacturer ships a lock with an ESP-IDF controller and a companion application. The team has no dedicated security function. The first review identifies the security-function Class I category, checks the role of the remote service and produces a build-linked inventory. Engineers then triage findings against the actual enabled functions rather than treating every component match as exploitable.
The next workstream reviews secure onboarding, credentials, update authenticity, availability and secure deletion. A product owner agrees the support-period rationale. The incident contact practises the reporting workflow and user communication. Where the chosen conformity route requires third-party involvement, the team plans it early with the relevant body. No conclusion of conformity is claimed from the illustrative scan or the existence of a document template.
Make the customer-facing commitment workable
Consumers need to know the support end date at purchase and receive usable security-update information. A device may remain in a home for years after the first sale, so plan the supported-release inventory and distribution records. Keep access to signing infrastructure and update servers under controlled ownership. Review what happens if an application is discontinued or a remote service changes, and document how that affects the product’s functions and security responsibilities.
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.