Interview zum Cyber Resilience Act „Security ist ein bewegliches Ziel“

Anbieter zum Thema

Infineon Technologies AG

FAULHABER Antriebssysteme

MES Electronic Connect GmbH & Co. KG

RECOM Power GmbH

Infineon-Expertin Preeti Khemani erklärt, wo Unternehmen beim Cyber Resilience Act stehen, welche Missverständnisse bestehen und warum Security entlang der gesamten Lieferkette gedacht werden muss.

Mit dem Cyber Resilience Act verschärft die EU die Anforderungen an die Cybersicherheit vernetzter Produkte. Zwar greifen die zentralen Pflichten der Verordnung erst ab dem 11. Dezember 2027 vollständig. Doch eine wichtige Stufe beginnt bereits am 11. September 2026: Ab diesem Datum müssen Hersteller aktiv ausgenutzte Schwachstellen sowie schwerwiegende sicherheitsrelevante Vorfälle melden, sobald sie davon Kenntnis erlangen. Vorgesehen sind dabei enge Fristen: eine Frühwarnung innerhalb von 24 Stunden, eine vollständige Meldung innerhalb von 72 Stunden und anschließende Abschlussberichte.

Was das für Hersteller, Zulieferer und Entwickler vernetzter Produkte bedeutet, erläutert Preeti Khemani im Gespräch. Sie ist bei Infineon in der Division Connected Secure Systems tätig und befasst sich dort mit Ökosystemen, Partnerschaften, Standards und Regulierungen rund um Halbleiter, Connectivity und Security. Zudem bringt sie über ihre Arbeit im Eurosmart-Umfeld eine breite Perspektive auf die Abstimmung zwischen Industrie und europäischen Institutionen mit. Im Interview spricht sie über typische Missverständnisse zum CRA, die Rolle von Risikoanalysen, SBOM (Software Bill of Materials) und HBOM (Hardware Bill of Materials) sowie die Frage, warum Security nicht an einer einzelnen Komponente endet, sondern entlang der gesamten Lieferkette gedacht werden muss.

ELEKTRONIKPRAXIS: Frau Khemani, ab dem 11. September 2026 müssen Hersteller Sicherheitslücken und sicherheitsrelevante Vorfälle melden, sobald sie davon Kenntnis erlangen. Aus Ihrer Perspektive: Wo stehen Unternehmen und Konzerne derzeit in Bezug auf ihre CRA-Bereitschaft?

Preeti Khemani: Die Frage nach der Bereitschaft lässt sich aus meiner Sicht in zwei Gruppen aufteilen: Unternehmen, deren Geschäftsfeld eng mit Security verknüpft ist und diejenigen, die damit noch keine Berührungspunkte hatten.

Unternehmen, die bereits im Security-Geschäft sind — ob in den Bereichen Identität, Payment, Network Security oder OT, also Operational Security — haben sich schon sehr früh mit Cyber Resilience beschäftigt und lagen deutlich vor der Kurve. Aber man muss gleichzeitig sagen: Der European Cyber Resilience Act ist ein sehr komplexes Gesetz. Man braucht ein gewisses Maß an Expertise, um zu verstehen, wie man es implementiert.

Beim übrigen Teil der Industrie ist Security nicht der Hauptfokus. Wenn ein OEM oder ODM Security als Belastung wahrnimmt, dann hinkt er bei der Integration von Security hinterher. In vielen unserer Gespräche gibt es Fragen von Neueinsteigern, die das Thema erst verstehen müssen. Es gibt also diese zwei Gruppen.

Zusätzlich würde ich noch zwischen europäischen und nicht-europäischen Unternehmen unterscheiden. Selbst wenn man im Security-Bereich tätig ist, aber nicht aus Europa kommt, dürften diese sich oft denken: Das betrifft uns nicht. Aber die Welt ist klein und sehr vernetzt und der Zugang zum europäischen Markt unverzichtbar.

Unsere Erfahrung ist: Wenn die Messlatte in einer Region angehoben wird, erkennen andere Regionen — auch aus geopolitischen Gründen —, dass das für sie ebenfalls notwendig sein könnte.

Viele Unternehmen wissen oder spüren womöglich gar nicht, wie stark sie selbst verantwortlich sind. Viele denken vielleicht: Ich kaufe ja schon ein TPM (Trusted Protection Module) von Infineon, also bin ich jetzt sicher. Dabei fehlt das Bewusstsein, dass mehr dazugehört, um die eigenen Voraussetzungen zu erfüllen.

Das ist absolut richtig. Cyber Resilience und das entsprechende Gesetz sind sehr breit und sehr komplex. Kunden, die unsere Security-Produkte kaufen, haben bereits ein Bewusstsein für Security. Sobald dieses Gesetz diskutiert wurde, kamen sie zu uns und fragten: Was stellt ihr bereit? Was müssen wir tun?

Aber wie gesagt, die Industrie ist extrem divers. Da gibt es Hersteller digitaler und vernetzter Produkte, die bisher nicht über Security nachgedacht haben.

Es muss ja entlang der gesamten Lieferkette passieren? Es geht nicht nur um das eine Security-Modul. Es geht darum: Woher bekomme ich meine CPU, meine SoCs, meine Speicher und so weiter? Wie kann ich alle Vulnerability-Vektoren managen? Wann und wo muss ich einen Vorfall melden, und wie schwerwiegend muss er sein? Welche organisatorischen oder technischen Hürden müssen diese Unternehmen noch angehen oder überwinden?

Für Produkte, die nicht in Anhang III oder IV des CRA gelistet sind, ist es ist nicht zwingend erforderlich, dass jede einzelne Komponente für sich betrachtet sicher ist; vielmehr muss aus Sicht des Herstellers die gebotene Sorgfaltspflicht (Due Diligence) für das Gesamtsystem gewährleistet werden. Nehmen wir zum Beispiel ein IoT-Gerät. Dort gibt es einen Mikrocontroller und Connectivity-Bauteile. Es ist nicht immer notwendig, dass jeder Mikrocontroller und jeder Connectivity-Zugang an sich abgesichert ist. Wenn man einen gesicherten Controller hat, kann dieser bestimmte Funktionen übernehmen. Eine solche Architektur kann für jede Geräteklasse genutzt werden.

Vieles kann also das TPM übernehmen, dennoch müssen auch weitere Aspekte berücksichtigt werden. Das TPM – oder unser PSOC edge, der in ein edge System eingesetzt wird – kann seine Aufgabe nur gut erfüllen, wenn zumindest Due Diligence und Risikobewertung erfolgen. Wir brauchen diese Korrelation zwischen dem Gesamtsystem und den Komponenten, die darin eingesetzt werden.

Dieses Verständnis gibt es bereits bei Unternehmen, die Security integriert haben. Diejenigen, die das noch nicht getan haben, müssen beginnen, sich damit auseinanderzusetzen.

Wenn ein vernetztes Gerät nicht gelistet ist, heißt das nicht, dass es keine Security braucht

Aus Beratungsperspektive: Was sind typische Missverständnisse? Was verstehen Unternehmen an den Anforderungen des Cyber Resilience Act falsch?

Eines kann ich nennen, das fast immer auftaucht. Es betrifft Geräte, die nicht in Anhang III oder Anhang IV des CRA aufgeführt sind. In diese Default-Kategorie fallen alle Geräte, deren Hauptfunktion nicht Security ist.

Dazu zählt zum Beispiel ein Förderband oder eine Klimaanlage. Deren Hauptaufgabe ist nicht, Security bereitzustellen. Sie sind nicht in Anhang III oder IV gelistet. Müssen sie also Security haben oder nicht?

Es gab ja schon vor Jahren Fälle, in denen beispielsweise ein Casino über die Temperaturregelung der Aquariums gehackt wurde...

Genau. Wenn ein Förderband vernetzte Elemente hat, kann man über diese das Förderband betreiben, aber auch einen Security-Vorfall verursachen. Wenn es Zugang zum zentralen Netzwerk hat und dieses auf diesem Weg gehackt werden kann, kann daraus sogar ein Safety-Vorfall werden.

Nur weil diese vernetzten Dinge nicht in Anhang III oder IV aufgeführt sind, heißt das also nicht, dass sie keine Security brauchen. Sie fallen alle unter die Default-Kategorie: Sie müssen ausreichend Security besitzen. Ein Missverständnis ist also, dass alle nicht gelisteten Geräte wenig oder gar keine Security brauchen.

Aber was die Kommission in dieses Gesetz integriert hat — und was ich immer stärker in Gesprächen mit Industriepartnern sehe —, ist Risikobewertung. Wenn ein Förderband Produkte enthält, die nicht sicherheitsrelevant sind, kann die Risikobewertung zeigen, dass es Security braucht, wenn auch nur auf niedrigerem Niveau. Wenn ein Förderband aber Produkte enthält, die am Ende eine Sicherheitsgefährdung verursachen könnten, dann muss es eine bessere Security haben — auch wenn es elektronisch betrachtet kein Hochsicherheitsprodukt ist. Der Grund liegt in der betrieblichen Umgebung dieses Bands, dieses PLCs, oder Controllers. Ich verwende den Begriff bewusst vorsichtig: Ich würde nicht von hoher oder niedriger Security sprechen, sondern von besserer Security.

Diese Art von Bewertung und Risikobewertung ist notwendig. Bei Klimaanlagen ist es ähnlich. Wenn sie in Rechenzentren eingesetzt werden und gehackt werden, kann das erhebliche Auswirkungen haben — sowohl in Bezug auf die öffentliche Wahrnehmung als auch auf die Produktivität.

Man kann also nicht alles in einen Topf werfen. Das größte Missverständnis betrifft Basic Security. Auch dort gibt es Abstufungen wie „basic“, „substantial“ und „high“, die je nach Risikobetrachtung Orientierung geben können.

Gibt es an dieser Stelle noch weitere Herausforderungen oder Missverständnisse?

Die zweite größere Herausforderung ist, zu verstehen, was unter „vernetzt“ zu verstehen ist und was nicht. Was direkt vernetzt ist, versteht jeder: Router und ähnliche Geräte, die direkt ins Internet gehen. Aber was passiert, wenn ein Gerät indirekt vernetzt ist? Es wacht nur einmal pro Stunde auf, um ein Signal zu senden, oder jemand verbindet sich mit dem Gerät, um Software zu aktualisieren. Diese intermittierenden Verbindungen oder Geräte, die sich nur verbinden, um Statistiken zu prüfen, sind komplizierter. Solche Geräte sind normalerweise nicht online, aber gelegentlich muss jemand eine Verbindung herstellen. Das ist indirekt. Für diese Fälle wird noch diskutiert, wie die Angriffsfläche zu bewerten ist.

Das ist komplex. Wenn man ein vernetztes Gerät hat, vielleicht ein Tablet oder ein Service-Tablet, das sehr sicher ist: Kann man dann das Gerät, mit dem es sich verbindet, ebenfalls als sicher betrachten? In welche Kategorie des CRA fällt es? Es ist nicht schwarz-weiß, und wir bekommen dazu bisher nicht in allen Punkten vollständige Orientierung: Es gibt natürlich den Entwurf der Leitlinien der Kommission. Darin stehen viele gute und sehr nützliche Informationen, aber einige Punkte sind weiterhin verwirrend, speziell was den Software-Bereich anbelangt.

Es müssen also weiterhin noch Dinge geklärt werden, ganz speziell im Bereich Software Bill of Materials (SBOM) und Hardware Bill of Materials (HBOM). Die Consumer-Seite wird in der Guidance recht breit behandelt, aber die industrielle Seite ist noch etwas offen.

Bloße Zertifizierung bedeutet nicht gleichzeitig CRA-Compliance

Welche Rolle spielen Standards und Zertifizierungen in diesem Zusammenhang? Beim Cyber Resilience Act sind derzeit bestimmte Standards immer noch nur in Arbeit und noch nicht veröffentlicht. Wie wirkt sich das auf die Industrie aus?

Ich beziehe mich erst einmal hierfür nur auf die Deliverables, die CEN, ETSI und CENELEC entwickeln: Standards für den Konformitätsnachweis, also für die Compliance mit Cyber Resilience. Diese beziehen sich vor allem auf Anhang III und Anhang IV; die Default-Kategorie wird bisher nicht so stark berührt. Infineon hat übrigens CENELEC TC47X geleitet.

Zertifizierungen für die kritische Klasse spielen eine große Rolle. Die Compliance-Checkliste ist hilfreich, wenn man eine breite Palette von Produkten hat, die Security-Funktionalität bereitstellen und dies auch weiterhin tun müssen. Ein gewisses Maß an Checklisten und Zertifizierungen ist notwendig, damit es eine gemeinsame Baseline gibt und Integration erleichtert wird.

Aber bloße Zertifizierung bedeutet nicht gleichzeitig auch CRA-Compliance.

Wenn sie in ihrem Router oder IPC ein TPM oder einen PSOC-Edge-Controller einsetzen, ist dieser auf Basis des Standards zertifiziert. Aber es muss dennoch weiterhin anschließend eine Compliance-Prüfung des gesamten Systems erfolgen. Dafür braucht es nicht zwingend ein Zertifikat, aber es braucht weiterhin eine Art Selbsttest oder einen Test durch Dritte. Die Europäische Kommission hat zum 11. Juni 2026 eine Liste der für die jeweiligen Länder zuständigen Komformitätsbewertungsstellen veröffentlicht.

Checklisten, Standards und Zertifizierungen erleichtern den Prozess und helfen, ein konsistentes Verhalten aller Entwicklungsteams sicherzustellen. Wenn man allerdings nur Checklisten um der Checklisten willen ausfüllt, bekommt man Schwierigkeiten. Denn dann verliert man schnell das Gespür für echte Schwachstellen. Da ich seit mehr als 20 Jahren im Security-Geschäft bin, habe ich viele Vorfälle erlebt. Irgendwann wird jede mögliche Schwachstelle ausgenutzt.

Ich sage gern: Security ist ein bewegliches Ziel. Man kann etwas beheben, und danach wird etwas anderes sichtbar. Wenn man eine Standardpraxis oder Verfahrensregeln hat, mit denen man Dinge konsistent beheben kann, ist das gut. Wenn man aber nur Dokumentation um der Dokumentation willen macht, wird man irgendwann verwundbar sein, und die Konsequenzen tragen müssen.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Wo stehen wir jetzt allgemein hinsichtlich des Cyber Resilience Acts? Wann kommen die nächsten Stufen, und wie weit sind die meisten Unternehmen darauf vorbereitet?

Die CRA-Anforderungen müssen bis Dezember 2027 vollständig umgesetzt sein. Aber ernst wird es bereits am 11. September. Ab dann muss man, wenn es eine Schwachstelle gibt, die ausgenutzt wird— egal ob über einen Safety- oder Security-Zugang —, diese melden können und im 1-3-14-Zyklus bearbeiten: ein Tag, drei Tage beziehungsweise 72 Stunden, und 14 Tage.

Es wird sich natürlich nicht plötzlich am 12. Dezember 2027 alles ändern, sondern eine schrittweise Entwicklung geben.

Wir beginnen gerade erst mit dem horizontalen Teil der Industrie. Das basiert alles auf einem sehr stabilen Standard, IEC 62443. Das ist gut, und dieser Standard korreliert auch mit Safety und Security. Aber die Anpassung dieses Standards an den CRA hat gerade erst begonnen. Und basierend auf unseren Erfahrungen der letzten beiden Jahre, glaube ich, wird es knapp.

Innerhalb von Infineon rollen wir das bereits aus. Wir sind im Security-Geschäft aktiv, und wir haben weitere Abteilungen, die stärker anwendungszentriert sind.

Bei Power-Management-Devices müssen wir abwägen: Muss das compliant sein? Das müssen wir im größeren Kontext bewerten. Wenn ein industrielles System über eine Schwachstelle angegriffen wird, müssen wir unsere Due Diligence nachweisen: Infineon hat als Hersteller seinen Teil erfüllt. Nicht jedes MOSFET muss security gehärtet sein, aber es muss den CRA Prozess durchlaufen haben.

Daher setzen wir auf Baseline Incident und Bill of Materials Reporting.

Das klingt nach einem enormen Dokumentationsaufwand. Wenn man einen Vorfall hat, muss man durch die gesamte Liste gehen: Wer war der Distributor, wer hat die Stromversorgung geliefert, wer den Mikrocontroller, wer den Speicher? Jedes Unternehmen muss also HBOM und SBOM vorliegen haben.

Unabhängig vom CRA: Wenn Sie zum Beispiel Hersteller von vernetzten Waschmaschinenhersteller sind: Möchten Sie wissen, was darin verbaut wurde? Wenn Sie Solarpanels herstellen: Möchten Sie wissen, was darin steckt? Falls nicht, wäre das für Ihre Kunden in Ordnung?

Denn das Wissen darüber nicht zu haben, führt zu Unsicherheit. Wenn man nicht weiß, ob ein bestimmtes Bauteil sicher ist oder nicht, und es geschieht ein Security-Vorfall, setzt man als Gerätehersteller seinen Namen und seine Marke aufs Spiel. Ein Hersteller, der sich wirklich um seine Kunden kümmert, besitzt auch eine SBOM oder HBOM.

Wie sollte Ihre Einkaufsabteilung einkaufen, wenn sie die HBOM nicht kennt? Wie sollte Wartung funktionieren? Das kommt jetzt durch den CRA in deutlicherer Form, aber eigentlich wäre ich überrascht, wenn ein Unternehmen sagen würde: Wir machen SBOMs nur, weil der CRA es verlangt.

Wie verändert das die Beziehung zwischen OEMs, Softwareentwicklern, Distributoren und Geräteherstellern?

Als OEM kann man jetzt nach seinen Quellen fragen, und das Gesetz gibt einem das Rückgrat, zu den Lieferanten zu gehen und zu sagen: Auch wir werden danach gefragt.

Glücklicherweise tun wir das standardmäßig. Wir haben SBOMs, weil wir unsere eigene Arbeit nachverfolgen müssen. Ich war zehn Jahre lang in der Softwareentwicklung. Man konnte kein Configuration Management betreiben, ohne SBOM-Traceability zu haben. Das ist eigentlich gute Praxis.

Ich bin überrascht, dass das noch eine Frage ist. Als Mensch, als Verbraucherin: Wenn der Gerätehersteller keine Ahnung hat, woher die Geräte und die Software kommen, weiß ich nicht, ob ich dieses Produkt verwenden möchte. Durch das Gesetz wird das nun klarer.

Es gibt ja in der Regel kleinere und mittlere Unternehmen, die noch keine eigene Security-Abteilung haben oder nicht die logistischen Kapazitäten. Dort besteht wohl noch die größte Verunsicherung vor dem gesamten Dokumentationsaufwand. Sie müssen eine verantwortliche Person bestimmen, die sicherstellt, dass diese 24-Stunden- und 72-Stunden-Meldungen und die Schulungen vorhanden sind. Häufig haben sie dafür nicht die Kapazität.

Das stimmt. Sie sprechen die zentrale Herausforderung an, die wir bei der Umsetzung dieses Gesetzes haben. Große Lieferanten und große Anbieter, ob in Europa oder außerhalb Europas können sich darum kümmern. KMU sind ein schwieriges Thema.

Hier arbeiten wir über Distributionspartner. Unsere Industriepartner bereiten einige dieser Services für KMU vor — nicht alle, aber einige. Ja, KMU sind herausfordernd.

Es gibt auch die Frage der vernünftigerweise vorhersehbaren Verwendung eines Produkts. In der Industrie gibt es bestimmte Anwendungen, bei denen man sagt: Dieses Produkt muss zehn Jahre im Einsatz sein, und dieser Standard ist Teil des Zertifizierungsprozesses. Das ist einfacher. Aber für ein IoT-Gerät haben wir solche Leitlinien oder Standards nicht. Wie würde ich also eine Risikobewertung durchführen?

Das ist wirklich die größte und schwierigste Herausforderung. Auch große Lieferanten haben dieses Problem, nicht nur KMU.

Die Definition der vernünftigerweise vorhersehbaren Verwendung ist eine Herausforderung, besonders wenn man es mit Weißer Ware zu tun hat oder wenn man breit liefert, wie wir es über Distributionspartner tun. Wenn wir jedoch eine Risiko- und Schwachstellenanalyse eines Produkts durchführen, etwa bei SoCs, geben wir Zielsegmente an, in denen es verwendet wird.

Bei Endgeräten ist es einfacher als bei Komponenten.

Ein KMU, das Endgeräte herstellt, wissen, wofür das Gerät verwendet werden soll.

Die ersten Jahre nach Einführung werden nicht einfach

Unternehmen müssen außerdem eine Methodik implementieren, wie sie ihre Systeme sicher aktualisieren und sicher warten, oder das Produkt zurückrufen.

Ja, auch hier wird es aus meiner Sicht realistisch betrachtet Lernprozesse geben. Die ersten drei bis fünf Jahre werden nicht einfach. Sobald der CRA im Dezember 2027 in Kraft ist, wird es mit Sicherheit Vorfälle geben, bei denen dagegen verstoßen wird.

Ich glaube übrigens, dass wir bei Softwarevorfällen nicht einmal auf das volle Inkrafttreten des CRA warten müssen. Denn schon durch KI wird es deutlich mehr Zwischenfälle geben. In den nächsten drei bis fünf Jahren wird es durch KI und durch die Pflicht zur Meldung von Vorfällen Turbulenzen geben.

Ich halte den CRA in diesem Zusammenhang für etwas Gutes. Durch KI werden Vorfälle sichtbar, und durch den CRA werden sie zumindest den richtigen Behörden gemeldet. Stellen Sie sich vor, KI würde Vorfälle sichtbar machen, aber es gäbe keinen CRA, und diese Vorfälle werden nirgendwo gemeldet.

Kommen denn Unternehmen mit den Meldestufen und der 1-3-14 Regel zurecht?

Ich komme aus dem Security-Geschäft, deshalb bin ich etwas voreingenommen. Ich denke, es ist gut, dass es Meldestrukturen gibt. Die Fristen sind allerdings zu streng, würde ich sagen.

An Tag eins erfährt man gerade erst, dass etwas passiert. Eine vollständige Scope-Analyse innerhalb von drei Tagen ist praktisch nicht möglich. Selbst wenn Ihr gesamtes Geschäft bereits zusammengebrochen ist, weil Ihr Service gekapert wurde, ist die Impact-Analyse — etwa wo ein bestimmtes Stück Code eingesetzt wurde — in drei Tagen sehr schwer zu leisten - selbst mit KI.

Und etwas innerhalb von 14 Tagen zu beheben, wird ebenfalls herausfordernd.

Es gab Vorschläge, dass es für den Cyber Resilience Act sinnvoll wäre, Labels einzuführen, ähnlich wie bei Energieeffizienzlabels: eine Farbskala oder eine A-, B-, F-Klassifizierung. Halten Sie das für eine gute Idee, damit man eine Vorstellung bekommt, wem man am meisten vertrauen kann oder wie viel Vertrauen man in ein Produkt setzen kann?

Ja. Singapur hat bereits Labels, bei denen eine Bewertung vergeben wird. Wir haben auch bei ENISA über Labeling-Schemata gesprochen, im Kontext von CRA, CSA und EU-Cybersicherheitsschemata wie EUCC.

Beim Cyber Resilience Act zeigt die CE-Kennzeichnung grundsätzlich an, dass Security berücksichtigt wurde. Ihre Frage betrifft jedoch die Skalierung von Security: Was ist höher, was niedriger?

Natürlich wäre es gut, so etwas zu haben. Aber das würde zusätzliche Kosten verursachen. Aus Sicht des Security-Geschäfts würde ich gern sagen können: Dieses Produkt ist sicherer, dieses weniger sicher. Als Verbraucherin würde ich ebenfalls sagen: Ja, es sollte schwarz-weiß sein. Aber zwischen dem Anbieter von Security-Lösungen und dem Verbraucher liegt eine gesamte Lieferkette.

Derzeit hat die Kommission nur die CE-Kennzeichnung eingeführt. Ich hoffe, dass wir mit der Zeit einen Diskurs sehen werden: Dieses Produkt ist sicherer, dieses weniger sicher. Als Verbraucherin würde ich es wollen; als Security-Anbieterin würde ich es wollen. Aber dazwischen stehen Kosten. Ich weiß nicht, ob wir das jetzt schon forcieren sollten.

Das wird immer der Fall sein: Wie viel darf es kosten, und wie teuer darf mein Produkt sein, wenn ich es auf den Markt bringe?

Genau. Und es würde auch die Frage aufwerfen: Was wären die Kriterien? Bei Energieeffizienz kann man schwarz-weiß messen. Bei Security: Wie würde man das messen? Das ist eine weitere Herausforderung.

Für Security müsste man ähnliche wie bei Safety einführen, und das wird schwierig. Eine smarte Türklingel ist bereits Important Class 1, weil sie Security-bezogen ist. Der erste Schritt der Differenzierung ist also bereits gemacht. Wenn ein Produkt stärker sicherheitskritisch ist — Smart Door Lock, Überwachungskamera, Router und so weiter —, ist es bereits klassifiziert.

Ich spreche hier über die Default-Kategorie, in der es eine so breite Spanne gibt. Natürlich wäre es gut, „Default Category Low Security“, „Default Category Medium oder Substantial“ und „Default Category High“ zu haben. Eine Temperatursteuerung für ein Aquarium ist etwas ganz anderes als industrielle Automatisierung.

Aber das bringt eine weitere Achse in das Ganze, einen weiteren Prüfvektor, und dafür bräuchte man explizite Kriterien. Deshalb: ein Schritt nach dem anderen. Zuerst die CE-Kennzeichnung, dann klären wir den Rest.

Wir haben jetzt Juni 2026. Was müssen Hersteller, Unternehmen und Serviceprovider ab heute tun? Welche Herausforderungen müssen sie zuerst angehen? Was müssen sie tun, um für die nächste Stufe im September und für den eigentlichen CRA bereit zu sein?

Ich nenne gern einen Vier-Schritte-Plan:

Der erste Schritt: Informieren Sie sich zum CRA, prüfen Sie Ihre Bill of Materials und bewerten Sie die Auswirkungen auf Ihr Produkt.

Im Kern geht es um drei Punkte: Security by Design, Schwachstellen- und Incident-Management sowie klare Security-Informationen für Kunden und Endanwender.

An zweiter Stelle steht die Risikobewertung anhand der vernünftigerweise vorhersehbaren Verwendung des Produkts.

Im dritten Schritt prüfen Sie, wo die Architektur um dauerhafte Security ergänzt werden muss. Beginnen Sie früh mit Ihren Security-Anbietern zu sprechen: Infineon bietet bereits Lösungen von Authentifizierungsbausteinen bis zu TPMs. Das Rad muss also nicht komplett neu erfunden werden.

Zu guter Letzt: Starten Sie mit der Implementierung – denn Sie sind bereits spät dran.  (sg)

(ID:50868280)