Embedded World 2024 Closing – Thoughts about Cyber Resilience in a Connected World

Homepage Embedded World 2024 Closing – Thoughts about Cyber Resilience in a Connected World

I’ve been thinking about this for three days at Embedded World. Numerous debates and conversations with my peers and the other cyber experts present at the show inspired me to share a few thoughts with you. Just the time to write a few lines before traveling for a series of workshops across Europe with NXP, Avnet, Witekio, and Keyfactor among others.

Cybersecurity is not a new topic. Dealing with some level of formalism in cybersecurity neither: Common Criteria certifications, for instance, have been around for more than 20 years, and are internationally recognized thanks to various mutual agreements such as the CCRA (and in Europe the SOG-IS) that allow a country to recognize the certificates produced by another country.

These evaluation and certification processes ensure that some level of robustness against state-of-the-art attacks is reached, and are essential to provide trust in sensitive devices we use every day to secure our payments, identities, and communications.

The catch is that these cybersecurity evaluations are really focused on security products, such as smartcards, TPMs, HSMs, … but not your everyday connected device.

This made a lot of sense in a world less connected than the one we live in today; security certifications are cumbersome and costly, and these costs are really only the tip of the iceberg: reaching a Common Critera EAL4 level requires a massive involvement from the developer, and it’s not rare to see initial certifications of products span over several year and multiple reworks.

Now we live in a world where most devices with a digital element are connected. This means that the number of entry points in the local networks and private information systems have exploded tremendously. In other words, the attack surface of our daily lives is everywhere.

The same goes of course for industries, governments and critical infrastructures. Thus the need for cybersecurity for seemingly innocuous products is there. And several years of certification are definitely not in order.

Another key difference is that security devices like smartcards are not designed to be updated: a Common Criteria certification targets a device in a specific configuration with specific software.

Change a line of code: there goes your certificate. Not only do you have to certify your product, but also each update, from the ground up. This makes sense for a critical device that is not exposed to the public networks, but is completely unrealistic and counter-productive in more dynamic setups where products are connected and open-source software represents more than 90% of the products code, and where the whole security community is working to identify vulnerabilities in these components: the updates need to be fast and efficient.

This does not mean that cybersecurity certification schemes for less critical devices should not be considered: the European Cyber Security Act mandated the ENISA to produce European Certification Schemes to provide an uniform way of assessing the cybersecurity of the products across all member states, as a more flexible and efficient alternative to the Common Criteria and SOG-IS agreement, and foundational components such as the hardware and operating systems should definitely be certified under such a scheme.

Then we need a lighter approach for leveraging the security guarantees brought by such certifications in finished products built upon these hardware and software components.

This is the main objective of the European Cyber Resilience Act: setting up a base level of cybersecurity around clear requirements imposed upon the product manufacturers. For most products these requirements will be self-assessed, and as a consequence the delays inherent to a certification process are avoided.

Truth be said this way of doing things targets a very different goal than the one of the certification schemes: it’s not about conveying trust in the products, but rather induce a dynamic change in the industry that will result in a more secure ecosystem.

In this way this approach is much more pragmatic.

From a technical standpoint there is nothing new in the Cyber Resilience Act, but it’s a mandatory commitment to the good cybersecurity practices:

Cybersecurity risk assessment

Cybersecurity risk assessment: the manufacturer must formalize its security problem, and bring a suitable security solution. In concrete terms, it means that they must have identified the attack surface of the product (all possible ways to interact with it and available to an attacker), the threats that target the product (what are the feared events and what would their impacts be), the attack paths (how an attacker could use the attack surface to realize some threat), and for each relevant attack path (in that it is considered realistic in a given attack model) an assessment regarding how to counter it (using dedicated security mechanisms or policies) or why it is not dealt with (e.g. because a full attack requires another ingredient that is already mitigated).

There are several formalisms that help doing this kind of assessment (e.g. the french EBIOS, or the STRIDE method), but the key element here is someone with an external point of view, that will be able to thinks as an attacker and uncover unexpected behaviours that were not identified by the development team.

Vulnerability management

Vulnerability management: the manufacturer must be aware of any vulnerability that may target its product all along its lifetime, and take action if these vulnerabilities introduce new attack paths that were not identified during the initial cybersecurity risk assessment.

To achieve this, they need to know upside down the software components that are included in their products. In the smartcard world, where every line of code is carefully crafted by the developer this is granted, but the price to pay is the one of obscurity: the security community will never audit your code, and you will need to leverage other means (sound static analysis tools, thorough code reviews, security tests) to gains confidence in your code.

For most products though open-source and off-the-shelf software components are the main building blocks of the products. This comes with “free” security oversight provided that you are using broadly used packages, but the flip side of this coin is that you’re not the only one that can do this. Thus you must deal with these components’ vulnerabilites before an attacker does.

Since software systems are more and more complex, it’s not an easy task to build and maintain this software bill of material with the required granularity, especially with embedded products where standardized OSes and package manager are not the norm.

Let’s assume you can do this easily, then the real trouble starts: how do you know what are your vulnerable components? Fortunately the CVE system has been live for a long time, and nearly uniformly used.

It’s an invaluable help in federating the work of the security community, but it suffers from its hierarchical model: the US National Institute of Standards and Technologies is the keystone, in that it ultimately validates each CVE, maps it to the impacted software components, and attributes it a score.

Nowadays the number of reported CVEs grows exponentially, and the NIST cannot keep pace. Maybe it’s time to come up with a more distributed system, that would be funded by international non-profit organisations instead.


Authentication: the software updates must only be delivered by trusted channels, and only to properly identified products. This authentication process comes with several implications in terms of cryptography and key provisioning, which need to be identified and dealt with by the risk assessment.

At the end of the day the Cyber Resilience Act takes a pragmatic, if somewhat more radical, approach towards reaching its end goal which is uniformly raising the cybersecurity level in Europe.

The mandatory aspect (and associated penalties) will succeed in creating the necessary incentives for product vendors to take control over the security of their products, demonstrate it to their customers, and publicly share information regarding vulnerabilities.

There is hope that this virtuous circle will also result in more refined and actionable requirements, both from the development and the certification standpoint.

Julien Bernet - Head of Security
11 April 2024