For years, IoT platform decisions were driven mostly by connectivity, scale, and cost. Security was important, but it was often treated as a feature list: encrypted transport, device certificates, maybe an over-the-air update service. The European Union’s Cyber Resilience Act changes that framing. It turns security across the whole product lifecycle into a legal obligation for anyone placing products with digital elements on the EU market, and connected devices are squarely in scope.
Two dates define the timeline. On 11 September 2026, reporting obligations for actively exploited vulnerabilities and severe incidents began to apply. On 11 December 2027, the main obligations apply. For device makers and the teams who run their IoT platforms, the period in between is the window to make the platform capable of supporting compliance. This article explains what has changed, why the IoT platform is central to meeting the requirements, and how to prioritize the work. It is not legal advice; product teams should work with counsel and the official texts.
What the Cyber Resilience Act Requires, in Brief
The European Commission describes the CRA as introducing cybersecurity requirements across the planning, design, development, and maintenance of products with digital elements, applying at every stage of the value chain. Manufacturers must handle vulnerabilities throughout a product’s lifecycle and report actively exploited vulnerabilities. Compliant products carry the CE marking, and national market surveillance authorities enforce the rules. Most products fall under general conformity assessment rules, while products of particular cybersecurity relevance may need third-party assessment by a notified body.
The timeline, according to the Commission, runs as follows:
- 10 December 2024: the regulation entered into force.
- 27 July 2026: the Commission published practical implementation guidance, which Jones Day describes as more than 80 pages with examples, use cases, and flowcharts.
- 11 September 2026: reporting obligations for manufacturers began to apply.
- 11 December 2027: the main obligations apply, including essential cybersecurity requirements and conformity assessment.
Jones Day notes that fines for non-compliance can reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
The Reporting Clock Is Already Running
The most immediate change is reporting. Since 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents affecting the security of their products through the Single Reporting Platform established by ENISA. According to the Commission, the deadlines run from when the manufacturer becomes aware:
- Early warning within 24 hours.
- Full notification within 72 hours.
- Final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident.
The notification goes to the CSIRT of the member state where the manufacturer has its main establishment, with ENISA receiving it at the same time unless exceptional circumstances apply. Jones Day highlights two further points that matter to IoT teams: the reporting duties cover in-scope products already on the market, including those placed on the market before December 2027, and manufacturers must also inform impacted users, and where appropriate all users. There is no duty to report retroactively exploitation that was known before 11 September 2026.
For an IoT business, the implication is stark. A 24-hour early warning is impossible if you cannot quickly determine which products, firmware versions, and customers are affected by a vulnerability. That determination depends almost entirely on what your IoT platform knows.
Why the IoT Platform Is the Compliance Engine
Many CRA obligations sound like product engineering or legal tasks, but in connected products they are executed through the platform. Consider what a manufacturer must be able to do and where that capability lives:
- Know what is deployed. Which devices exist, where, running which hardware revision, firmware, and software components. This is the device registry and inventory.
- Detect exploitation. Spot anomalous behavior, unexpected connections, or tampering. This is device telemetry, security monitoring, and log pipelines.
- Assess impact quickly. Map a vulnerable component to affected devices and customers. This requires linking software bills of materials to inventory.
- Fix and verify. Ship security updates and confirm they were applied. This is the over-the-air update service and fleet reporting.
- Inform users. Notify affected customers with accurate scope. This depends on mapping devices to accounts and contacts.
- Evidence the process. Produce records for authorities and conformity assessment. This depends on audit logs and reporting.
An IoT platform that only moves telemetry and commands is not enough. To support CRA obligations, it must act as a system of record for the security state of the fleet.
Under the Cyber Resilience Act, a 24-hour early warning is only possible if your IoT platform can answer within hours which devices, firmware versions, components, and customers a vulnerability affects. The platform has become the compliance engine.
Platform Capabilities to Prioritize
1. A Trustworthy Device and Software Inventory
Every device should have a strong identity, a known hardware revision, and an accurate record of the firmware and software it runs. Inventory must update automatically from devices, not from manufacturing spreadsheets. For fleets that include third-party gateways or modules, record those components too.
2. Software Bills of Materials Linked to the Fleet
The CRA’s essential requirements include identifying and documenting the components in a product, including through a software bill of materials. The practical value comes from linking each firmware build’s SBOM to the devices running it. When a new vulnerability is published in an open-source library, you can query which builds include it and which devices run those builds. Store SBOMs in a standard format such as SPDX or CycloneDX alongside build artifacts and connect them to the registry.
3. Vulnerability Intake and Triage
Manufacturers need a coordinated vulnerability disclosure process and a way to receive reports from researchers, customers, and suppliers. Feed vulnerability intelligence into a triage workflow that queries the SBOM-to-fleet mapping, estimates exposure, and decides whether exploitation is active. Define in advance what evidence constitutes awareness, because the 24-hour clock depends on it.
4. Security Telemetry and Detection
Collect security-relevant signals: authentication failures, configuration changes, unexpected outbound connections, firmware integrity checks, and resource anomalies. Route them to security monitoring rather than leaving them in operational dashboards. Edge processing can filter and summarize to keep bandwidth and cost reasonable.
5. Secure, Observable Updates
Over-the-air updates must be signed, resilient to interruption, and capable of rollback. Equally important is observability: the platform must report which devices have applied an update, which failed, and which are offline. The final report deadline for exploited vulnerabilities is tied to when a corrective measure is available, so update speed and coverage become measurable obligations.
6. User Notification and Audit Trails
Map devices to customers and contacts so notifications can be targeted. Keep audit trails of detection, decisions, notifications, and updates, retained long enough to support authorities’ inquiries and conformity documentation.
A 2026 to 2027 Roadmap
With reporting obligations already live and main obligations a little over a year away, a pragmatic sequence for IoT teams looks like this:
- Now: Reporting readiness. Establish the incident and vulnerability response runbook, register for the Single Reporting Platform, define awareness criteria, and run a tabletop exercise against the 24-hour and 72-hour deadlines.
- Next quarter: Inventory and SBOM linkage. Close inventory gaps, generate SBOMs for all supported firmware builds, and connect them to the device registry so exposure queries take minutes.
- First half of 2027: Update and detection maturity. Harden the update pipeline, add rollout observability, and route security telemetry to monitoring with tuned alerts.
- Second half of 2027: Conformity evidence. Assemble technical documentation, confirm support periods and update policies for each product, and complete conformity assessment ahead of 11 December 2027.
Organizing the Response Team
Platform capabilities only help if people know how to use them under time pressure. A CRA-ready response model for connected products typically involves several roles with clearly defined handoffs:
- Product security lead: owns the vulnerability handling process, decides when awareness has been reached, and signs off on reports.
- IoT platform engineers: run exposure queries against inventory and SBOM data, prepare update rollouts, and monitor coverage.
- Firmware engineering: develops and validates fixes or mitigations, and maintains SBOM generation in the build pipeline.
- Customer and support teams: prepare and send notifications to affected users with accurate guidance.
- Legal and compliance: review submissions to the Single Reporting Platform and coordinate with authorities.
Write the runbook so that each role knows its first hour of actions. Keep pre-approved templates for early warnings, notifications, and customer messages. Rehearse at least twice a year with realistic scenarios, including vulnerabilities in third-party components and incidents that start outside business hours.
Metrics That Show Readiness
Track a small set of indicators so leadership can see whether the platform supports the obligations:
- Time to exposure: how long it takes to list affected devices and customers for a given component version.
- Inventory accuracy: share of devices whose reported firmware matches the registry.
- SBOM coverage: share of supported firmware builds with a current SBOM linked to the fleet.
- Update coverage: share of affected devices updated within seven and thirty days of a fix.
- Exercise performance: whether tabletop exercises met the 24-hour and 72-hour targets.
Build, Buy, or Extend?
Most organizations will extend their existing platform rather than replace it. Hyperscaler IoT services provide device identity, registries, and messaging; device management and update services cover over-the-air delivery; security vendors offer IoT-specific detection. The gaps are usually in the connective tissue: linking SBOMs to the fleet, automating exposure queries, and integrating triage with reporting. When evaluating options, ask:
- Can the platform export a complete, current inventory with firmware and component detail on demand?
- Does it support SBOM ingestion or integration, and can it answer which devices contain a given component version?
- How are update rollouts tracked, and can it report coverage within hours of a release?
- What security telemetry is available from devices and gateways, and how does it reach your monitoring tools?
- How long are audit logs retained, and can they be exported for authorities?
A Hypothetical Example: A Smart Building Device Maker
Consider a hypothetical manufacturer of networked building controllers sold across Europe. It has around two hundred thousand devices in the field across four hardware generations. Its IoT platform handles telemetry and remote configuration well, but firmware versions are tracked inconsistently and no SBOMs exist for older builds.
In October 2026, a researcher reports that a widely used embedded web server library has a flaw being exploited in the wild. The team takes three days just to determine which firmware builds include the library, far beyond the 24-hour window. The company then launches a remediation program: it generates SBOMs for all supported builds, links them to the device registry, adds automated exposure queries, and integrates the results into an on-call runbook with predefined notification templates for the Single Reporting Platform and customers. By mid-2027 an equivalent exposure query takes under an hour, and update coverage reports are available the same day a fix ships.
Common Pitfalls
- Treating the CRA as a 2027 problem. Reporting obligations already apply to products on the market.
- Inventory from manufacturing records. Devices are updated, repaired, and replaced; only live inventory is reliable.
- SBOMs in a drawer. SBOMs that are generated but not linked to the fleet do not speed up impact assessment.
- Ignoring offline devices. Devices that rarely connect can stay vulnerable for months; track and address them explicitly.
- Forgetting suppliers. Modules, gateways, and third-party firmware need contractual commitments for vulnerability information and updates.
Beyond Compliance: The Operational Upside
The capabilities the CRA demands are the same ones that make large fleets easier to run. Live inventory reduces truck rolls and support time because engineers know exactly what is in the field. SBOM-to-fleet linkage speeds up every security review, not only regulated ones. Observable updates cut the long tail of devices running old firmware, which also reduces support complexity. Security telemetry surfaces misconfigurations and failing hardware alongside attacks. Teams that frame CRA work as fleet operations modernization, rather than paperwork, usually find it easier to fund and sustain.
Conclusion
The Cyber Resilience Act makes lifecycle security a legal requirement, and for connected products the IoT platform is where most of that lifecycle is managed. Reporting obligations already apply, and the main obligations arrive in December 2027. Organizations that invest now in live inventory, SBOM-to-fleet linkage, security telemetry, observable updates, and rehearsed reporting will meet the deadlines with less disruption, and will run safer fleets in the process.
How Hanoi Technology Can Help
Hanoi Technology helps device makers extend their IoT platforms with live inventory, SBOM-to-fleet linkage, secure updates and security telemetry to support CRA readiness.