Ten checks for choosing an IoT stack under the Cyber Resilience Act, from the device to the cloud, and what to do when part of it stops existing.

Also as an interactive walk-through: the reporting clock, your support period against the end dates others set, and the ten checks layer by layer.

Under the EU Cyber Resilience Act, a connected product sold in the EU needs a published end date for security updates, free fixes until then, and a report within hours when attackers exploit one of its vulnerabilities or a severe incident hits its security. An IoT stack chosen this year, from the chip and the cellular module through the operating system and the network to device management and the cloud, will ship in products in 2027 and 2028 and has to be supported well into the next decade. For every layer that ends up in your product, that obligation is yours, whoever wrote the code. The layers outside it, the network and the hosted cloud platform, are risks your product has to withstand.

The CRA covers almost every hardware or software product made available in the EU that connects to a device or a network. Its main obligations fall on the manufacturer: whoever markets the product under their own name or trademark, including an importer or distributor that rebrands it (Articles 3(13) and 21). Medical devices, type-approved vehicles, certified aviation and marine equipment and products built only for national security or defence keep their own rules, and open source supplied outside any commercial activity is not covered. The core is short: products designed to the security requirements of Annex I, and vulnerabilities handled until the published end date. A product that does not meet them cannot carry the CE marking, and fines reach EUR 15 million or 2.5 per cent of worldwide annual turnover, whichever is higher (Article 64(2)).

Two dates matter. Since 11 September 2026 manufacturers have had to report to their national CSIRT and to ENISA through a single reporting platform, for products already sold as well: an early warning within 24 hours of becoming aware that a vulnerability in their product is being actively exploited, a notification with more detail within 72 hours, and a final report within 14 days after a fix or mitigation is available. The same 24 and 72 hours run for a severe incident affecting the product’s security, one that impairs its ability to protect sensitive or important data or functions or lets malicious code in; its final report is due one month after the incident notification (Articles 14 and 69(3)). From 11 December 2027 the regulation applies in full to every unit placed on the market from then on, including units of models designed earlier, and to earlier units that are substantially modified: changed after sale in a way that adds cybersecurity risk the original assessment did not cover, or that changes the intended purpose it was assessed for. Security fixes generally are not (Articles 3(30) and 69(2), recital 39).

The support period is the time during which you owe security updates. It has to reflect how long the product is expected to be in use, at least five years unless the expected use is shorter, and its end date, month and year, has to be stated when the product is sold (Article 13(8) and (19)). You may take into account the support periods of integrated components that provide core functions, but the obligation stays yours. If the cloud service at the top of your stack ends in 2029, your support period runs on. The reading list of 4 October collected four such end dates in one week, from the cloud down to the network.

The checks follow the stack from the bottom up: the device, the connection, the platform, then what runs through all of them. They are cheap before the contract is signed.

An IoT stack from the hosted cloud platform at the top to silicon and module at the bottom. Solid green layers are yours for the whole support period: backend functions your device needs, update delivery, application and update path, keys and certificates, operating system and BSP, silicon and module. Dashed layers sit outside it: the hosted cloud platform and the network with the SIM. Orange tags mark end dates set by others: IoT Central 2029, 2G off 2028, expiring roots, operating system support, JESD48 six months. A band at the bottom: SBOM, supplier vulnerability reports and open source run through every layer.
The green layers are yours for the whole support period. The network and the hosted platform sit outside your product, and others set their end dates.

The device

1. Silicon and module: whose end date sits under yours

The decision. Which chip and which cellular module the device is built on, whose firmware sits underneath yours, and whether any of them is an important or critical product under the CRA in its own right.

Why the CRA cares. A component placed on the market separately is a product with digital elements itself (Article 3(1)), so a commercial component placed on the market from December 2027 owes you a stated end date as well. Some components are listed for stricter assessment: modems intended for internet connection and microcontrollers with security-related functionalities are important products of class I (Annex III), and the embedded UICC behind an eSIM is among the critical products (Annex IV, as described in Implementing Regulation (EU) 2025/2392). Integrating one does not move your product into its category (Article 7(1); guidance, paragraph 141), but its conformity evidence becomes part of your due diligence. A last-time buy secures supply, not compliance: every unit placed on the market from 11 December 2027 has to comply, whatever the date code of its parts, and only spare parts that replace identical components to the same specification are exempt (Article 2(6)). Most connected products sit in the default category and may assess their own conformity, with no outside assessor. If your own product’s core function is listed, a cellular router for instance, or a gateway whose core function is routing between networks, self-assessment is possible only with harmonised standards, EU standards whose use presumes conformity, or common specifications applied in full; otherwise a notified body, an assessor designated by a member state, or a certification at assurance level “substantial” or higher is needed (Article 32(2)). In early October 2026 no harmonised standard for the CRA had been cited in the Official Journal, and the Commission’s NANDO database listed no notified body under the regulation. A router maker planning for December 2027 depends on standards not yet cited or on notified bodies not yet designated.

Ask the supplier. What is the end of security support for the exact module version we will ship, in month and year, and until when does the chipset vendor support the firmware underneath? In which CRA category do you place the module, and when will we have your EU declaration of conformity, your signed statement that it meets the CRA, and the integration information Annex II, point 8(f) requires?

Warning sign. End-of-life terms “per JESD48”, which guarantee six months to place a last order and twelve to receive it, against a module change with re-certification that rarely fits into either. Or: “The CRA does not apply to us, we only sell components.”

2. Operating system and BSP: fixes on your version, separate and free

The decision. Whether you will receive security fixes for the operating system release you ship, or only for whatever the vendor ships next.

Why the CRA cares. Security updates have to be provided separately from feature updates where technically feasible, and free of charge, unless agreed otherwise with a business user for a tailor-made product (Annex I, Part II, points 2 and 8). A vendor who charges for fixes has moved that cost onto you. But a software vendor may fix only its latest version, as long as users get the upgrade free and without extra cost to adapt their hardware or software (Article 13(10)). Fixes on the version you ship therefore have to be in the contract. An operating system placed on the market separately in the course of a commercial activity, even free of charge, is itself an important product of class I, so the questions from the first check apply to its vendor as well; if it is open source, its maker may still assess it itself (Article 32(5)).

Ask the vendor. Are security fixes delivered on the version we ship, apart from feature releases, at no extra charge, for the whole term of the contract?

Warning sign. A vendor BSP on a kernel that is neither a kernel.org long-term release nor a CIP kernel, so that every fix means porting to a new BSP. Or patches available only in a premium support tier.

3. Trust from the factory, and a way to renew it

The decision. How trust gets into each device and how it is replaced later: secure boot chain, per-device credentials provisioned in production, debug interfaces closed, the root certificates the device relies on.

Why the CRA cares. Where the risk assessment makes them applicable, the device has to ship with a secure default configuration that can be reset to its original state, protection against unauthorised access, protected programs and configuration, and a limited attack surface (Annex I, Part I, point 2). Certificates and roots have end dates of their own. When Azure IoT Hub moved from the Baltimore CyberTrust Root to DigiCert Global Root G2, Microsoft’s instructions were plain: a device without the new root in its store could no longer connect.

Ask the supplier. Where are device keys generated, who besides us has seen them, can we replace the trust store and device certificates over the air, and how many revocable boot-key slots does the chip have?

Warning sign. One credential per batch. Code-signing or CA private keys on the contract manufacturer’s line instead of an HSM that only ever sees certificate requests. A root certificate compiled into the firmware, or secure boot fused to a single key with no revocation.

4. An update path that reaches the whole device

The decision. Whether updates reach every part of the device that can carry a vulnerability: application, operating system, bootloader, modem firmware, the radio or safety coprocessor beside the main one. And whether flash and RAM leave headroom for ten years of patches that only grow.

Why the CRA cares. Vulnerabilities have to be fixable through security updates, automatic by default where applicable (Annex I, Part I, point 2(c)). A supplier’s component can sit outside your update path; the OTA article covers why the device side is the hard half.

Ask the module supplier. Can your firmware be updated over the air, driven by our host or our server rather than your cloud or a USB tool? Which version-to-version delta images do you provide? Who carries operator and GCF or PTCRB re-certification of each new modem release?

Warning sign. Modem firmware that only the module vendor’s utility can flash over USB, or flash sized for exactly one image.

The connection

5. The network and the SIM have end dates too

The decision. Which radio technology, which operators and which SIM the product depends on. The radio technology is fixed in hardware for the life of the device.

Why the CRA cares. Indirectly, and that is the trap. A network switch-off does not create a vulnerability, but it ends the channel your security updates travel on, inside a support period you have already stated.

Ask the connectivity provider. Until when does each operator we use commit to the radio technology we chose, and can the eSIM profile be switched to another provider remotely, under SGP.32?

Warning sign. A locked SIM from a connectivity reseller, or a module that supports one radio technology where the operator’s roadmap already shows its successor.

The platform

6. Device management: the fleet has to be movable

The decision. Where device identity, provisioning and the update server live, and whether the fleet can be moved to another service without a field visit.

Why the CRA cares. Updates have to be distributed securely, and security updates without delay, for the whole support period (Annex I, Part II, points 7 and 8). Each security update you issue then has to stay available for at least ten years, or for the rest of the support period if that is longer (Article 13(9)), so the update archive has to outlive the service it sits on.

Ask the platform provider. Which hostname do devices connect to, whose CA issues their credentials, can both be changed over the air, and how do we keep every update we have issued available for ten years?

Warning sign. Devices that connect to the provider’s hostname with credentials bound to its provisioning service, so that re-homing the fleet means touching every unit. A hostname you own and credentials from your own CA cost little at design time.

7. The cloud backend is part of the product

The decision. Which parts of the backend you build yourself and which you rent.

Why the CRA cares. The backend functions without which your device cannot perform one of its functions are part of the product, as remote data processing designed by you or under your responsibility (Article 3(2)), and they are inside your support period. The hosted platform underneath owes you no CRA end date: the CRA leaves such services to NIS2 (recital 12), and the Commission’s guidance of July 2026 asks you to treat them like third-party components. The provider’s device SDKs and edge runtimes are different: placed on the market from December 2027, they are products with an end date of their own. Microsoft has announced that Azure IoT Central applications are no longer available after 20 September 2029.

Ask the platform provider. What notice does the contract give before a service we depend on is retired, and which of our functions use APIs that exist only on your platform?

Warning sign. Business logic that lives in a provider’s proprietary rules engine or application builder, with no way to export it.

Across the stack

8. An SBOM for each layer, with each release

The decision. Whether you can say, within hours, which devices contain a component named in a fresh advisory, at whatever layer it sits.

Why the CRA cares. You need a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies (Annex I, Part II, point 1). That minimum does not tell you within hours whether an advisory about a supplier’s binary blob affects your devices, and once you know that a vulnerability in your product is being exploited, the 24 hours run. Binary analysis of the image finds some of what is inside; the rest has to come from the supplier.

Ask every supplier. Do you deliver an SBOM in SPDX or CycloneDX with every release, including the proprietary binaries, and VEX statements on which CVEs actually affect it, so that unaffected components drop out of your triage?

Warning sign. A PDF of open-source licences, or “the firmware is proprietary, we cannot list its contents”.

9. Supplier vulnerability handling feeds your own reporting

The decision. Whether each supplier in the stack will tell you about an exploited vulnerability fast enough for you to warn the authorities and your customers while it still matters.

Why the CRA cares. When an actively exploited vulnerability in your product comes from a third-party component, the report is yours, whatever the supplier reports for its own component; one that cannot be exploited, or has not been, in your product does not have to be reported (Commission guidance, paragraph 218; reading list of 27 September). You need a coordinated vulnerability disclosure (CVD) policy and a contact address for reports (Annex I, Part II, points 5 and 6), and a vulnerability you find in a component has to be reported to whoever maintains it (Article 13(6)).

Ask every supplier. Who handles vulnerability reports (your PSIRT), where is your CVD policy, how quickly do you notify integrators of an exploited vulnerability, and is that time in the contract?

Warning sign. No advisory page, or CVEs that appear only after a researcher has published first. A supplier with no published vulnerabilities in ten years has not been looking.

10. Open source with someone behind it

The decision. Which open-source projects sit in the critical path of the stack, from the bootloader to the backend, and who will fix them when they break.

Why the CRA cares. You have to exercise due diligence on every third-party component you integrate, including open source nobody sold you (Article 13(5)). Open-source stewards, foundations and other organisations, not themselves the manufacturer, that support open-source projects intended for commercial use on a sustained basis, carry lighter obligations of their own (Article 24), and fixing your product is not among them. If a project goes quiet, carrying the patch is your job.

Ask the project, or yourself. How many active maintainers, how fast are security reports answered, who stands behind it, and could we carry a fix ourselves?

Warning sign. One maintainer, no release in a year, security issues open without reply. Or a vendor SDK called open source that is a fork frozen several versions ago. Open source controlled by a single vendor is a different dependency, not a smaller one.

All ten questions in one table

For a request for quotation, the questions and warning signs side by side.

CheckAsk the supplierWarning sign
1. Silicon and module (Art. 3(1), 13(19), Annex III)End of security support for our module version, in month and year? Chipset support underneath? CRA category, declaration of conformity, integration information?End of life “per JESD48”; “the CRA does not apply to components”
2. Operating system and BSP (Annex I, Part II; Art. 13(10))Security fixes on the version we ship, separate from features, free, for the whole contract?A kernel that is neither long-term nor CIP; patches only in a premium tier
3. Trust from the factory (Annex I, Part I)Where are keys generated, who has seen them, can trust store and certificates be replaced over the air, how many revocable boot-key slots?One credential per batch; signing keys on the factory line; a root compiled into the firmware
4. Update path (Annex I, Part I, point 2(c))Modem firmware over the air through our channel? Delta images? Who carries re-certification?Modem flashable only with a USB tool; flash for one image
5. Network and SIMHow long does each operator commit to our radio technology? eSIM profile switchable remotely (SGP.32)?A locked reseller SIM; a radio technology whose successor is already on the roadmap
6. Device management (Annex I, Part II; Art. 13(9))Whose hostname and CA, changeable over the air? Update archive available for ten years?Provider hostname and credentials bound to its provisioning service
7. Cloud backend (Art. 3(2))Notice before a service is retired? Which functions use platform-only APIs?Business logic in a proprietary rules engine with no export
8. SBOM (Annex I, Part II, point 1)SBOM in SPDX or CycloneDX with every release, binaries included, plus VEX?A licence PDF; “proprietary, we cannot list its contents”
9. Vulnerability handling (Art. 13(6), 14; Annex I, Part II)Who handles reports, where is the CVD policy, how fast are integrators notified, and is that in the contract?No advisory page; CVEs only after a researcher publishes
10. Open source (Art. 13(5), 24)Active maintainers, response time, who stands behind it, could we carry a fix?One maintainer, no release in a year

When part of the stack stops existing

Some of these checks will fail anyway, years after the contract, because nobody controls every date. AWS set 7 October 2026 as the end of support for its Greengrass V1 edge runtime. A supplier is sold, as Semtech has agreed to sell its cellular module business to Compal, or goes insolvent. An open-source project loses its last maintainer. A network is switched off: Telekom plans to end 2G in Germany by 30 June 2028, and Vodafone in September 2028, keeping it open for critical IoT applications until the end of 2030.

A vertical timeline from 2026 to 2033. Left, the CRA: reporting applies from 11 September 2026, the regulation in full from 11 December 2027, and a unit placed on the market then has a support period of at least five years, ending no earlier than December 2032, drawn as a green bar. Right, end dates set by others: Greengrass V1 support ends on 7 October 2026, 2G is switched off in Germany between June and September 2028 (Telekom's date is planned), Azure IoT Central applications end on 20 September 2029, and Vodafone keeps 2G for critical IoT until the end of 2030. Dotted lines show the last three falling inside the support period.
A unit placed on the market in December 2027 has to be supported until December 2032 at the earliest. Every end date shown after that point falls inside the period.

None of that moves the obligations. The support period you stated when the product was sold stands, the reporting duty continues, and a product that no longer meets the requirements during the support period has to be brought back into conformity, withdrawn or recalled (Article 13(21)). A manufacturer that ceases operations has to tell the market surveillance authorities and, as far as possible, its users beforehand (Article 13(23)); beyond that notice, the CRA has no answer to a supplier that disappears. For cloud services, the Data Act gives customers a contractual right to switch and take their data, and bans switching charges from 12 January 2027, with exceptions for custom-built services (Articles 23 to 31); no article keeps a platform running.

What to build in beforehand. An abstraction where an end date is most likely: cloud connectivity and device management. A second source that has been qualified, not just named; for the modem, a pin-compatible second module is the real exit, because chipset licences keep modem firmware out of escrow. Escrow for what a supplier can deposit (device agent, a small vendor’s BSP or backend), with end of support and change of control among the release triggers, rebuilt once by the escrow agent to prove it works, and with the build container and compiler licences, because source code without the toolchain does not compile in 2034. And a fleet inventory that records which software, at which SBOM version, runs on which device at which customer.

What to do when it is announced. Use the inventory and the SBOMs to establish which units and which customers are affected. Work out the migration path, its cost and its re-certification, and whether it runs over the air or needs a field visit. A network switch-off means new hardware and a new radio assessment. A backend migration has to go out through the old backend while it still runs, so plan for the units that stay offline for months. Check whether the change is a substantial modification (Article 3(30)), and update the cybersecurity risk assessment, which has to be updated as appropriate during the support period (Article 13(3)). Then tell customers, before they read it elsewhere, whether the end date you gave them still holds.

Who is responsible. Procurement holds the contract until it is signed, product management the next release, engineering the current build. The fleet that shipped three years ago has no one: the same gap that leaves OTA without an owner, one level up. I would give one person the fleet inventory, the end dates across the stack and the customer commitments, with the budget authority to fund a migration before it becomes urgent.

Each part of the stack you choose this year comes with an end date you do not set. The one you state when the product is sold is the only one your customers will hold you to.

Sources