Connected Toys, Smart Locks, and Health Wearables: Why Your Consumer IoT Product Is Probably "Important" Under the CRA
General guidance only, not legal advice. The correct conformity assessment route for your specific product depends on its design, intended use, and classification. Consult a qualified expert or notified body for formal decisions.
Key points
- The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024, with full application from 11 December 2027. Reporting obligations start earlier - 11 September 2026.
- Connected toys with interactive or location features, smart-home security devices (smart locks, cameras, baby monitors, alarm systems), and health wearables are Important Class I products under Annex III - not the default tier that covers roughly 90% of products.
- Commission Implementing Regulation (EU) 2025/2392, adopted on 28 November 2025 and in force from 21 December 2025, provides the technical descriptions that translate the CRA's high-level Annex III/IV labels into criteria you can apply when designing, documenting, and launching a product.
- Your tier determines your conformity route, not whether the security requirements apply - those apply to everyone.
- For Important Class I, you can self-assess only if you fully apply relevant harmonised standards. As of mid-2026, no CRA harmonised standard has yet been published in the Official Journal, so the presumption of conformity under Article 27 is not yet available for any product category. Many Class I makers should plan for a notified body route now.
The tier that catches consumer IoT makers off guard
Most manufacturers of connected consumer products assume they are in the CRA's default tier - the self-assessment lane used by the vast majority of products. For a smart plug, a connected coffee machine, or a basic fitness tracker that counts steps, that assumption is probably right.
But for a significant slice of the consumer IoT market, it is wrong. The CRA's Annex III lists categories of "important" products that carry a higher conformity bar. The problem, until recently, was that Annex III used high-level labels - "smart-home security devices", "toys" - without defining what those terms actually meant in engineering terms.
Implementing Regulation (EU) 2025/2392 closes that gap. It provides precise technical descriptions for all 26 named product categories across the important and critical tiers, making classification a functional test rather than a guessing game.
The classification principle is straightforward: what does the product's core functionality do? Ancillary features do not change the answer. A product that embeds a browser to display content is not a "browser" under the CRA. A router that includes firewall functionality is still a router. What matters is the primary function the product was designed and marketed to perform.
Classification is not a feature checklist. It turns on design intent and core functionality. A product is subject to the conformity assessment procedures for important or critical products if its core functionality matches the technical description of a category in Annex III or IV — not because it happens to include a component that would, on its own, fall into a higher tier.
Which consumer products land in Important Class I?
The implementing regulation's technical descriptions confirm what many in the industry suspected. The following product types are explicitly in scope for Important Class I:
Smart-home security devices - The regulation names smart door locks, camera systems, baby monitoring systems, alarm systems, and sensors when their core functionality is security-related. If your product's primary job is to control access, monitor a space, or raise an alert, it is almost certainly here.
Connected toys with interactive or location features - Internet-connected toys that have interactive capabilities (voice, video, responsive play) or that track a child's location fall into Class I. A basic toy that simply connects to an app to download content may not; one with a microphone, camera, or GPS almost certainly does.
Personal health wearables - Wearables designed for health monitoring, or wearables intended for use by children, are in Class I. A general-purpose smartwatch that happens to count steps sits in a different position from a device whose core function is monitoring heart rate, blood oxygen, or other health metrics.
Four ETSI draft standards cover these consumer categories under the M/606 mandate: EN 304 631 (smart home virtual assistants), EN 304 632 (smart home security-functional devices), EN 304 633 (connected toys), and EN 304 634 (personal wearables) - all Important Class I.
A worked example
Take an interactive connected toy aimed at children aged 4-8. It has a microphone for voice interaction, a camera for facial recognition during play, and a companion app that tracks the child's location when the toy is taken outside.
Its core functionality is interactive, location-aware play. That maps directly to the implementing regulation's description of connected toys with interactive or location-tracking capabilities. The toy is Important Class I. The manufacturer cannot self-assess unless they fully apply the relevant harmonised standards - and as those standards are not yet published in the Official Journal, they should be planning for a notified body assessment or tracking standard availability very closely.
What "Important Class I" actually means for conformity
The tier does not change what security requirements apply - it changes how you prove you meet them.
| Default | Important Class I | Important Class II | |
|---|---|---|---|
| Conformity route | Self-assessment (Module A) | Self-assess if fully applying harmonised standards; otherwise notified body | Notified body — mandatory in all cases |
| Harmonised standards available? | Drafts in progress | Drafts in progress — none yet in OJ | Drafts in progress — none yet in OJ |
| Practical route today | Self-assessment | Notified body (standards not yet in OJ) | Notified body |
| Examples | Smart plugs, basic IoT sensors | Smart locks, baby monitors, connected toys, health wearables | Firewalls, IDS/IPS, tamper-resistant microprocessors |
The key constraint for Class I makers right now is the standards gap. The self-assessment shortcut is only available when you "fully apply" the relevant harmonised standards. CEN, CENELEC, and ETSI accepted Standardisation Request M/606 in April 2025 and committed to delivering 41 harmonised standards, with the first horizontal standards and vertical drafts targeting around Q3 2026; a vulnerability-handling standard is slated for around August 2026. Until those standards are published in the Official Journal, the presumption of conformity they would provide does not exist.
That means most Important Class I manufacturers face a practical choice: engage a notified body now, or build a compliance programme that is ready to pivot to self-assessment the moment the relevant standard is published and cited in the OJ. Either way, waiting is not a strategy - full CRA application is 11 December 2027, and notified body capacity is finite.
For Class II products (firewalls, IDS/IPS, tamper-resistant microprocessors), there is no self-assessment option regardless of standards. See our conformity assessment and notified bodies guide for detail on engaging a notified body and what to expect from the process.
The security requirements: same for everyone, but especially visible for Class I
Tier determines your conformity route. The essential requirements in Annex I apply regardless of tier. For consumer IoT makers, the ones that most commonly surface as gaps are:
No weak default passwords. Every device must ship with a secure-by-default configuration. Shared default credentials - the same password on every unit of a product line - are explicitly prohibited. Each device needs a unique credential, or the product must force the user to set one on first use.
Secure update mechanism. Security updates must be delivered free of charge across the support period. The update mechanism itself must be authenticated and integrity-protected. A toy or camera that cannot receive a firmware update over the air, or that delivers updates without signature verification, does not meet this requirement.
Support period. The CRA presumes a minimum support period of five years unless the expected product lifetime is shorter. For a connected toy or baby monitor, five years is a reasonable baseline. Document the support period explicitly - it must appear in your technical documentation and be communicated to users.
Coordinated vulnerability disclosure (CVD) policy. You must publish a contact point for security researchers to report vulnerabilities, and you must have a process for handling those reports. A security.txt file or a published CVD policy page is the minimum. The reporting obligations that start in September 2026 require you to notify ENISA of actively exploited vulnerabilities within 24 hours of becoming aware.
SBOM. Annex I, Part II requires a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies of the product. The SBOM lives in your technical documentation (Annex VII, retained for 10 years) and must be available to market surveillance authorities on request. The CRA does not mandate a specific format, but CycloneDX and SPDX are the two established formats that satisfy the machine-readable requirement. A PDF or spreadsheet does not.
Start your SBOM in your build pipeline, not as a documentation exercise. A hand-crafted SBOM drifts from what you actually ship. Automate generation with tools like Syft, Trivy, or cdxgen so every release produces a fresh, signed SBOM that can be matched against CVE feeds the moment a new vulnerability is disclosed.
How to work out your tier: a practical process
If you prefer to work through it manually, the logic is:
- Read Annex III of the CRA and the technical descriptions in Implementing Regulation (EU) 2025/2392. Annex III lists the high-level categories; the implementing regulation gives you the functional criteria.
- Apply the core-functionality test. What is the primary function your product was designed and marketed to perform? Not what components it contains - what does it do?
- Consider integrated components carefully. Embedding a component that would itself be Class I or II does not automatically elevate your product's tier. What matters is whether the product as a whole has the core functionality of an important or critical category.
- Document your reasoning. Whether you conclude Default or Important, write down how you reached that conclusion, which Annex III categories you considered, and why you ruled them in or out. This reasoning belongs in your technical documentation.
What to do next
If you are Important Class I:
- Engage a notified body early. Capacity is limited and lead times are real. Our conformity assessment guide covers what to expect.
- Track the harmonised standards programme. When the relevant vertical standard (e.g. EN 304 632 for smart home security devices, EN 304 633 for connected toys) is published in the Official Journal, you may be able to switch to a self-assessment route - but only if you fully apply it.
- Start the Annex I essentials now: eliminate default passwords, build a secure update mechanism, define your support period, publish a CVD contact, and generate your SBOM.
If you are Default:
- Self-assessment is your route, but the same Annex I requirements apply. Use the time before December 2027 to build the Article 13 risk assessment, technical documentation, and SBOM infrastructure.
If you are unsure:
- Use the decision tree above as a starting point, then read the implementing regulation's technical descriptions for the categories closest to your product. When in doubt, the conservative assumption is that you are Important Class I - it is easier to step down than to redo a conformity assessment.
Further reading on CRA Facts
- CRA product classes: Default, Important, Critical - the full tier breakdown
- Conformity assessment and notified bodies - what a notified body assessment involves and how to prepare
- Article 13 risk assessment guide - the document that underpins your technical file
- Key deadlines at a glance - September 2026 reporting, December 2027 full application
- Scope checker - confirm whether your product is in CRA scope at all
Official sources: Regulation (EU) 2024/2847 · Commission Implementing Regulation (EU) 2025/2392 · European Commission CRA page
Stay on top of every CRA development - standards citations, Commission acts, notified body news - by subscribing to The CRA Brief, our free weekly digest. Sign up at cra-facts.com/subscribe.
Related reading
You Put Your Name on It. The CRA Makes You the Manufacturer.
If you sell a connected product under your own name or trademark in the EU, the Cyber Resilience Act treats you as the manufacturer - regardless of who built it. Here's what that means and what to do.
The CRA Authorised Representative (Article 18): What It Is, What It Isn't, and Whether You Need One
Under the Cyber Resilience Act, appointing an EU authorised representative is optional - unlike MDR or RED. Article 18 explained: what the mandate must cover, what it cannot delegate, and why non-EU manufacturers often appoint one anyway.
CRA Transitional Provisions: Do You Have to Re-Certify Products Already on the Market?
Already selling connected products into the EU? Here's exactly what the CRA's transitional provisions mean for legacy inventory - and the one obligation that applies to everyone right now.