CRA Compliance Checklist: Smart Home Devices
Default Class (self-assessment) — unless device functions as a gateway or identity management component
Smart home devices — thermostats, smart speakers, lighting controllers, home security cameras — are among the most common products with digital elements in scope for the CRA. Most will fall into the Default class requiring self-assessment, but devices with gateway functionality may be classified as Important Class I.
1. Scope & Classification
Confirm your device connects to a network (directly or via a hub)
Any device that can connect to another device or network is in scope. This includes devices that only connect to a local home network.
Determine whether your device qualifies as a gateway — if so, review Annex III Class I classification
Smart home hubs that route traffic between devices and the internet may be classified as Important Class I, requiring third-party audit.
Identify all software components and prepare a Software Bill of Materials (SBOM)
Required to demonstrate the 'no known vulnerabilities' requirement. Cover all open-source and third-party libraries.
Document the product's intended purpose and foreseeable misuse scenarios
Forms the basis of your cybersecurity risk assessment.
2. Product Security (Annex I Part I)
Scan all components against CVE databases before release — no known exploitable vulnerabilities
Use automated SBOM vulnerability scanning. Document results in the technical file.
Ensure device ships with secure default credentials — no hardcoded or universal default passwords
Each device must have a unique credential or force password change on first use. Universal default passwords are a common CRA violation for IoT devices.
Disable all unnecessary ports, protocols, and services by default
UPnP, Telnet, SSH, and other management protocols should be disabled by default unless essential to product function.
Implement authentication and access control for all device interfaces
This includes local network interfaces, cloud APIs, and Bluetooth pairing. Authentication must be enforced before granting access.
Encrypt data in transit (TLS 1.2 minimum) and sensitive data at rest
Device-to-cloud and device-to-app communication must be encrypted. Credentials and personal data stored on-device must be protected.
Implement a secure, verifiable over-the-air update mechanism
Updates must be cryptographically signed. The device must verify signatures before applying updates. Rollback protection is strongly recommended.
Log security-relevant events (failed logins, firmware updates, factory resets)
Logs must be tamper-evident and accessible for incident investigation.
Implement data minimisation — collect only data necessary for product function
Ties into GDPR obligations. Document what data is collected and justify each data point.
3. CVD Policy (Article 13)
Publish a publicly accessible Coordinated Vulnerability Disclosure (CVD) policy
The policy must be reachable from your product documentation or website. Link to it from your security.txt file.
Create a security.txt file at /.well-known/security.txt with contact and policy information
Required to make your vulnerability reporting contact discoverable. Include Contact, Expires, and Policy fields.
Establish a monitored channel for receiving vulnerability reports (email or submission portal)
This inbox must be monitored continuously — 48-hour acknowledgment is mandatory.
Document a process to acknowledge vulnerability reports within 48 hours
The acknowledgment does not need to confirm validity — just receipt. Set up auto-response as a backstop.
Document a safe harbour commitment protecting good-faith security researchers
Explicitly state you will not pursue legal action against researchers who follow your CVD policy.
4. Vulnerability Management (Annex I Part II)
Define and publish a security support period for each product model
The support period must be appropriate to the expected use life. For smart home devices, this is typically 5–10 years.
Establish a process to deliver security updates free of charge to all users
Security patches cannot be paywalled. All supported devices must receive updates regardless of user subscription status.
Set up a CVE registration process for vulnerabilities discovered in your products
Register as a CNA (CVE Numbering Authority) or work with a coordinating CNA to issue CVEs for your products.
Publish security advisories when vulnerabilities are fixed (CSAF 2.0 format recommended)
Advisories must be publicly accessible. Machine-readable CSAF 2.0 format is increasingly expected.
5. Article 14 Incident Reporting
Identify your national CSIRT contact point for Article 14 notifications
Each EU member state has a designated CSIRT. Know your contact before an incident occurs.
Document an internal escalation procedure for active exploitation events
When active exploitation is confirmed, you have 24 hours to file an early warning. Internal process must enable this.
Prepare an Article 14 notification template for the 24h/72h/14-day reports
Pre-preparing templates saves critical time during an incident. Include product info, vulnerability fields, and impact fields.
6. CE Marking & Conformity
Compile a technical file documenting all Annex I compliance evidence
Must include risk assessment, design documentation, test results, SBOM, CVD policy, and support period declaration.
Conduct and document a cybersecurity risk assessment for the product
Document threats, vulnerabilities, likelihood, and mitigating controls. This is reviewed by market surveillance authorities.
Draw up an EU Declaration of Conformity referencing CRA compliance
Must be signed by an authorised person and kept for 10 years. References technical file and conformity assessment procedure.
Affix CE marking to the product and/or packaging
CE marking cannot be applied until the DoC is complete and the technical file is in order.
Track your Smart Home Devices compliance progress in CVD Portal.
Public CVD submission portal, Article 14 deadline alerts, SBOM tracking, and CSAF advisory generation. Free forever for manufacturers.
Start your free portalFrequently asked
Does the CRA apply to smart home devices sold before September 2026?+
Products placed on the EU market before September 2026 are not immediately required to comply with the CRA. However, products that continue to be manufactured and sold after that date under new production runs will need to comply. Substantially modified products already on the market may also require reassessment.
Do I need a separate CVD policy for each smart home product?+
No. A single company-level CVD policy covering all products is acceptable. You can reference product-specific contact points within a single policy document.
What is the security support period for smart home devices?+
The CRA does not specify a fixed number of years. The support period must be 'appropriate to the expected use life' of the product. For smart home devices typically used for 5–10 years, a minimum 5-year support period is considered good practice. The European Commission is expected to provide guidance by product category.
Is a cloud-connected smart home app in scope for the CRA?+
The hardware device is in scope. The companion mobile app downloaded by users is also in scope as a software product with digital elements. Pure cloud services are generally excluded, but the downloadable app component is in scope.
Need a CVD policy for Smart Home Devices?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.