Catalog of SIP Cores
System on Chip design resources
System on Chip design resources
August 3, 2026 -
Cyber Resilience Act: Security must be built into architecture, hardware, and software from day one – especially for embedded and IoT development.
In a three-part article series, eeNews examines various aspects of the CRA and, in particular, how companies should now proceed. eeNews, together with Lemberg Solutions, is also organizing the free webinar “Building CRA-ready IoT products: the practical side of compliance” on 10 September, 2026. This webinar will show what a CRA-compliant SDLC looks like in practice. Registration for the webinar is now open.
As outlined in the first installment of the article series, the EU’s Cyber Resilience Act (CRA), or Regulation (EU) 2024/2847, will make cybersecurity a mandatory CE requirement for connected products starting in 2027. This part focuses on why “Security by Design” and “Secure by Default” will become mandatory, and what this specifically means for embedded and IoT developers.
For a long time, cybersecurity in many embedded and IoT products was considered only late in the development process – or added as an afterthought. The CRA puts an end to this practice. Security by Design and Secure by Default are becoming key requirements for products with digital elements. Anyone wishing to bring CE-compliant products to the European market in the future must embed security into requirements, architecture, and design decisions from the outset.
Shift Left: Security begins with architecture
The CRA establishes cybersecurity as a verifiable product attribute. Consequently, it will stand on equal footing with established requirements such as functional safety, electrical safety, and EMC (electromagnetic compatibility). For developers, this means that security decisions must not only be technically implemented but also documented and maintained throughout the product’s entire lifecycle.
A key principle of the CRA is the so-called “shift-left” approach. Security requirements should not be verified only at the end of development but rather taken into account during the early conceptual and architectural phases. This includes threat modeling, assessing potential attack surfaces, and defining appropriate protective measures.
For development teams, this entails,a mong other things, avoiding unnecessary interfaces and protocols, securing or disabling debug interfaces, establishing secure communication channels, and planning for update mechanisms from the very beginning...