Does the Cyber Resilience Act apply to our IoT device and what must we do?
Most connected devices follow the default self-assessment route under module A, but certain consumer categories listed in Annex III are important products with stricter conformity routes, so the first decision is which group your product falls into. The full obligations apply from 11 December 2027, while the Article 14 reporting duty for actively exploited vulnerabilities and severe incidents applies from 11 September 2026, and it reaches products already on the market whenever they were placed there. If a customer, retailer or regulator is asking for CRA compliance now, the reporting duty is the date that matters most for your current stock. Your organization owns the controls, the risk assessment, the technical documentation and the evidence that goes with them. An implementation partner such as DeployOpen can prepare the systems, build-and-release pipeline, update infrastructure and documentation against the Annex I requirements, but that work does not make the product compliant on its own. Where a notified body is required, only that independent body can issue a certificate. Before you request a quote, confirm with your conformity lead whether any of your products match an Annex III category as described in Implementing Regulation (EU) 2025/2392, since that determines whether you need outside assessment at all.
Ask any implementation partner for a written scope that names each device family, its classification and the evidence it will produce, so you can see what is owned internally and what is prepared externally. Confirm with the vendor and your legal team how your cloud backend is treated under the guidance, because a manufacturer-designed cloud service used to exchange and store device data may count as remote data processing even when it runs on third-party infrastructure. Read the official text in Regulation (EU) 2024/2847 on EUR-Lex and the Annex III categories before you commit budget, so that your scope decision rests on the regulation rather than on a supplier's summary.
Which consumer IoT products are important products under the CRA?
Most consumer connected devices fall in the default category, but several consumer categories named in Annex III are important products with stricter conformity routes. Core functionality decides the category, so each product should be checked against the category descriptions before the conformity route is chosen.
Smart home virtual assistants
Annex III lists smart home virtual assistants in class I. A device that is mainly a voice assistant for controlling a home, rather than a general-purpose speaker with a voice feature, is likely to sit in this category. Check whether the core function is the assistant itself, how it processes voice data and which cloud services it depends on. Confirm the classification against the technical description in Implementing Regulation (EU) 2025/2392 before choosing a conformity route.
Smart home security cameras and locks
Door locks, cameras, baby monitors and alarms that are sold as smart home security products are named in class I. A manufacturer of a connected lock or camera should not assume a general consumer gadget label settles the question, because the core function is what counts. Document the security function, the access paths to the device and the remote services it uses, then compare these against the category description.
Internet-connected toys with social or location features
Connected toys are important products when they have social or location features. A toy that only plays prerecorded audio is treated differently from one that lets children talk to other users or reports where the child is. Map each feature to the category wording, and record which features are optional, since a toy's variants may fall in different categories.
Health-monitoring and children's wearables
Annex III covers certain health-monitoring wearables and children's wearables in class I. The boundary depends on what the wearable does and for whom, so a fitness band, a medical-grade sensor and a child locator may land in different places. Confirm with the technical description whether the device's core function matches a listed category, and note that health-related data also brings GDPR and sector rules into view.
Microprocessors, microcontrollers and FPGAs
Component makers should check whether chips such as microprocessors, microcontrollers, ASICs and FPGAs with security-related functionality are named in class I. Device makers who buy these parts still need to know the component's category, because it shapes what they can rely on. Ask suppliers for the classification of each security-relevant part and for the evidence supporting it, and record that evidence in the technical file.
Core functionality decides the category
The category follows the product's core functionality, not its marketing name or a single feature. A connected device with a small listed function may still be in the default category if that function is not central to what it does. Write a short classification memo for each product that states its core function, the category wording it was matched against and the reasons for the decision, then keep it with the technical documentation.
How secure by default and factory reset shape the device design
Annex I Part I point (2)(b) requires that a connected device is made available with a secure by default configuration, and that it can be reset to its original state. The only exception is a tailor-made product where the manufacturer and the business user agree otherwise. For a consumer IoT maker, that exception rarely applies, so the factory state of the device is the product's security baseline from the first power-on. The design team therefore has to settle three decisions early: whether any default credential exists at all (the usual answer is a unique credential generated per device or a forced setup step on first use), which network services the device exposes out of the box (listening ports, debug interfaces, local APIs and cloud endpoints that should be off until a user enables them), and how the reset path works, including what it wipes, what it keeps and who can trigger it.
The evidence an assessor will look for is a documented configuration baseline for each product variant. It should list every default setting, every enabled service and every credential mechanism, with the reason each one is set that way. Pair it with reset test records: repeatable tests on production firmware showing that a reset removes user data, paired account links, stored keys that the user owns, and any changed settings, and returns the device to the documented baseline. Keep the test logs tied to firmware version and hardware revision, because a reset that works on one build can fail on the next. Also confirm how the reset interacts with the cloud side. If the device is reset but the cloud account still holds an active binding, the user's data may still be exposed, and the test should cover that case.
Ask your implementation partner and your conformity assessment body to agree the baseline format before firmware freezes, not after. Confirm with your notified body or harmonized standard owner how they expect reset and default-state tests to be documented, since the Commission's guidance and the standards work under standardization request M/606 may refine expectations. Checking this early avoids redesigning a credential flow late in the cycle, which is the most expensive form of rework for a connected product.
Automatic updates: what point (2)(c) requires for consumer devices
Point (2)(c) of Annex I Part I expects a product to let vulnerabilities be fixed through security updates. Where that applies, automatic security updates should be enabled by default, and the user should be able to switch them off through a clear and easy opt-out. For a connected camera or door lock, this means the device ships with updates on, the setting is visible in the app or on the device, and turning it off takes a few steps rather than a support call. Your product team owns the default and the opt-out flow. Your platform team owns the signed update pipeline behind them.
- Default state: Confirm that the factory configuration enables security updates, and record the setting value in the build configuration so the default can be shown to an assessor.
- Opt-out path: Document the steps a user takes to disable automatic updates, and test that the opt-out works on every supported hardware variant and app version.
- Scope of automatic updates: Decide which update types install automatically. Security fixes are the core, and feature updates are a separate decision you should document.
- Integrity checks: Show that each automatic update is signed and verified on the device before installation, with failed checks logged.
- Rollback behavior: Record what happens when an automatic update fails, including whether the device returns to the last working version.
Before relying on defaults, confirm with your technical documentation and risk assessment which update types you treat as security updates and how the opt-out interacts with support obligations.
Where users manage updates themselves, or where a device has been configured to ask first, point (2)(c) expects the user to be told that an update is available. The notice has to be clear enough that a householder understands it is a security fix, not a cosmetic change. The notification mechanism is part of the product, so it needs test cases, logs and a defined owner, just like the update itself.
- Notice content: Make each notification state that a security update exists and what it addresses at a level the user can understand, without exposing exploit detail.
- Delivery channels: Specify the channels used, such as an app push, an on-device indicator or an email, and test delivery on each one.
- Escalation for unpatched devices: Define how long a device may remain on a vulnerable version before the user is reminded again, and record the reminder schedule in your design documents.
- Test records: Keep test results showing that notices appear for a seeded update on each supported model and firmware branch.
- Delivery telemetry: Where privacy rules allow, record aggregate counts of notices shown and acted upon, so you can show the mechanism works in the field.
Check with your privacy team how telemetry is collected, since logging who saw a notice can involve personal data under the GDPR.
Point (2)(c) also expects the option to temporarily postpone updates. For consumer devices, this matters when a user is in the middle of using a device, such as a baby monitor during a night feed or an alarm system during a holiday. The postponement must be temporary and bounded, so the device does not stay unpatched indefinitely. Designing the limit is a product decision, and it should be justified in your risk assessment.
- Bounded postponement: Set a maximum postponement period and show it to the user, so the choice is informed and does not become a permanent exemption.
- Re-prompting: Define when the device asks again after the postponement ends, and test that the prompt returns on schedule.
- Safety-critical functions: Decide whether a postponed update can be forced for a critical fix, and document the reasoning for that choice.
- Test cases: Test postponement on every supported firmware branch, including the case where the device loses connectivity during the postponement window.
- Audit trail: Log each postponement and the eventual installation, so the record shows the mechanism behaves as designed.
Ask your legal or compliance team to confirm the postponement limits against your own risk assessment, since the appropriate period depends on the device's function and threat model.
An assessor will not accept a description of update behavior alone. They will look for test evidence that each mode works as designed, and for records showing how updates behaved in the field. For a self-assessment under module A, the manufacturer keeps this evidence in the technical documentation and must be able to produce it on request from a market surveillance authority. Design the tests before the first release, not after an incident.
- Test matrix: Map each update mode (automatic, notification, postponement) against each supported model, firmware branch and app version, and record the pass or fail result for each combination.
- Negative tests: Test failed signatures, interrupted downloads, and a user who opts out, and show that the device refuses or flags the outcome correctly.
- Field metrics: Track the share of devices on the current security version over time, using whatever telemetry your privacy assessment allows, and review the trend regularly.
- Release records: Keep a record of each security update, its release date, the vulnerability it addresses and the devices it reached.
- Retention: Keep these records for the support period, which must be at least five years for most products, as set out in Article 13(8).
Agree the test plan and record format with whoever will perform your conformity assessment, so the evidence matches what they will ask for.
The update channel is not just a feature of the device. It is a cloud service, a signing process and a set of third-party dependencies that together deliver every security fix. Point (2)(c) depends on the channel working for the whole support period, so its design belongs in the same review as your cloud and supply chain decisions. The Commission guidance treats cloud functions that a manufacturer designs for a product as part of that product's data processing, even when they run on third-party infrastructure.
- Signing keys: Define who holds the signing keys, where they are stored and how a compromised key would be rotated without bricking devices in the field.
- Hosting dependencies: List the cloud and content delivery services that serve updates, and confirm how their availability and security are assured under contract.
- Component updates: Track the third-party libraries inside the device and the update image, so a fix in a dependency can reach devices through the same channel.
- Capacity and fallback: Plan for a large update wave, including a fallback path if the primary delivery service is unavailable.
- Reporting link: Connect the update channel to your vulnerability handling process, so that a fix can be published and reported on the same timeline.
Confirm with your architects and any outside implementation partner which parts of the update service you run, which you buy, and which evidence each provider can supply.
When cloud functions count as remote data processing
A manufacturer's own cloud functions can fall within the CRA even when they run on someone else's infrastructure. The Commission's guidance uses a smart thermostat to show this. The app and the device exchange and store data through cloud functions that the manufacturer designed, and those functions are treated as remote data processing solutions (RDPS) even though they run on a third-party infrastructure-as-a-service (IaaS) provider. In that illustrative case, the cloud layer is part of what the manufacturer must secure and support, not a separate service that sits outside the product. Hosting location does not decide the question. Who designed the functions and what they do for the product does.
For the connected device team, this changes the supplier evidence to collect. The guidance indicates that the manufacturer could ask the IaaS provider for evidence that the provider meets its obligations under NIS 2, the EU directive on cybersecurity for essential and important entities. Ask the cloud provider for its NIS 2 compliance evidence, its security certifications, its incident notification commitments and its arrangements for patching the underlying services. Record the answers in the technical file, and confirm with your provider whether it will supply them under contract. Plan for the cloud layer to be covered by your vulnerability handling process, your support period and your reporting duties under Article 14, which apply to in-scope products whenever they were placed on the market.
Confirm the reading with counsel before you rely on it. Map each cloud function to the product's core functionality, document which functions store or process device data, and agree in writing which party operates, patches and monitors each layer. Whether a given backend is RDPS depends on the specific architecture and the Commission's current guidance, so treat the thermostat example as one illustration rather than a ruling on your product. Your legal team and any notified body or assessor you engage should confirm the classification and the evidence set in writing.
How long must we support the device?
This sequence turns the Article 13(8) support period rule into a documented, defensible support period for each product model. The output is a written decision that engineering, product and compliance can point to when a customer or market surveillance authority asks how long updates will continue.
Confirm the product is in scope
Start by confirming that the device is a product with digital elements placed on the EU market and that the support period duty applies to it. Product management and compliance should record the product name, model variants and the market placement date. The step is complete when each model that will carry the CE marking has a named owner and an entry in the product register. Scope is confirmed before any support period is set, so the decision does not rest on an unverified assumption.
Estimate the expected use time
For each model, estimate how long a typical customer will keep the device in service. Consider the product category, its physical lifespan, how it is installed and how customers actually use comparable devices. Product management leads this estimate, with input from engineering and customer support on return rates and field data. The output is a single expected use figure per model, written in years, with the reasoning attached.
Apply the five-year minimum
Under Article 13(8), the support period must be at least five years. If the expected use time is shorter than five years, the support period must match that expected use time instead. Compliance records which rule applies to each model. The check that closes this step is a comparison of the expected use figure with the five-year floor, recorded as the starting support period for the model.
Test for longer periods in long-lived products
Commission CRA FAQ 4.5.2 says longer support periods are expected for products usually used for more than five years, such as routers and modems, along with other long-lived categories. For connected devices in these groups, engineering and compliance should check whether the expected use time points beyond five years. Record the conclusion, even if it is that the five-year floor applies. Confirm the reading with the Commission FAQ and, if the product is borderline, with a legal adviser before the period is fixed.
Document the basis for the period
Write a short support period record for each model. It should state the period in years, the expected use estimate and its evidence, the rule applied (five-year minimum or expected use time), and the FAQ reference if a longer period was chosen. Compliance owns the record and approves it. The step is done when the record is versioned, signed off and stored with the technical documentation for the product.
Plan updates across the full period
Match the support period to a release plan that covers the whole period. Engineering should map the security update cadence, the dependencies that need patching, the end-of-life dates of third-party components and the cloud functions the device relies on. Where a backend or third-party service may end before the device support period does, record a fallback. The output is a support roadmap that shows how updates will be delivered in each year covered by the period.
Publish the period to users
Make the support period visible to customers at the point of purchase and in the product documentation, using the wording approved in the record. Compliance checks that the published statement matches the documented period for every model. The step closes when the statement is live on the product pages and in the user manual, and the version in each location is logged against the record.
Review the period on each substantial change
Revisit the support period record whenever the product is substantially modified, a new model variant is launched, or the expected use estimate changes materially. Product management and compliance decide whether the period changes and update the record and the published statement together. Ask your conformity assessment body or legal adviser to confirm how the Commission guidance on substantial modification applies to your change before you rely on it.
When the default self-assessment route applies and when it does not
Most connected devices reach conformity on their own. A product that does not match a category in Annex III or Annex IV is in the default category, and the manufacturer may use internal control under module A, which means preparing the technical documentation, performing the Annex I risk assessment, drawing up the EU declaration of conformity and affixing CE marking without a third party reviewing the file. For a smart thermostat, a connected kettle or a fitness tracker with no social or location features, the first decision is therefore a classification check: compare the device's core functionality against the Annex III descriptions in Implementing Regulation (EU) 2025/2392 and record the reasoning in the technical file. The Annex III text is the starting point for that comparison.
Self-assessment stops being the default for some consumer devices. Under Article 32(2), a class I important product can use module A only where the manufacturer has applied in full harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial. If the manufacturer has not applied them in full, module B with module C, or module H, brings a notified body into the conformity assessment. Smart home security products such as door locks, cameras, baby monitors and alarms, and internet-connected toys with social or location features, fall in class I, so their makers should decide early which route applies. Confirm the current status of the harmonized standards under standardization request M/606 with the European standardization organizations and the Commission CRA FAQ, since several deliverables were still pending at the time of writing.
Plan for the cost and timing consequences before choosing a route. A notified body is paid for its assessment, and its availability and fees depend on the product and the market, so ask the bodies listed in the Commission's NANDO system for written scope and timelines before committing to a launch date. Ask your implementation partner to map which harmonized standards your device can fully apply, because partial application pushes the product off module A. Note that a notified body route does not replace the manufacturer's own duties: the organization still owns the risk assessment, the documentation and the support obligations.
What drives the cost and effort of CRA compliance for a device line
The cost of CRA compliance for a connected device line depends less on the device itself than on how many variants you ship, who supplies its components, how much cloud service sits behind it, and how mature your evidence already is. Each card below is a driver you can check against your own line before you ask anyone for a quote.
Number of product variants
Each hardware revision, regional model, firmware branch and feature-differing SKU can count as a separate product for conformity purposes, and each needs its own technical documentation, risk assessment and EU declaration of conformity. A line with many variants multiplies the same evidence work. Ask your implementation partner and your assessor to confirm early how they will group variants, because that grouping decision drives most of the effort in the first assessment cycle.
Number of component suppliers
Every third-party module, chipset SDK, radio stack and open-source library in the firmware is part of what you must document and monitor for vulnerabilities. Suppliers that cannot provide software bills of materials or update commitments add cost because you must either obtain that information or replace the component. Inventory your suppliers and record which ones can supply component data and security update commitments before you scope the work.
Cloud footprint behind the device
Cloud functions that exchange and store device data are treated as remote data processing of the product, even when they run on a third-party infrastructure provider. Each cloud service you rely on adds design review, access control evidence, logging, and supplier assurance to the scope. Map every backend service, region and managed component that the device depends on so the scope reflects what you actually operate.
Whether a notified body is needed
Most products follow self-assessment under module A. A notified body becomes necessary for class I important products where harmonized standards, common specifications or certification schemes are not applied in full, and for class II and critical products. Whether your product is in the default category, class I or class II changes both the assessor and the price range. Confirm the classification against Annex III and the technical descriptions in Implementing Regulation (EU) 2025/2392 before you commit budget.
Evidence maturity
Teams with a documented secure development lifecycle, a vulnerability handling process, tested update mechanisms and retained build records need far less new work than teams starting from informal practices. Gaps in threat modeling, default configuration testing, or update signing usually take the most engineering time. Review your existing evidence against the essential requirements and note which items already exist as records, not just as intentions.
Who is paid for what
Your internal engineering team owns the product, its controls and its ongoing security work, and that cost recurs for the support period. An implementation partner, if you hire one, prepares systems, documentation and evidence for a fixed written scope. Tooling, such as SBOM generators and vulnerability tracking, has license or hosting costs. A notified body, where required, charges for its own assessment and is independent of your partner. Ask each party to state in writing which items are one-time and which recur.
Questions IoT makers ask about CRA compliance
Is my consumer gadget an important product under the CRA?
It is if its core functionality matches a category listed in Annex III, and many consumer devices do. Class I covers smart home security products such as door locks, cameras, baby monitors and alarms, smart home virtual assistants, internet-connected toys with social or location features, and certain health-monitoring or children's wearables. It also covers microprocessors, microcontrollers, ASICs and FPGAs with security-related functionality, which matters if you ship a component others build into their products. The category is set by core functionality, not by price or marketing, so a simple plug with no network features will usually fall in the default category. Check the technical descriptions in Commission Implementing Regulation (EU) 2025/2392 against your product's actual functions before deciding.
Is self-assessment enough for a connected device?
For most connected devices, yes, but only if the product is in the default category or in class I and you have fully applied the relevant harmonized standards, common specifications or a certification scheme at assurance level at least substantial. Under Article 32(2), class I manufacturers may use internal control (module A) only in that case. Otherwise a notified body must be involved through module B with module C, or module H. Who must be involved depends on which standards you follow in full, so decide early whether you will rely on harmonized standards. Harmonized standards are still in preparation under standardization request M/606, so the choice of route may affect your timeline. Confirm your route with a notified body or a competent adviser before you commit budget.
What does the five-year support period mean for a cheap device?
The support period must be at least five years, unless the product is expected to be in use for less time, in which case it must match the expected use time. Article 13(8) sets this rule. For a low-cost device, the cost driver is not the number of years alone but what you must keep running: firmware security updates, vulnerability handling under Annex I Part II, and the reporting duties under Article 14 that apply from 11 September 2026. Your bill of materials, third-party libraries and cloud dependencies all need to stay maintained for that window. Ask your engineering team to estimate the update effort per year, and ask any outside provider for a written quote that covers the full support period rather than a one-time build.
Is my cloud backend in scope of the CRA?
It can be. The Commission guidance treats cloud functions that you design and that your app and device use to exchange and store data as remote data processing, even when they run on a third-party IaaS provider. In its smart thermostat example (section 8.3.2 of the guidance), the manufacturer's cloud functions were treated as part of the product's remote data processing, and the manufacturer could ask the IaaS provider for evidence that NIS 2 obligations are met. In practice, your backend's security and update duties can therefore follow the device. Map which services you designed, which ones you only consume, and where the data is stored, and review the Commission guidance on the application of the regulation with your legal team.
What penalties can apply under Article 64?
Article 64 sets maximum administrative fines of EUR 15 million or 2.5% of total worldwide annual turnover for breaches of Annex I and of Articles 13 and 14, whichever is higher. Other listed obligations carry a maximum of EUR 10 million or 2%, and incorrect or misleading information given to authorities carries EUR 5 million or 1%, again whichever is higher. These are caps, not expected fines. The exposure depends on the breach, the company's size and turnover, and how national market surveillance authorities choose to act. Reporting failures are a particular risk because the Article 14 duty to notify actively exploited vulnerabilities applies to in-scope products placed on the market, whenever they were placed on the market.
Can my own engineering team do CRA compliance work in-house?
Often yes for the engineering work, but the conformity assessment itself must be done by you or by an independent notified body, depending on your route. Your team owns the controls: secure defaults, reset to original state, automatic updates with clear opt-out, vulnerability handling and the technical documentation. An implementation partner can help build and harden the systems, prepare the evidence and document it, and run security testing, but it cannot issue the EU declaration of conformity or stand in for a notified body. Before you hire anyone, ask for a fixed-scope written proposal that lists deliverables, the systems covered and the evidence each deliverable produces. DeployOpen works this way, and quotes follow from that written scope.
Do I need automatic updates on every connected device?
Annex I Part I point (2)(c) requires that vulnerabilities can be addressed through security updates. Where applicable, automatic security updates should be enabled by default, with a clear and easy opt-out, notification of available updates, and the option to temporarily postpone them. The key phrase is where applicable, so a device that cannot safely update without an operator present needs a documented reason and a different approach. Engineers should design update delivery, signing, rollback and user notification together, and test them against the full support period. Confirm the design with your own threat model and with the Commission guidance before you lock the firmware architecture.
How DeployOpen works on this
DeployOpen prepares the platforms behind connected devices, including device management, cloud functions and update infrastructure, along with the evidence a manufacturer needs for its CRA technical file. The work runs inside the client's own cloud accounts or data centers, and the manufacturer keeps ownership of its products, risk assessment and declarations.
How we scope
- Written scope lists which connected products, firmware lines and cloud functions are covered by the CRA review.
- Scope names each Annex I point the engagement addresses, with the owner for each requirement on the manufacturer side.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.
How we build
- Secure default configuration and factory reset paths are implemented and tested on representative device and cloud builds.
- Update delivery, opt-out and postponement settings are configured in the device management platform and checked end to end.
- Cloud functions that process device data are hardened, logged and documented as remote data processing where they apply.
How we hand over
- Deliverables include configuration records, test results, update and support-period documentation for the technical file.
- Software component inventories and SBOM outputs are produced from the build pipeline and stored with each release.
- Handover covers runbooks so the manufacturer's own staff can operate and evidence the controls after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can keep update infrastructure, vulnerability intake and evidence records current across the support period.
- Confirm with the independent assessor which evidence formats and conformity route they will accept before scoping begins.
