{"id":1867,"date":"2026-04-23T14:50:16","date_gmt":"2026-04-23T14:50:16","guid":{"rendered":"https:\/\/www.pickplace.de\/?page_id=1867"},"modified":"2026-04-23T16:08:37","modified_gmt":"2026-04-23T16:08:37","slug":"cyber-resilience-act","status":"publish","type":"page","link":"https:\/\/www.pickplace.de\/de\/cyber-resilience-act\/","title":{"rendered":"Cyber Resilience Act"},"content":{"rendered":"<p>Mit dem Cyber Resilience Act (<a href=\"https:\/\/eur-lex.europa.eu\/legal-content\/EN\/TXT\/?uri=CELEX%3A32024R2847\" target=\"_blank\" rel=\"noopener\">CRA<\/a>) hat die Europ&#xE4;ische Union einen regulatorischen Rahmen geschaffen, der Cybersicherheit direkt in die Produktverantwortung &#xFC;berf&#xFC;hrt. Die Verordnung richtet sich an Hersteller, Importeure und weitere Wirtschaftsakteure, die Produkte mit digitalen Elementen auf dem europ&#xE4;ischen Markt bereitstellen. Damit wird Cybersicherheit nicht mehr als separates IT-Thema behandelt, sondern als feste Eigenschaft eines Produkts.<\/p>\n\n\n\n<p>F&uuml;r Unternehmen mit Hardware, <a class=\"glossaryLink\"  aria-describedby=\"tt\"  data-cmtooltip=\"cmtt_e7cfd26b192bb2977fae6bc5dc38b507\"  href=\"https:\/\/www.pickplace.de\/de\/glossar\/embedded-software\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>Embedded Software<\/a>, industrieller Elektronik, vernetzter Sensorik oder eigenst&auml;ndigen Softwareprodukten ist der CRA ein operatives Thema. Anforderungen an Entwicklung, Dokumentation, Wartung und Schwachstellenmanagement werden Bestandteil des regul&auml;ren Produktgesch&auml;fts. Besonders relevant ist das f&uuml;r Branchen mit langen Lebenszyklen, technischen Variantenst&auml;nden und komplexen Lieferketten.<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Inhalt<\/h2><nav><ul><li class=\"\"><a href=\"#u\">Umfang<\/a><ul><li class=\"\"><a href=\"#produkte-mit-digitalen-elementen-als-regulatorischer-fokus\">Produkte mit digitalen Elementen<\/a><\/li><li class=\"\"><a href=\"#cybersicherheit-wird-teil-der-entwicklungsdisziplin\">Cybersicherheit als Teil der Entwicklungsdisziplin<\/a><\/li><li class=\"\"><a href=\"#schwachstellenmanagement-endet-nicht-mit-dem-serienstart\">Schwachstellenmanagement gem&#xE4;&#xDF; Cyber Resilience Act<\/a><\/li><li class=\"\"><a href=\"#dokumentation-wird-zum-technischen-nachweis\">Dokumentation und Nachweisf&#xE4;higkeit<\/a><\/li><li class=\"\"><a href=\"#auswirkungen-auf-lieferketten-und-zukaufkomponenten\">Lieferketten und Zukaufkomponenten<\/a><\/li><\/ul><\/li><li class=\"\"><a href=\"#bedeutung-fur-industrielle-elektronik-und-maschinenbau\">Bedeutung f&#xFC;r industrielle Elektronik und Maschinenbau<\/a><\/li><li class=\"\"><a href=\"#organisatorische-folgen-im-unternehmen\">Organisatorische Folgen im Unternehmen<\/a><\/li><li class=\"\"><a href=\"#der-cra-als-engineering-thema\">Secure Engineering und Security By Design<\/a><\/li><li class=\"\"><a href=\"#ausgangspunkt-netzwerkfahige-elektronik-ist-ein-angreifbares-system\">Ma&#xDF;nahmen f&#xFC;r die Elektronik-Entwicklung<\/a><ul><li class=\"\"><a href=\"#tara-als-pflichtinstrument-der-technischen-bewertung\">TARA: Threat And Risk Assessment<\/a><\/li><li class=\"\"><a href=\"#security-by-design-als-architekturprinzip\">Security by Design<\/a><\/li><li class=\"\"><a href=\"#anforderungen-an-hardware-und-software-getrennt-betrachten\">Anforderungen Hardware und Software<\/a><\/li><li class=\"\"><a href=\"#penetration-testing-als-nachweis-technischer-wirksamkeit\">Penetration Testing<\/a><\/li><li class=\"\"><a href=\"#regelmassiger-prozess-statt-einmalprojekt\">Regelm&#xE4;&#xDF;iger Prozess<\/a><\/li><\/ul><\/li><li class=\"\"><a href=\"#fazit\">Fazit<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"u\">Umfang<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"produkte-mit-digitalen-elementen-als-regulatorischer-fokus\">Produkte mit digitalen Elementen<\/h3>\n\n\n\n<p>Der CRA verwendet den Begriff &#x201E;Produkte mit digitalen Elementen&#x201C;. Gemeint sind Produkte, deren Funktion ganz oder teilweise durch Software, Firmware, Datenverarbeitung oder Vernetzung gepr&#xE4;gt ist. Darunter fallen klassische Konsumprodukte ebenso wie industrielle Systeme, Maschinenkomponenten, Steuerger&#xE4;te, Kommunikationsmodule oder softwarebasierte Anwendungen.<\/p>\n\n\n\n<p>F&uuml;r die Industrie ist entscheidend, dass viele etablierte Produkte heute digitale Elemente enthalten, auch wenn sie historisch als reine Elektronik- oder Maschinenprodukte verstanden wurden. Ein <a class=\"glossaryLink\"  aria-describedby=\"tt\"  data-cmtooltip=\"cmtt_cd9f113f1bb5dca381349f2669b4bf21\"  href=\"https:\/\/www.pickplace.de\/de\/glossar\/steuergeraet\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>Steuerger&auml;t<\/a> mit Ethernet-Schnittstelle, ein Diagnosezugang &uuml;ber USB, eine Weboberfl&auml;che f&uuml;r Parametrierung oder ein cloudf&auml;higes Gateway f&uuml;hren ein Produkt in einen Bereich, in dem Cybersicherheit regulatorisch relevant wird.<\/p>\n\n\n\n<p>Die praktische Folge ist eine Neubewertung des Portfolios. Unternehmen m&#xFC;ssen nicht nur neue Produkte betrachten, sondern auch bestehende Plattformen, Variantenfamilien und Serienprodukte. Viele Organisationen werden feststellen, dass ein erheblicher Teil des Angebots unter den CRA f&#xE4;llt.<\/p>\n\n\n\n<p>Der CRA unterscheidet zwischen allgemeinen Produkten mit digitalen Elementen und besonders relevanten Produktgruppen mit erh&#xF6;hten Anforderungen. Ein gro&#xDF;er Teil der Produkte f&#xE4;llt in den Bereich der regul&#xE4;ren Konformit&#xE4;tsbewertung mit interner Herstellerverantwortung. Dazu z&#xE4;hlen zahlreiche Standardprodukte aus dem Software- und Consumer-Umfeld.<\/p>\n\n\n\n<div class=\"wp-block-stackable-image stk-block-image stk-block stk-3801cb0\" data-block-id=\"3801cb0\"><style>.stk-3801cb0 .stk-img-figcaption{text-align:center !important;font-style:italic !important;}.stk-3801cb0 .stk-img-wrapper{width:50% !important;}@media screen and (max-width:689px){.stk-3801cb0 .stk-img-wrapper{width:100% !important;}}<\/style><figure><span class=\"stk-img-wrapper stk-image--shape-stretch\"><img loading=\"lazy\" decoding=\"async\" class=\"stk-img wp-image-1870\" src=\"https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/produkt-kategorien-cyber-resilience-act.jpg\" width=\"1812\" height=\"1595\" alt=\"Infografik zur Produktklassifizierung: Cyber Resilience Act: Selbstbewertung, Class I\/II, 90% der Produkte, Third-Party-Assessment.\"\/><\/span><figcaption class=\"stk-img-figcaption\">Produktklassifizierung gem&#xE4;&#xDF; Cyber Resilience Act<\/figcaption><\/figure><\/div>\n\n\n\n<p>F&#xFC;r definierte Produktgruppen aus Annex III gelten strengere Anforderungen. Diese Produkte sind in Class I und Class II unterteilt. Ma&#xDF;geblich sind technische Funktion, Einsatzbereich und potenzieller Einfluss auf Sicherheit und Infrastruktur.<\/p>\n\n\n\n<p>Class I umfasst unter anderem Produkte wie Netzwerkinterfaces, Firewalls oder bestimmte Mikrocontroller-Plattformen. Hier erfolgt die Bewertung typischerweise &#xFC;ber harmonisierte Standards oder geeignete Pr&#xFC;fverfahren.<\/p>\n\n\n\n<p>Class II betrifft besonders sensible oder systemrelevante Komponenten wie Prozessoren, Secure Elements, Betriebssysteme oder industrielle Firewalls. In diesen F&#xE4;llen steigt die regulatorische Pr&#xFC;ftiefe, h&#xE4;ufig unter Einbindung externer Stellen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"cybersicherheit-wird-teil-der-entwicklungsdisziplin\">Cybersicherheit als Teil der Entwicklungsdisziplin<\/h3>\n\n\n\n<p>Der CRA verankert Cybersicherheit in der Entstehung des Produkts. Konstruktion, Elektronikentwicklung, Softwareentwicklung und Systemarchitektur m&#xFC;ssen Sicherheitsanforderungen fr&#xFC;hzeitig ber&#xFC;cksichtigen. Das betrifft nicht nur sichtbare Sicherheitsfunktionen, sondern grundlegende Designentscheidungen.<\/p>\n\n\n\n<p>Eine Architektur mit unn&#xF6;tig offenen Schnittstellen, ungesch&#xFC;tzten Servicezug&#xE4;ngen oder fehlender Trennung von Vertrauensbereichen erzeugt Risiken, die sich sp&#xE4;ter nur mit hohem Aufwand korrigieren lassen. Der CRA erh&#xF6;ht daher die Bedeutung fr&#xFC;her Architekturentscheidungen. Sicherheitsaspekte geh&#xF6;ren in Anforderungsmanagement, Systemdesign, Schnittstellendefinition, Auswahl von Komponenten und Integrationskonzepte.<\/p>\n\n\n\n<p>In Embedded-Systemen betrifft das regelm&#xE4;&#xDF;ig Themen wie sichere Bootketten, Schutz von Debug-Zug&#xE4;ngen, Integrit&#xE4;t von Firmware, Rechtekonzepte f&#xFC;r Wartungsfunktionen, sichere Kommunikationskan&#xE4;le und kontrollierte Update-Mechanismen. Auch Speicher- und Laufzeitschutz durch MPU, TrustZone oder vergleichbare Mechanismen gewinnt an Bedeutung.<\/p>\n\n\n\n<p>Unternehmen mit etablierten Entwicklungsprozessen k&#xF6;nnen diese Anforderungen strukturiert integrieren. Organisationen ohne klar definierte Engineering-Gates werden st&#xE4;rker nachsteuern m&#xFC;ssen, weil Sicherheit nachvollziehbar geplant und umgesetzt werden muss.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"schwachstellenmanagement-endet-nicht-mit-dem-serienstart\">Schwachstellenmanagement gem&#xE4;&#xDF; Cyber Resilience Act<\/h3>\n\n\n\n<p>Ein zentrales Element des CRA ist die fortlaufende Verantwortung nach dem Inverkehrbringen. Produkte bleiben auch nach Auslieferung sicherheitsrelevant. Hersteller ben&#xF6;tigen Prozesse, mit denen Schwachstellen aufgenommen, bewertet, priorisiert und behoben werden.<\/p>\n\n\n\n<p>Das ver&#xE4;ndert die klassische Sicht vieler Produktunternehmen. In zahlreichen Industriebereichen galt der Serienstart lange als &#xDC;bergang von Entwicklung in Support. Der CRA verschiebt dieses Modell. Sicherheitsarbeit l&#xE4;uft &#xFC;ber den Lebenszyklus weiter. Dazu geh&#xF6;ren Meldestrukturen f&#xFC;r externe Hinweise, interne Bewertung technischer Risiken, Entwicklung von Korrekturma&#xDF;nahmen, Test neuer Softwarest&#xE4;nde und geregelte Bereitstellung von Updates.<\/p>\n\n\n\n<p>F&#xFC;r Produkte im Feld stellt sich damit unmittelbar die Frage nach technischer Updatef&#xE4;higkeit. Systeme ohne sichere Updatefunktion verursachen im Fall einer Schwachstelle hohe operative Kosten, weil Serviceeins&#xE4;tze, manuelle Nacharbeiten oder Hardwaretausch erforderlich werden k&#xF6;nnen. Bereits deshalb ist Updatef&#xE4;higkeit nicht nur ein Compliance-Thema, sondern ein wirtschaftlicher Faktor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"dokumentation-wird-zum-technischen-nachweis\">Dokumentation und Nachweisf&#xE4;higkeit<\/h3>\n\n\n\n<p>Der CRA verlangt Nachweisf&#xE4;higkeit. Unternehmen m&#xFC;ssen zeigen k&#xF6;nnen, wie Sicherheitsanforderungen umgesetzt wurden. Das betrifft technische Dokumentation ebenso wie interne Prozesse und Konformit&#xE4;tsunterlagen.<\/p>\n\n\n\n<p>In der Praxis reicht eine allgemeine Produktbeschreibung daf&#xFC;r nicht aus. Erforderlich sind nachvollziehbare Informationen zu Architektur, digitalen Funktionen, eingesetzten Komponenten, relevanten Schnittstellen, Sicherheitsmechanismen, Updatekonzepten und Prozessen zum Umgang mit Schwachstellen. Auch Pr&#xFC;fungen, Validierungen und Freigaben gewinnen an Gewicht.<\/p>\n\n\n\n<p>Viele Unternehmen besitzen umfangreiche Entwicklungsdaten, jedoch keine strukturierte Security-Dokumentation. Der CRA f&#xFC;hrt daher h&#xE4;ufig nicht zu v&#xF6;llig neuen T&#xE4;tigkeiten, sondern zur Notwendigkeit, vorhandene technische Arbeit systematisch dokumentierbar zu machen.<\/p>\n\n\n\n<p>F&#xFC;r Engineering-Organisationen ist das ein wichtiger Punkt: Wer Architekturentscheidungen, Tests und Freigaben sauber f&#xFC;hrt, reduziert sp&#xE4;teren Aufwand bei Nachweisen erheblich.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"auswirkungen-auf-lieferketten-und-zukaufkomponenten\">Lieferketten und Zukaufkomponenten<\/h3>\n\n\n\n<p>Digitale Produkte bestehen selten nur aus Eigenentwicklung. Betriebssysteme, Middleware, Funkmodule, Bibliotheken, Open-Source-Komponenten, Halbleiterplattformen und externe Softwarebausteine sind Standard. Der CRA erh&#xF6;ht damit automatisch die Relevanz des Lieferantenmanagements.<\/p>\n\n\n\n<p>Ein Hersteller muss wissen, welche Komponenten im Produkt verwendet werden, welche Abh&#xE4;ngigkeiten bestehen und wie Sicherheitsupdates aus der Lieferkette verf&#xFC;gbar werden. Besonders kritisch sind Bausteine ohne langfristige Pflege, nicht dokumentierte Fremdsoftware oder Plattformen mit unklarer Security-Roadmap.<\/p>\n\n\n\n<p>Im Embedded-Umfeld betrifft das beispielsweise Mikrocontroller-SDKs, Linux-Distributionen, Kommunikationsstacks, Wireless-Module oder propriet&#xE4;re Drittbibliotheken. Fehlt Transparenz, entstehen Risiken bei Wartbarkeit und Nachweisf&#xFC;hrung.<\/p>\n\n\n\n<p>Deshalb wird St&#xFC;cklistenlogik im Softwarebereich wichtiger. Software Bill of Materials, Versionskontrolle und geregelte Freigaben werden f&#xFC;r viele Hersteller zum Standardwerkzeug.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"bedeutung-fur-industrielle-elektronik-und-maschinenbau\">Bedeutung f&#xFC;r industrielle Elektronik und Maschinenbau<\/h2>\n\n\n\n<p>Der CRA wird h&#xE4;ufig mit Consumer-IoT verbunden. F&#xFC;r den industriellen Bereich ist er ebenso relevant. Moderne Maschinen, Steuerungen und Anlagen enthalten Netzwerktechnik, Fernwartung, Datenlogging, Feldbus-Gateways und servicef&#xE4;hige Embedded-Systeme. Damit entstehen dieselben Grundfragen wie in anderen digitalen Produkten.<\/p>\n\n\n\n<p>In industriellen Umgebungen kommen zus&#xE4;tzliche Anforderungen hinzu. Lebenszyklen sind l&#xE4;nger, Freigabeprozesse strenger, &#xC4;nderungen im Feld aufwendiger und Stillstandszeiten teuer. Ein Sicherheitsupdate kann hier nicht isoliert betrachtet werden, sondern muss mit Betrieb, Validierung und Produktionsrealit&#xE4;t zusammenpassen.<\/p>\n\n\n\n<p>Das verlangt robuste Engineering-Prozesse. Unternehmen ben&#xF6;tigen klare Strategien, wie Security-Updates gepr&#xFC;ft, freigegeben und ausgerollt werden, ohne die Verf&#xFC;gbarkeit technischer Systeme zu gef&#xE4;hrden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"organisatorische-folgen-im-unternehmen\">Organisatorische Folgen im Unternehmen<\/h2>\n\n\n\n<p>Der CRA ist nicht Aufgabe einzelner Security-Spezialisten. Betroffen sind Produktmanagement, Entwicklung, Qualit&#xE4;t, Einkauf, Service, Dokumentation und Gesch&#xE4;ftsleitung. Rollen und Verantwortlichkeiten m&#xFC;ssen eindeutig sein.<\/p>\n\n\n\n<p>Produktmanagement muss Anforderungen und Marktverantwortung steuern. Entwicklung muss technische Ma&#xDF;nahmen umsetzen. Einkauf muss Lieferantenf&#xE4;higkeit bewerten. Service ben&#xF6;tigt Prozesse f&#xFC;r Feldma&#xDF;nahmen. Qualit&#xE4;t und Management brauchen Transparenz &#xFC;ber Risiken, Reifegrad und Nachweise.<\/p>\n\n\n\n<p>In vielen mittelst&#xE4;ndischen Unternehmen wird dadurch erstmals eine formalisierte Product-Security-Struktur entstehen. Das kann durch dedizierte Rollen, klare Freigabemechanismen oder integrierte Verantwortlichkeiten im bestehenden Qualit&#xE4;tsmanagement erfolgen.<\/p>\n\n\n\n<p>Cybersicherheit wird also bei Produkten mit digitalen Elementen ein durchg&#xE4;ngiger Entwicklungsprozess von Anforderungen, Architektur und Implementierung bis zu Verifikation, Penetration Testing, Updates und Schwachstellenmanagement. Der CRA st&#xE4;rkt genau diesen Lifecycle-Ansatz, bei dem TARA, Security Requirements und regelm&#xE4;&#xDF;ige Re-Assessment-Zyklen fester Bestandteil der Produktpflege werden.<\/p>\n\n\n\n<div class=\"wp-block-stackable-image stk-block-image stk-block stk-e3147c5\" data-block-id=\"e3147c5\"><style>.stk-e3147c5 .stk-img-figcaption{text-align:center !important;font-style:italic !important;}.stk-e3147c5 .stk-img-wrapper{width:50% !important;}@media screen and (max-width:689px){.stk-e3147c5 .stk-img-wrapper{width:100% !important;}}<\/style><figure><span class=\"stk-img-wrapper stk-image--shape-stretch\"><img loading=\"lazy\" decoding=\"async\" class=\"stk-img wp-image-1871\" src=\"https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/cyber-resilience-act-prozess-cyber-security-v-modell.jpg\" width=\"2391\" height=\"1881\" alt=\"CRA Diagramm: Sicherheitsziele, Funktionen und Tests &#x2013; Fokus auf embedded software und funktionale Sicherheit.\" srcset=\"https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/cyber-resilience-act-prozess-cyber-security-v-modell.jpg 2391w, https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/cyber-resilience-act-prozess-cyber-security-v-modell-300x236.jpg 300w, https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/cyber-resilience-act-prozess-cyber-security-v-modell-1024x806.jpg 1024w, https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/cyber-resilience-act-prozess-cyber-security-v-modell-768x604.jpg 768w, https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/cyber-resilience-act-prozess-cyber-security-v-modell-1536x1208.jpg 1536w, https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/cyber-resilience-act-prozess-cyber-security-v-modell-2048x1611.jpg 2048w, https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/cyber-resilience-act-prozess-cyber-security-v-modell-15x12.jpg 15w\" sizes=\"auto, (max-width: 2391px) 100vw, 2391px\"\/><\/span><figcaption class=\"stk-img-figcaption\">CRA: Sicherheitsziele, Funktionen und Tests werden Prozess<\/figcaption><\/figure><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"der-cra-als-engineering-thema\">Secure Engineering und Security By Design<\/h2>\n\n\n\n<p>Unternehmen, die den CRA ausschlie&#xDF;lich juristisch betrachten, greifen zu kurz. Die eigentliche Arbeit liegt im Engineering. Sicherheitsarchitektur, Updatef&#xE4;higkeit, Komponentenstrategie, Testbarkeit und technische Dokumentation entscheiden dar&#xFC;ber, wie aufwendig Compliance tats&#xE4;chlich wird.<\/p>\n\n\n\n<p>Wer Produkte mit modularer Softwarestruktur, sauberer Schnittstellentrennung und nachvollziehbarer Konfiguration entwickelt, schafft g&#xFC;nstigere Voraussetzungen. Wer historisch gewachsene Plattformen mit ungepflegten Altkomponenten betreibt, wird h&#xF6;here Aufw&#xE4;nde sehen.<\/p>\n\n\n\n<p>Deshalb ist der CRA auch ein Modernisierungstreiber. Viele notwendige Ma&#xDF;nahmen verbessern nicht nur regulatorische Lage, sondern auch Wartbarkeit, Produktqualit&#xE4;t und Beherrschbarkeit komplexer Systeme.<\/p>\n\n\n\n<p>Sobald Elektronik durch Firmware oder Software gesteuert wird und zus&#xE4;tzlich Schnittstellen zu Netzwerken, Serviceger&#xE4;ten oder anderen Teilnehmern besitzt, entsteht eine Angriffsfl&#xE4;che. Genau an dieser Stelle setzt der CRA an. Die Verordnung fordert nicht einzelne isolierte Sicherheitsfunktionen, sondern einen nachvollziehbaren Sicherheitsansatz &#xFC;ber den gesamten Produktlebenszyklus.<\/p>\n\n\n\n<p>F&#xFC;r Unternehmen bedeutet das: Sicherheit muss als technischer Entwicklungsprozess organisiert werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ausgangspunkt-netzwerkfahige-elektronik-ist-ein-angreifbares-system\">Ma&#xDF;nahmen f&#xFC;r die Elektronik-Entwicklung<\/h2>\n\n\n\n<p>Ein Ger&#xE4;t mit Ethernet, WLAN, Bluetooth, CAN-over-IP, Mobilfunk, USB-Serviceport, Webinterface, Fernwartung oder Datenaustausch mit anderen Teilnehmern ist aus Sicht des CRA ein relevantes digitales Produkt. Auch interne Netzwerke in Maschinen, Anlagen oder Fahrzeugen sind technisch bedeutsam, weil Kommunikation immer potenzielle Angriffsvektoren er&#xF6;ffnet. Der Begriff des Netzwerks ist dabei bewusst sehr weit <\/p>\n\n\n\n<p>Ein <a class=\"glossaryLink\"  aria-describedby=\"tt\"  data-cmtooltip=\"cmtt_d983cf127120ee60c83537d13641bc54\"  href=\"https:\/\/www.pickplace.de\/de\/glossar\/mikrocontroller\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>Mikrocontroller<\/a> ohne klassische Internetverbindung kann betroffen sein, wenn er &uuml;ber ein Gateway erreichbar ist, Diagnosedaten austauscht oder Teil eines gr&ouml;&szlig;eren vernetzten Systems ist.<\/p>\n\n\n\n<p>Daraus folgt eine zentrale Interpretation: Nicht die Branche entscheidet &#xFC;ber die Relevanz, sondern die technische Exponierung des Produkts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"tara-als-pflichtinstrument-der-technischen-bewertung\">TARA: Threat And Risk Assessment<\/h3>\n\n\n\n<p>Ein zentrales Werkzeug zur praktischen Umsetzung ist die <a href=\"https:\/\/www.pickplace.de\/threat-and-risk-assessment\/\" data-type=\"page\" data-id=\"1298\">Threat Analysis and Risk Assessment<\/a> (TARA). Der CRA verwendet nicht den Begriff TARA, verlangt jedoch inhaltlich genau diesen Denkansatz: Risiken erkennen, Bedrohungen bewerten, Schutzma&#xDF;nahmen ableiten.<\/p>\n\n\n\n<p>F&#xFC;r Elektronik mit Software bedeutet das, dass zun&#xE4;chst die Systemarchitektur verstanden werden muss. Danach werden Assets identifiziert. Dazu z&#xE4;hlen Firmware, Bootloader, Schl&#xFC;sselmaterial, Konfigurationsdaten, Kommunikationskan&#xE4;le, Messwerte, Aktorik, Safety-Funktionen oder Produktionsparameter.<\/p>\n\n\n\n<p>Im n&#xE4;chsten Schritt werden Bedrohungen untersucht. Typische Beispiele sind:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Manipulation von Firmware<\/li>\n\n\n\n<li>unautorisierter Zugriff auf Wartungsfunktionen<\/li>\n\n\n\n<li>Netzwerkangriffe auf Dienste und Ports<\/li>\n\n\n\n<li>Denial of Service gegen Steuerfunktionen<\/li>\n\n\n\n<li>Diebstahl kryptografischer Schl&#xFC;ssel<\/li>\n\n\n\n<li>Replay- oder Spoofing-Angriffe<\/li>\n\n\n\n<li>Rechteausweitung &#xFC;ber Softwarefehler<\/li>\n\n\n\n<li>Missbrauch unsicherer Updatepfade<\/li>\n<\/ul>\n\n\n\n<p>Aus dieser Analyse entstehen technische Anforderungen. Ohne TARA fehlt die belastbare Grundlage, welche Schutzma&#xDF;nahmen tats&#xE4;chlich notwendig sind.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"security-by-design-als-architekturprinzip\">Security by Design<\/h3>\n\n\n\n<p>Der CRA verlangt, dass Sicherheit nicht nachtr&#xE4;glich aufgesetzt wird. F&#xFC;r Elektronikprodukte hei&#xDF;t das, dass <a href=\"https:\/\/www.pickplace.de\/embedded-systems-cyber-security\/\" data-type=\"page\" data-id=\"954\">Security<\/a> bereits in Architektur, Hardwareauswahl und Softwarestruktur verankert werden muss.<\/p>\n\n\n\n<p>Ein typisches Embedded-System sollte daher bereits in der Konzeptphase folgende Fragen beantworten:<\/p>\n\n\n\n<p><em>Wie wird Vertrauen im System aufgebaut?<br>Welche Komponente startet zuerst?<br>Wie wird Firmware gepr&#xFC;ft?<br>Welche Schnittstellen sind im Feld aktiv?<br>Welche Rechte hat ein Service-Techniker?<br>Wie werden Schl&#xFC;ssel gespeichert?<br>Wie werden Logs erzeugt?<br>Wie kann ein Update sicher eingespielt werden?<\/em><\/p>\n\n\n\n<p>Security by Design f&#xFC;hrt regelm&#xE4;&#xDF;ig zu Ma&#xDF;nahmen wie Secure Boot, signierten Images, deaktivierten Debug-Schnittstellen im Feld, Segmentierung interner Funktionen, rollenbasierten Zug&#xE4;ngen und geh&#xE4;rteten Kommunikationsprotokollen.<\/p>\n\n\n\n<p>Wird dies erst sp&#xE4;t ber&#xFC;cksichtigt, steigen Aufwand, Kosten und technische Risiken erheblich.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"anforderungen-an-hardware-und-software-getrennt-betrachten\">Anforderungen Hardware und Software<\/h3>\n\n\n\n<p>Viele Unternehmen betrachten Security prim&#xE4;r als Softwarethema. Bei vernetzter Elektronik greift das zu kurz. Der CRA betrifft das Gesamtsystem. Deshalb m&#xFC;ssen Hardware- und Softwareanforderungen getrennt und gemeinsam betrachtet werden.<\/p>\n\n\n\n<p>Auf Hardwareseite sind h&#xE4;ufig relevant:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Secure Elements oder HSM<\/li>\n\n\n\n<li>gesch&#xFC;tzte Schl&#xFC;sselablage<\/li>\n\n\n\n<li>Debug-Port-Kontrolle<\/li>\n\n\n\n<li>MPU \/ Memory Protection<\/li>\n\n\n\n<li>TrustZone oder vergleichbare Isolation<\/li>\n\n\n\n<li>physische Manipulationsresistenz je nach Produktklasse<\/li>\n\n\n\n<li>sichere Reset- und Recovery-Pfade<\/li>\n<\/ul>\n\n\n\n<p>Auf Softwareseite sind regelm&#xE4;&#xDF;ig erforderlich:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>sichere Authentisierung<\/li>\n\n\n\n<li>Rollen- und Rechtekonzepte<\/li>\n\n\n\n<li>H&#xE4;rtung von Netzwerkdiensten<\/li>\n\n\n\n<li>Input Validation<\/li>\n\n\n\n<li>Speicherfehlervermeidung<\/li>\n\n\n\n<li>Update- und Rollback-Konzepte<\/li>\n\n\n\n<li>Logging sicherheitsrelevanter Ereignisse<\/li>\n\n\n\n<li>sichere Konfiguration im Auslieferzustand<\/li>\n<\/ul>\n\n\n\n<p>Erst das Zusammenspiel beider Ebenen ergibt ein belastbares Sicherheitsniveau.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"penetration-testing-als-nachweis-technischer-wirksamkeit\">Penetration Testing<\/h3>\n\n\n\n<p>Der CRA verlangt wirksame Sicherheitsma&#xDF;nahmen. In der Praxis reicht eine reine Dokumentation daf&#xFC;r nicht aus. Unternehmen m&#xFC;ssen pr&#xFC;fen, ob Schutzma&#xDF;nahmen tats&#xE4;chlich funktionieren. Penetration Testing ist daf&#xFC;r ein zentrales Instrument.<\/p>\n\n\n\n<p>Bei Embedded-Produkten umfasst das typischerweise:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Netzwerkscans und Serviceanalyse<\/li>\n\n\n\n<li>Authentisierungspr&#xFC;fungen<\/li>\n\n\n\n<li>Test unsicherer Standardzug&#xE4;nge<\/li>\n\n\n\n<li>Update-Manipulationsversuche<\/li>\n\n\n\n<li>Webinterface-Tests<\/li>\n\n\n\n<li>API-Tests<\/li>\n\n\n\n<li>Protokollfuzzing<\/li>\n\n\n\n<li>Hardwarezugriff &#xFC;ber UART, JTAG, SWD oder &#xE4;hnliche Schnittstellen<\/li>\n\n\n\n<li>Extraktion von Firmware und Secrets<\/li>\n\n\n\n<li>Pr&#xFC;fung von Rechteeskalationen<\/li>\n<\/ul>\n\n\n\n<p>Penetration Testing sollte risikobasiert geplant werden. Kritische Funktionen, externe Schnittstellen und privilegierte Zug&#xE4;nge erhalten Priorit&#xE4;t.<\/p>\n\n\n\n<p>F&#xFC;r viele Unternehmen ist dies der &#xDC;bergang von theoretischer Security zu messbarer Produktsicherheit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"regelmassiger-prozess-statt-einmalprojekt\">Regelm&#xE4;&#xDF;iger Prozess<\/h3>\n\n\n\n<p>Die vielleicht wichtigste Interpretation des CRA lautet: Cybersicherheit ist kein Projekt mit Enddatum. Sie ist ein laufender Prozess.<\/p>\n\n\n\n<p>Ein Produkt, das heute freigegeben wurde, kann morgen durch neue Schwachstellen, neue Angriffsmethoden oder neue Abh&#xE4;ngigkeiten betroffen sein. Deshalb m&#xFC;ssen Hersteller wiederkehrende Abl&#xE4;ufe etablieren:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>regelm&#xE4;&#xDF;ige Neubewertung der TARA<\/li>\n\n\n\n<li>Schwachstellenmonitoring f&#xFC;r eingesetzte Komponenten<\/li>\n\n\n\n<li>Pflege von Open-Source-Abh&#xE4;ngigkeiten<\/li>\n\n\n\n<li>Security Regression Tests<\/li>\n\n\n\n<li>erneute Penetration Tests bei gr&#xF6;&#xDF;eren Releases<\/li>\n\n\n\n<li>Patch- und Updateprozesse<\/li>\n\n\n\n<li>Incident Handling<\/li>\n\n\n\n<li>Dokumentationspflege<\/li>\n<\/ul>\n\n\n\n<p>Besonders bei Produkten mit langen Feldlaufzeiten entscheidet dieser Prozess &#xFC;ber die tats&#xE4;chliche Compliance.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fazit\">Fazit<\/h2>\n\n\n\n<p>Der Cyber Resilience Act macht Cybersicherheit zu einer verbindlichen Produkteigenschaft im europ&#xE4;ischen Markt. F&#xFC;r Hersteller digitaler Produkte entsteht eine dauerhafte Verantwortung von der Architekturentscheidung bis zum Ende des Supportzeitraums. Besonders in Embedded-Systemen, industrieller Elektronik und vernetzten Ger&#xE4;ten verschiebt sich der Schwerpunkt auf saubere technische Strukturen, dokumentierte Prozesse und wartbare Plattformen.<\/p>\n\n\n\n<p>Unternehmen, die fr&#xFC;hzeitig Engineering, Lieferkette und Lifecycle-Management auf diese Anforderungen ausrichten, schaffen belastbare Voraussetzungen f&#xFC;r k&#xFC;nftige Produktgenerationen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Mit dem Cyber Resilience Act (CRA) hat die Europ\u00e4ische Union einen regulatorischen Rahmen geschaffen, der Cybersicherheit direkt in die Produktverantwortung \u00fcberf\u00fchrt. Die Verordnung richtet sich an Hersteller, Importeure und weitere Wirtschaftsakteure, die Produkte mit digitalen Elementen auf dem europ\u00e4ischen Markt bereitstellen. Damit wird Cybersicherheit nicht mehr als separates IT-Thema behandelt, sondern als feste Eigenschaft eines [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-1867","page","type-page","status-publish","hentry"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/pages\/1867","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/comments?post=1867"}],"version-history":[{"count":4,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/pages\/1867\/revisions"}],"predecessor-version":[{"id":1875,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/pages\/1867\/revisions\/1875"}],"wp:attachment":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/media?parent=1867"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}