This is a deadline that arrives more than a year before the regulation's full application, set for 11 December 2027, yet it already carries penalties for those who are not prepared. For companies that design and sell connected devices, from smart heating systems to industrial systems, this is no longer a matter that can be postponed.
We are not a law firm and this is not a piece of regulatory advice: what we can offer, from our perspective as a software house that develops platforms and apps for connected devices, is a technical reading of what concretely changes in the way an IoT product is designed, developed and maintained.
What the Cyber Resilience Act is and who it involves
Regulation (EU) 2024/2847, which entered into force on 10 December 2024, is the first European text to introduce horizontal, mandatory cybersecurity requirements for "products with digital elements": hardware, software, firmware and connected components placed on the EU market. The scope includes routers, cameras and smart appliances, but also mobile applications, cloud platforms and the firmware that controls industrial devices and systems. It therefore does not concern only hardware manufacturers: anyone who develops the software that controls it, if they place it on the market under their own brand, also falls among the parties subject to the obligation.
For the client companies we work with, businesses that manufacture and sell connected devices under their own brand, it is typically the manufacturer who is the party subject to the CRA. Our role as a technical partner is to support them in the part that falls to us: the architecture, development and maintenance of the platform in line with the regulation's requirements.
Deadlines to keep in mind
The regulation applies gradually over a period of 36 months. On 11 June 2026, the provisions on conformity assessment bodies entered into force, a preparatory step but already indicative of how much the regulatory machinery is moving. On 11 September 2026, the reporting obligations under Article 14 kick in: notification of actively exploited vulnerabilities and severe security incidents, with staggered timeframes of 24 hours for the early warning, 72 hours for the detailed notification and 14 days for the final report. On 11 December 2027, the full essential requirements finally enter into force, including mandatory CE marking for cybersecurity: from that date, no product with digital elements will be able to be placed on the EU market without demonstrating compliance.
Secure by design and secure by default: what changes in product design
The CRA turns two principles that we already apply as good practice in our work, secure by design and secure by default, into genuine legal requirements. The first concerns how the product is conceived and built: it means integrating security into the architecture from the design phase onward, reducing the attack surface, separating functions when necessary, applying the principle of least privilege, and protecting the confidentiality, integrity and availability of data and services. The second concerns the configuration in which the product is delivered: no universal or weak default password, only the functionalities that are genuinely necessary active, a level of protection that does not depend on the end user's ability to configure it correctly.
These are the same principles that guide architectural choices we often describe in our projects: the differentiated management of local and cloud communication, multi-user access control, and secure data synchronization even under non-ideal network conditions. With the CRA, this kind of attention stops being a distinguishing mark of quality work and becomes a requirement that must be demonstrable.
Vulnerability management, SBOM and the support period
The regulation requires manufacturers to manage vulnerabilities in a structured way for the entire support period of the product, which must last at least five years, or as long as the expected lifespan of the product if shorter, and which must be clearly stated before purchase. Among the tools required is the Software Bill of Materials (SBOM): a machine-readable inventory of the product's software components, including first-level dependencies, typically in standard formats such as SPDX or CycloneDX. It serves to quickly trace which components are involved when a new vulnerability emerges, instead of having to reconstruct the software's composition once an incident is already underway.
Alongside this is the obligation to adopt a coordinated vulnerability disclosure (CVD) policy, a structured channel through which security researchers and users can report problems in a traceable way. The technical documentation that accompanies all of this (SBOM, list of vulnerabilities, risk assessment, evidence of security testing, declaration of conformity) must be kept for at least ten years from the product's placement on the market.
Where to start, from a technical standpoint
For a company that already has a connected device on the market, or that is considering developing one, the first useful step is a technical gap analysis: checking, product by product, where things stand with respect to secure-by-design architecture, vulnerability management, the update mechanism and technical documentation. This is different work from a legal audit, because it goes into the product's actual architecture, device-to-cloud communication, access management, the update release process, rather than into the interpretation of the regulatory text.
The topic ties in directly with what has already emerged from our work on IoT platforms: devices, libraries and operating systems change over time, and a platform that is not maintained and updated continuously loses value, as well as compliance. That is why, in the projects we follow, platform maintenance is never a secondary activity but an integral part of the work from the initial design stage onward.
