The Cyber Resilience Act (CRA) is a major milestone in securing embedded systems against cyber threats. While most provisions must be implemented by 2027, reporting obligations take effect from 11 September 2026. As a manufacturer, what are your responsibilities, and which devices are affected?

As software touches every part of life, people expect higher standards for quality, security, and reliability. The Cyber Resilience Act (CRA) reflects this shift - a necessary response to past industry mistakes. Rather than resisting, we can use this regulation to improve our practices. Here’s why regulation is necessary, how we reached this point, and how we can use it to create better software.

The CRA mandates stringent cybersecurity requirements for digital products, ranging from vulnerability management and regular updates to security-by-design principles. Manufacturers are tasked with ensuring that their products remain secure throughout their lifecycle, providing ongoing updates, and managing vulnerabilities proactively. The agile development approach, characterized by iterative cycles, cross-functional collaboration, and continuous integration, is ideally suited to meet these requirements. Agile practices enable teams to quickly adapt to new regulatory demands, implement security measures efficiently, and deliver high-quality, secure software. This article outlines the key aspects of agile development that align with CRA compliance and demonstrates how organizations can leverage agility to meet their obligations under the CRA. For more information on how to transition your team to agile practices and ensure compliance with the CRA, feel free to reach out to me at urs.fassler@iqilio.ch.

Check out the Cyber Resilience Act overview. It shows the most important aspects of the upcoming regulation.

Download as pdf or png. Contact us for preparing the software development, questions and remarks.

Clean Code und Software Craftsmanship helfen, Embedded Systeme sicher zu machen (safety und security). Diese Botschaft hat uns Simon Künzli im aktuellen Kurs Security in Embedded Systems an der ZHAW School of Engineering vermittelt, und ich stimme absolut zu.

Es sind Methoden, Prinzipen und Praktiken welche ich seit bereits 10 Jahren anwende und sehr zu schätzen gelernt habe. Vielleicht tönt TDD, BDD, CI/CD, Review und was es alles gibt abschreckend. Persönlich gebe ich es nicht mehr her. Es gibt so viel Sicherheit das man das richtige entwickelt und die Qualität stimmt. Auch reduziert es die Bugs - dadurch ist der initial etwas höhere Aufwand nach kurzer Zeit amortisiert.

What to do with third party hardware components in your machine wrt. Cyber Resilience Act?

When working towards CRA compliance the focus is usually on the software you write. Especially devices based on Embedded Linux often have other hardware they control or interact with. In this context, one question came up from multiple customers: how do we work with third party hardware that contains software?

I thought about this and came to a quite simple solution with the realization of two key ideas:

Gestern war der Auftakt des Kurses Security in Embeeded Systems an der ZHAW Zürcher Hochschule für Angewandte Wissenschaften. Ich konnte durch den Input von Simon Künzli und den Diskussionen mit meinen Kommilitonen bereits einen differenzierteren Blick auf die kommenden Anforderungen des Cyber Resilience Act (CRA) der EU gewinnen.

Speziell interessiert mich, wie wir als Open Source Community im Embedded Linux Umfeld das Thema gemeinsam umsetzen können.