Cyber Resilience Act

Mit dem Cyber Resilience Act (CRA) hat die Europäische Union einen regulatorischen Rahmen geschaffen, der Cybersicherheit direkt in die Produktverantwortung überführt. Die Verordnung richtet sich an Hersteller, Importeure und weitere Wirtschaftsakteure, die Produkte mit digitalen Elementen auf dem europäischen Markt bereitstellen. Damit wird Cybersicherheit nicht mehr als separates IT-Thema behandelt, sondern als feste Eigenschaft eines Produkts.

Für Unternehmen mit Hardware, Embedded Software, industrieller Elektronik, vernetzter Sensorik oder eigenständigen Softwareprodukten ist der CRA ein operatives Thema. Anforderungen an Entwicklung, Dokumentation, Wartung und Schwachstellenmanagement werden Bestandteil des regulären Produktgeschäfts. Besonders relevant ist das für Branchen mit langen Lebenszyklen, technischen Variantenständen und komplexen Lieferketten.

Umfang

Produkte mit digitalen Elementen

Der CRA verwendet den Begriff „Produkte mit digitalen Elementen“. Gemeint sind Produkte, deren Funktion ganz oder teilweise durch Software, Firmware, Datenverarbeitung oder Vernetzung geprägt ist. Darunter fallen klassische Konsumprodukte ebenso wie industrielle Systeme, Maschinenkomponenten, Steuergeräte, Kommunikationsmodule oder softwarebasierte Anwendungen.

Fü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 Steuergerät mit Ethernet-Schnittstelle, ein Diagnosezugang über USB, eine Weboberfläche für Parametrierung oder ein cloudfähiges Gateway führen ein Produkt in einen Bereich, in dem Cybersicherheit regulatorisch relevant wird.

Die praktische Folge ist eine Neubewertung des Portfolios. Unternehmen mü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ällt.

Der CRA unterscheidet zwischen allgemeinen Produkten mit digitalen Elementen und besonders relevanten Produktgruppen mit erhöhten Anforderungen. Ein großer Teil der Produkte fällt in den Bereich der regulären Konformitätsbewertung mit interner Herstellerverantwortung. Dazu zählen zahlreiche Standardprodukte aus dem Software- und Consumer-Umfeld.

Für definierte Produktgruppen aus Annex III gelten strengere Anforderungen. Diese Produkte sind in Class I und Class II unterteilt. Maßgeblich sind technische Funktion, Einsatzbereich und potenzieller Einfluss auf Sicherheit und Infrastruktur.

Class I umfasst unter anderem Produkte wie Netzwerkinterfaces, Firewalls oder bestimmte Mikrocontroller-Plattformen. Hier erfolgt die Bewertung typischerweise über harmonisierte Standards oder geeignete Prüfverfahren.

Class II betrifft besonders sensible oder systemrelevante Komponenten wie Prozessoren, Secure Elements, Betriebssysteme oder industrielle Firewalls. In diesen Fällen steigt die regulatorische Prüftiefe, häufig unter Einbindung externer Stellen.

Cybersicherheit als Teil der Entwicklungsdisziplin

Der CRA verankert Cybersicherheit in der Entstehung des Produkts. Konstruktion, Elektronikentwicklung, Softwareentwicklung und Systemarchitektur müssen Sicherheitsanforderungen frühzeitig berücksichtigen. Das betrifft nicht nur sichtbare Sicherheitsfunktionen, sondern grundlegende Designentscheidungen.

Eine Architektur mit unnötig offenen Schnittstellen, ungeschützten Servicezugängen oder fehlender Trennung von Vertrauensbereichen erzeugt Risiken, die sich später nur mit hohem Aufwand korrigieren lassen. Der CRA erhöht daher die Bedeutung früher Architekturentscheidungen. Sicherheitsaspekte gehören in Anforderungsmanagement, Systemdesign, Schnittstellendefinition, Auswahl von Komponenten und Integrationskonzepte.

In Embedded-Systemen betrifft das regelmäßig Themen wie sichere Bootketten, Schutz von Debug-Zugängen, Integrität von Firmware, Rechtekonzepte für Wartungsfunktionen, sichere Kommunikationskanäle und kontrollierte Update-Mechanismen. Auch Speicher- und Laufzeitschutz durch MPU, TrustZone oder vergleichbare Mechanismen gewinnt an Bedeutung.

Unternehmen mit etablierten Entwicklungsprozessen können diese Anforderungen strukturiert integrieren. Organisationen ohne klar definierte Engineering-Gates werden stärker nachsteuern müssen, weil Sicherheit nachvollziehbar geplant und umgesetzt werden muss.

Schwachstellenmanagement gemäß Cyber Resilience Act

Ein zentrales Element des CRA ist die fortlaufende Verantwortung nach dem Inverkehrbringen. Produkte bleiben auch nach Auslieferung sicherheitsrelevant. Hersteller benötigen Prozesse, mit denen Schwachstellen aufgenommen, bewertet, priorisiert und behoben werden.

Das verändert die klassische Sicht vieler Produktunternehmen. In zahlreichen Industriebereichen galt der Serienstart lange als Übergang von Entwicklung in Support. Der CRA verschiebt dieses Modell. Sicherheitsarbeit läuft über den Lebenszyklus weiter. Dazu gehören Meldestrukturen für externe Hinweise, interne Bewertung technischer Risiken, Entwicklung von Korrekturmaßnahmen, Test neuer Softwarestände und geregelte Bereitstellung von Updates.

Für Produkte im Feld stellt sich damit unmittelbar die Frage nach technischer Updatefähigkeit. Systeme ohne sichere Updatefunktion verursachen im Fall einer Schwachstelle hohe operative Kosten, weil Serviceeinsätze, manuelle Nacharbeiten oder Hardwaretausch erforderlich werden können. Bereits deshalb ist Updatefähigkeit nicht nur ein Compliance-Thema, sondern ein wirtschaftlicher Faktor.

Dokumentation und Nachweisfähigkeit

Der CRA verlangt Nachweisfähigkeit. Unternehmen müssen zeigen können, wie Sicherheitsanforderungen umgesetzt wurden. Das betrifft technische Dokumentation ebenso wie interne Prozesse und Konformitätsunterlagen.

In der Praxis reicht eine allgemeine Produktbeschreibung dafü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üfungen, Validierungen und Freigaben gewinnen an Gewicht.

Viele Unternehmen besitzen umfangreiche Entwicklungsdaten, jedoch keine strukturierte Security-Dokumentation. Der CRA führt daher häufig nicht zu völlig neuen Tätigkeiten, sondern zur Notwendigkeit, vorhandene technische Arbeit systematisch dokumentierbar zu machen.

Für Engineering-Organisationen ist das ein wichtiger Punkt: Wer Architekturentscheidungen, Tests und Freigaben sauber führt, reduziert späteren Aufwand bei Nachweisen erheblich.

Lieferketten und Zukaufkomponenten

Digitale Produkte bestehen selten nur aus Eigenentwicklung. Betriebssysteme, Middleware, Funkmodule, Bibliotheken, Open-Source-Komponenten, Halbleiterplattformen und externe Softwarebausteine sind Standard. Der CRA erhöht damit automatisch die Relevanz des Lieferantenmanagements.

Ein Hersteller muss wissen, welche Komponenten im Produkt verwendet werden, welche Abhängigkeiten bestehen und wie Sicherheitsupdates aus der Lieferkette verfügbar werden. Besonders kritisch sind Bausteine ohne langfristige Pflege, nicht dokumentierte Fremdsoftware oder Plattformen mit unklarer Security-Roadmap.

Im Embedded-Umfeld betrifft das beispielsweise Mikrocontroller-SDKs, Linux-Distributionen, Kommunikationsstacks, Wireless-Module oder proprietäre Drittbibliotheken. Fehlt Transparenz, entstehen Risiken bei Wartbarkeit und Nachweisführung.

Deshalb wird Stücklistenlogik im Softwarebereich wichtiger. Software Bill of Materials, Versionskontrolle und geregelte Freigaben werden für viele Hersteller zum Standardwerkzeug.

Bedeutung für industrielle Elektronik und Maschinenbau

Der CRA wird häufig mit Consumer-IoT verbunden. Für den industriellen Bereich ist er ebenso relevant. Moderne Maschinen, Steuerungen und Anlagen enthalten Netzwerktechnik, Fernwartung, Datenlogging, Feldbus-Gateways und servicefähige Embedded-Systeme. Damit entstehen dieselben Grundfragen wie in anderen digitalen Produkten.

In industriellen Umgebungen kommen zusätzliche Anforderungen hinzu. Lebenszyklen sind länger, Freigabeprozesse strenger, Änderungen im Feld aufwendiger und Stillstandszeiten teuer. Ein Sicherheitsupdate kann hier nicht isoliert betrachtet werden, sondern muss mit Betrieb, Validierung und Produktionsrealität zusammenpassen.

Das verlangt robuste Engineering-Prozesse. Unternehmen benötigen klare Strategien, wie Security-Updates geprüft, freigegeben und ausgerollt werden, ohne die Verfügbarkeit technischer Systeme zu gefährden.

Organisatorische Folgen im Unternehmen

Der CRA ist nicht Aufgabe einzelner Security-Spezialisten. Betroffen sind Produktmanagement, Entwicklung, Qualität, Einkauf, Service, Dokumentation und Geschäftsleitung. Rollen und Verantwortlichkeiten müssen eindeutig sein.

Produktmanagement muss Anforderungen und Marktverantwortung steuern. Entwicklung muss technische Maßnahmen umsetzen. Einkauf muss Lieferantenfähigkeit bewerten. Service benötigt Prozesse für Feldmaßnahmen. Qualität und Management brauchen Transparenz über Risiken, Reifegrad und Nachweise.

In vielen mittelständischen Unternehmen wird dadurch erstmals eine formalisierte Product-Security-Struktur entstehen. Das kann durch dedizierte Rollen, klare Freigabemechanismen oder integrierte Verantwortlichkeiten im bestehenden Qualitätsmanagement erfolgen.

Cybersicherheit wird also bei Produkten mit digitalen Elementen ein durchgängiger Entwicklungsprozess von Anforderungen, Architektur und Implementierung bis zu Verifikation, Penetration Testing, Updates und Schwachstellenmanagement. Der CRA stärkt genau diesen Lifecycle-Ansatz, bei dem TARA, Security Requirements und regelmäßige Re-Assessment-Zyklen fester Bestandteil der Produktpflege werden.

Secure Engineering und Security By Design

Unternehmen, die den CRA ausschließlich juristisch betrachten, greifen zu kurz. Die eigentliche Arbeit liegt im Engineering. Sicherheitsarchitektur, Updatefähigkeit, Komponentenstrategie, Testbarkeit und technische Dokumentation entscheiden darüber, wie aufwendig Compliance tatsächlich wird.

Wer Produkte mit modularer Softwarestruktur, sauberer Schnittstellentrennung und nachvollziehbarer Konfiguration entwickelt, schafft günstigere Voraussetzungen. Wer historisch gewachsene Plattformen mit ungepflegten Altkomponenten betreibt, wird höhere Aufwände sehen.

Deshalb ist der CRA auch ein Modernisierungstreiber. Viele notwendige Maßnahmen verbessern nicht nur regulatorische Lage, sondern auch Wartbarkeit, Produktqualität und Beherrschbarkeit komplexer Systeme.

Sobald Elektronik durch Firmware oder Software gesteuert wird und zusätzlich Schnittstellen zu Netzwerken, Servicegeräten oder anderen Teilnehmern besitzt, entsteht eine Angriffsfläche. Genau an dieser Stelle setzt der CRA an. Die Verordnung fordert nicht einzelne isolierte Sicherheitsfunktionen, sondern einen nachvollziehbaren Sicherheitsansatz über den gesamten Produktlebenszyklus.

Für Unternehmen bedeutet das: Sicherheit muss als technischer Entwicklungsprozess organisiert werden.

Maßnahmen für die Elektronik-Entwicklung

Ein Gerä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öffnet. Der Begriff des Netzwerks ist dabei bewusst sehr weit

Ein Mikrocontroller ohne klassische Internetverbindung kann betroffen sein, wenn er über ein Gateway erreichbar ist, Diagnosedaten austauscht oder Teil eines größeren vernetzten Systems ist.

Daraus folgt eine zentrale Interpretation: Nicht die Branche entscheidet über die Relevanz, sondern die technische Exponierung des Produkts.

TARA: Threat And Risk Assessment

Ein zentrales Werkzeug zur praktischen Umsetzung ist die Threat Analysis and Risk Assessment (TARA). Der CRA verwendet nicht den Begriff TARA, verlangt jedoch inhaltlich genau diesen Denkansatz: Risiken erkennen, Bedrohungen bewerten, Schutzmaßnahmen ableiten.

Für Elektronik mit Software bedeutet das, dass zunächst die Systemarchitektur verstanden werden muss. Danach werden Assets identifiziert. Dazu zählen Firmware, Bootloader, Schlüsselmaterial, Konfigurationsdaten, Kommunikationskanäle, Messwerte, Aktorik, Safety-Funktionen oder Produktionsparameter.

Im nächsten Schritt werden Bedrohungen untersucht. Typische Beispiele sind:

• Manipulation von Firmware
• unautorisierter Zugriff auf Wartungsfunktionen
• Netzwerkangriffe auf Dienste und Ports
• Denial of Service gegen Steuerfunktionen
• Diebstahl kryptografischer Schlüssel
• Replay- oder Spoofing-Angriffe
• Rechteausweitung über Softwarefehler
• Missbrauch unsicherer Updatepfade

Aus dieser Analyse entstehen technische Anforderungen. Ohne TARA fehlt die belastbare Grundlage, welche Schutzmaßnahmen tatsächlich notwendig sind.

Security by Design

Der CRA verlangt, dass Sicherheit nicht nachträglich aufgesetzt wird. Für Elektronikprodukte heißt das, dass Security bereits in Architektur, Hardwareauswahl und Softwarestruktur verankert werden muss.

Ein typisches Embedded-System sollte daher bereits in der Konzeptphase folgende Fragen beantworten:

Wie wird Vertrauen im System aufgebaut?
Welche Komponente startet zuerst?
Wie wird Firmware geprüft?
Welche Schnittstellen sind im Feld aktiv?
Welche Rechte hat ein Service-Techniker?
Wie werden Schlüssel gespeichert?
Wie werden Logs erzeugt?
Wie kann ein Update sicher eingespielt werden?

Security by Design führt regelmäßig zu Maßnahmen wie Secure Boot, signierten Images, deaktivierten Debug-Schnittstellen im Feld, Segmentierung interner Funktionen, rollenbasierten Zugängen und gehärteten Kommunikationsprotokollen.

Wird dies erst spät berücksichtigt, steigen Aufwand, Kosten und technische Risiken erheblich.

Anforderungen Hardware und Software

Viele Unternehmen betrachten Security primär als Softwarethema. Bei vernetzter Elektronik greift das zu kurz. Der CRA betrifft das Gesamtsystem. Deshalb müssen Hardware- und Softwareanforderungen getrennt und gemeinsam betrachtet werden.

Auf Hardwareseite sind häufig relevant:

• Secure Elements oder HSM
• geschützte Schlüsselablage
• Debug-Port-Kontrolle
• MPU / Memory Protection
• TrustZone oder vergleichbare Isolation
• physische Manipulationsresistenz je nach Produktklasse
• sichere Reset- und Recovery-Pfade

Auf Softwareseite sind regelmäßig erforderlich:

• sichere Authentisierung
• Rollen- und Rechtekonzepte
• Härtung von Netzwerkdiensten
• Input Validation
• Speicherfehlervermeidung
• Update- und Rollback-Konzepte
• Logging sicherheitsrelevanter Ereignisse
• sichere Konfiguration im Auslieferzustand

Erst das Zusammenspiel beider Ebenen ergibt ein belastbares Sicherheitsniveau.

Penetration Testing

Der CRA verlangt wirksame Sicherheitsmaßnahmen. In der Praxis reicht eine reine Dokumentation dafür nicht aus. Unternehmen müssen prüfen, ob Schutzmaßnahmen tatsächlich funktionieren. Penetration Testing ist dafür ein zentrales Instrument.

Bei Embedded-Produkten umfasst das typischerweise:

• Netzwerkscans und Serviceanalyse
• Authentisierungsprüfungen
• Test unsicherer Standardzugänge
• Update-Manipulationsversuche
• Webinterface-Tests
• API-Tests
• Protokollfuzzing
• Hardwarezugriff über UART, JTAG, SWD oder ähnliche Schnittstellen
• Extraktion von Firmware und Secrets
• Prüfung von Rechteeskalationen

Penetration Testing sollte risikobasiert geplant werden. Kritische Funktionen, externe Schnittstellen und privilegierte Zugänge erhalten Priorität.

Für viele Unternehmen ist dies der Übergang von theoretischer Security zu messbarer Produktsicherheit.

Regelmäßiger Prozess

Die vielleicht wichtigste Interpretation des CRA lautet: Cybersicherheit ist kein Projekt mit Enddatum. Sie ist ein laufender Prozess.

Ein Produkt, das heute freigegeben wurde, kann morgen durch neue Schwachstellen, neue Angriffsmethoden oder neue Abhängigkeiten betroffen sein. Deshalb müssen Hersteller wiederkehrende Abläufe etablieren:

• regelmäßige Neubewertung der TARA
• Schwachstellenmonitoring für eingesetzte Komponenten
• Pflege von Open-Source-Abhängigkeiten
• Security Regression Tests
• erneute Penetration Tests bei größeren Releases
• Patch- und Updateprozesse
• Incident Handling
• Dokumentationspflege

Besonders bei Produkten mit langen Feldlaufzeiten entscheidet dieser Prozess über die tatsächliche Compliance.

Fazit

Der Cyber Resilience Act macht Cybersicherheit zu einer verbindlichen Produkteigenschaft im europäischen Markt. Fü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äten verschiebt sich der Schwerpunkt auf saubere technische Strukturen, dokumentierte Prozesse und wartbare Plattformen.

Unternehmen, die frühzeitig Engineering, Lieferkette und Lifecycle-Management auf diese Anforderungen ausrichten, schaffen belastbare Voraussetzungen für künftige Produktgenerationen.