The reporting obligations of the EU Cyber Resilience Act (CRA) took effect on Friday 11th September 2026. From that date, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements has just 24 hours to file an early warning and 72 hours to file a full notification.
Full CRA compliance follows on Saturday 11th December 2027. Failure to comply carries a penalty ceiling of €15 million or 2.5% of global annual turnover, whichever is higher.
Whilst the penalties are a matter of public record, what a manufacturer has to do to achieve compliance, is less widely understood. In recognition of this, a new report from Transforma Insights maps the regulatory and operational governance issues converging on connected operations: IoT in Transition: Navigating a Rapidly Evolving Global Regulatory and Connectivity Landscape.
Accountability and the reporting clock
The CRA is not the only clock now ticking. The NIS2 Directive imposes its own reporting cadence and it attaches accountability at management level rather than to a product.
Placed side by side, the two regimes leave a gap between them. CRA obligations attach to the manufacturer. NIS2 obligations attach to the operator. A single connected asset is typically the work of a silicon vendor, a module maker, an ODM, a platform provider, a connectivity provider and an integrator, and the deployment is run by a different organisation again.
Irrespective of how many parties are involved, the regulation requires a named accountable party. In most deployments the matter has not traditionally even been discussed, let alone settled, and the answer is rarely written into the associated supply contracts.
Update reach across the device lifecycle
Most IoT programmes have a software update policy and typically industrial and utility deployments for example, run for ten to fifteen years. Despite the fact that the obligation to keep them secure runs the length of that period, the deployment’s update reach was determined by specifications written before the requirement existed.
Regulators have moved past asking whether the capability is present and, sector by sector, a stated intention to patch is being replaced by a requirement to demonstrate the capability. For example, UNECE WP.29 R156 requires vehicle manufacturers to operate a certified software update management system, subject to audit, with comparable expectations set out in FDA guidance for connected medical devices.
Connectivity as part of the security architecture
Another development arising from the new legislation is that connectivity models are also required to change. Transforma Insights looks at the implications of placing connectivity inside the security architecture, rather than alongside it.
In this new report, Transforma Insights sets out the six operational obligations arising from this new regime – lifecycle security accountability, update management, vulnerability handling and disclosure, attack surface limitation, incident containment and security logging and monitoring – and maps what each requires in practice.
Comment on this article via X: @IoTNow_ and visit our homepage IoT Now
