PHYTEC Blog | Embedded Systems Insights

Secure by Design von Embedded Systems: Sicherheit beginnt mit dem Produktdesign

Geschrieben von Julia Philipp | 14 Juli 2025

Sicherheitsanforderungen für die Zukunft mitdenken und den Produktlebenszyklus sichern


 

Der Cyber Resilience Act (CRA) ist seit 10. Dezember 2024 in Kraft und soll bis zum 11. Dezember 2027 umgesetzt sein. Maik Otto, Embedded Security Specialist bei Phytec, gibt im Interview Einblicke, was Kunden bei Neuentwicklungen beachten sollten und was Secure by Design damit zu tun hat.

 

Phytec: Maik, du bist der Experte für Embedded Security bei Phytec und berätst Kunden zu diesem Thema. Der CRA gilt zwar vorerst für neue, nach dem 11. Dezember 2027 auf den Markt gebrachte Produkte, aber je nach Risikoklasse müssen einige Produkte ab Juni 2026 von unabhängigen Stellen hinsichtlich ihrer Konformität bewertet werden. 
Was müssen Kunden jetzt tun, um ein CRA-konformes Produkt mit einem eingebetteten System als Bestandteil planen zu können?

Maik: Im ersten Schritt ist es wichtig, dass die IT-Sicherheit bei der Entwicklung eines neuen Produktes direkt mitgedacht wird. Das Prinzip „Secure by Design“ ist nicht neu, aber nun essentiell. Das heißt auch, dass bei der Verwendung eines eingebetteten Systems alle Sicherheitsfeatures und -elemente eingeplant werden müssen. Dabei sollten auch zukünftige Sicherheitsanforderungen mitgedacht werden. Denn im Nachhinein sie einzubauen, ist aufwendiger oder sogar unmöglich. Das ist immer dann der Fall, wenn Bauteile fehlen oder Schaltpläne geändert werden müssen.

Phytec: Kannst du das an einem Beispiel festmachen?

Maik: Ja, klar. Für die Geräteauthentifizierung werden Private Keys verwendet, die einen sicheren Speicherplatz benötigen. Hierfür kann ein Secure-Element wie ein Trusted Platform Module (TPM) verwendet werden, das auf dem Carrierboard vorhanden sein muss. Wenn das Element aber fehlt, weil es aus bestimmten Gründen wie Kosten, niedrigeren Sicherheitsanforderungen bei der Planung , unklarem Einsatzgebiet oder Security-Levels nicht mit eingeplant wurde, dann lässt sich die Anforderung nur über ein Redesign oder eine Softwarelösung nachziehen. 

Phytec: Gibt es Secure-Elemente, die immer im Design mit eingeplant werden sollten?

Maik: Es gibt verschiedene Secure-Elemente, die je nach Einsatzzweck ihre Berechtigung haben. Secure-Elemente, die für ARM-Mikrocontroller (MCU) konzipiert wurden − also einen geringen Stromverbrauch und einen minimalen Funktionsumfang haben −, sind meist in Verbindung mit Linux und Mikroprozessoren in ihrem Funktionsumfang nicht ausreichend. Deshalb verwenden wir primär TPMs und NXP SE051 / SE052 Secure Elemente. 

 



Phytec: Du hast erwähnt, dass Schritt 1 ist, entsprechende Sicherheitsfeatures und -elemente bei der Entwicklung einzuplanen. Was empfiehlst du Kunden, die eine Neuentwicklung planen?

Maik: Für die Planung ist es entscheidend, in welche Risikoklasse das neue Produkt einzuordnen ist. Denn davon hängen die Anforderungen ab. Auf dieser Grundlage sollten sich Entwickler und Entwicklerinnen eingehend mit den Sicherheitsfeatures der Chiphersteller auseinandersetzen. Denn erst dann können sie entscheiden, welcher Mikrocontroller geeignet ist und wie das Carrierboard designt werden muss, um die heutigen und zukünftigen Anforderungen zu erfüllen. Im Whitepaper „Secure by Design“ haben wir Grundlagen zu Cybersecurity, den Sicherheitsfeatures und -elementen von NXP-Chips und den zusätzlichen Sicherheits-Services von Phytec zusammengetragen, um den Informationsprozess zu unterstützen. Denn nur, wenn die verschiedenen Möglichkeiten verstanden sind, kann ein Embedded System geplant und entwickelt werden, das heutige und zukünftige Anforderungen erfüllt. Insofern ist Secure by Design entscheidend für den Produktlebenszyklus. 

Phytec: Vielen Dank, Maik. 

 

Maik Otto, Embedded Security Specialist bei Phytec, studierte Elektrotechnik in Mittweida (zwischen Leipzig und Chemnitz) und arbeitet seit 2011 bei Phytec als Softwareentwickler. Seit mehr als 8 Jahren ist er für den Bereich Embedded Security zuständig und hat in dieser Zeit sowohl Security Features in das BSP integriert, als auch in verschiedenen Kundenprojekten Security-Anforderungen umgesetzt.