EU Cyber Resilience Act Guide for Smart Home Device Manufacturers

Smart home products with network connectivity and embedded software — smart plugs, bulbs, thermostats, doorbells, smart locks, home automation hubs, and security camera systems — are products with digital elements within CRA scope. Product classification depends on the device's function and data processing capabilities.

Default Class applies to simple connected accessories with limited data processing — a smart plug that enables remote power switching with no biometric data collection may be Default Class. Important Class I applies to devices that provide physical access control (smart locks), process audio or video inside the home (security cameras with cloud recording), or function as a network hub controlling other devices. Smart home hub devices that integrate with multiple third-party products and control home access or safety systems should be assessed as Class I. Manufacturers must document their classification rationale for each product SKU in the technical file.

Smart home devices have historically been among the most poorly secured connected products, with default credentials, unencrypted communications, and absent update mechanisms being widespread. CRA Annex I Part I directly targets these systemic weaknesses:

• Unique or no default credentials: Each device must either use a unique factory-assigned credential or require the user to set credentials at first use. Shared default passwords (e.g., admin/admin) are prohibited.
• Encrypted communications: All communications between the device, companion app, and cloud backend must be encrypted using current TLS standards. Local network discovery protocols must not expose sensitive device data.
• Automatic security updates: Smart home devices must support and enable by default automatic security updates. The update mechanism must be authenticated and tamper-resistant.
• Minimal data collection: Devices must not collect data beyond what is necessary for device function. Camera and audio data must be protected against unauthorised access.
• End-of-life communication: When a device reaches end of support, the manufacturer must notify users and must not disable security functionality in a way that leaves devices vulnerable.

Most smart home device manufacturers — particularly smaller brands and white-label manufacturers — currently lack a formal CVD policy. Security researchers routinely discover vulnerabilities in smart home products that go unreported or unacknowledged for months because no submission channel exists.

• Publishing a security.txt file at the brand domain (e.g., https://brand.com/.well-known/security.txt)
• Providing a submission channel accessible to non-technical users and researchers alike
• Responding to reports within a defined timeframe (best practice: 5 business days)
• Committing to security update publication and customer notification for resolved vulnerabilities

Brands operating under private-label or OEM arrangements must clarify which entity bears the Article 13 CVD obligation. If the brand places the product on the EU market under its own brand name, it is the manufacturer for CRA purposes, regardless of the actual hardware manufacturer. CVD Portal's intake and triage tools enable brands without dedicated security teams to manage this obligation operationally.

Smart home vulnerabilities attract significant attention from both security researchers and threat actors due to the privacy implications of compromised home cameras, locks, and microphones. Article 14 requires manufacturers to notify ENISA within 24 hours of becoming aware of active exploitation of a product vulnerability.

• Unauthorised remote access to device cloud accounts at scale
• Malware campaigns targeting the device (e.g., Mirai-variant infections)
• Researcher or law enforcement reports of active exploitation in the wild

The 24-hour ENISA notification must confirm the product and nature of the exploitation. The 72-hour detailed report provides technical content; the 30-day final report confirms remediation. For consumer-facing smart home products, manufacturer communication must also include direct customer notification through app push notifications and email — passive advisory publication is insufficient given that consumers may not check security advisory pages.

Default Class smart home products may use the internal conformity assessment procedure (Module A under Annex VIII). Class I products require third-party assessment. For brands relying on ODM/OEM manufacturers in Asia, the conformity assessment obligation sits with the EU market placer — the brand.

1. Obtain security documentation from the ODM/OEM that supports the Annex I technical assessment
2. Verify that the ODM's software stack meets CRA requirements or commission modifications
3. Maintain an SBOM for the product that reflects the actual components used
4. Ensure that post-sale update mechanisms are under the brand's control, not solely the ODM's

This creates a commercial pressure to restructure ODM relationships: brands must have contractual rights to require security patches, SBOM updates, and vulnerability notifications from their hardware suppliers throughout the product's supported lifetime. Sourcing from ODMs who are not CRA-ready will create ongoing compliance liability for EU-market brands.