Cyber Resilience Act für Hersteller vernetzter Produkte

Letztes Update: 06.06.2026

Der Cyber Resilience Act (CRA) macht Cybersicherheit für Produkte mit digitalen Elementen zu einem strukturierten Produkt- und Lifecycle-Thema. Für Hersteller vernetzter Produkte geht es deshalb nicht nur um einzelne technische Maßnahmen, sondern um nachvollziehbare Produktsecurity über Entwicklung, Komponenten, Updates, Schwachstellenprozesse und Dokumentation hinweg.

Dieser Beitrag bietet eine allgemeine Orientierung für Hersteller und Produktverantwortliche. Für konkrete Produkte sollten Scope, Produktrolle, Produktklassifikation und Nachweisweg produktbezogen geprüft werden.

Was der CRA für Hersteller vernetzter Produkte bedeutet

Der CRA ist eine EU-Verordnung für Produkte mit digitalen Elementen. Dazu können Software, Hardware, Firmware, Komponenten und vernetzte physische Produkte gehören. Entscheidend ist nicht nur, ob ein Produkt digital ist, sondern welche Rolle das Produkt im Markt hat, wie es verbunden ist und welche Funktionen es erfüllt.

Für Hersteller wird damit wichtig, Produktsecurity nicht erst am Ende eines Entwicklungsprojekts zu betrachten. Viele CRA-relevante Fragen entstehen früher:

• ●
  Welche Produktfamilien sind betroffen?
• ●
  Wer trägt intern Verantwortung für Produktsecurity?
• ●
  Welche Komponenten und Abhängigkeiten stecken im Produkt?
• ●
  Wie werden Schwachstellen gemeldet, bewertet und kommuniziert?
• ●
  Wie werden Updates über den Lebenszyklus geplant und verteilt?
• ●
  Welche technische Dokumentation ist belastbar vorhanden?

Der wichtigste erste Schritt ist daher meistens kein großes Audit, sondern eine saubere Einordnung: Produkt, Rolle, Entwicklungsstand, vorhandene Prozesse und nächster sinnvoller Arbeitsschritt.

Warum CRA-Vorbereitung ein Lebenszyklus-Thema ist

Die CRA-Quellen beschreiben Cybersicherheit als Aufgabe über den gesamten Produktlebenszyklus. Das umfasst Planung, Design, Entwicklung, Herstellung, Bereitstellung, Wartung, Schwachstellenbehandlung, Updates, technische Dokumentation und Informationen für Nutzer.

Praktisch heißt das: Ein Produktteam braucht nicht nur eine Liste technischer Kontrollen. Es braucht ein Arbeitsmodell, das Sicherheit mit Entwicklung, Produktmanagement, Qualität, Support und Management verbindet.

Typische Fragen sind:

• ●
  Wo wird Risiko im Produktprozess sichtbar gemacht?
• ●
  Wer entscheidet über Security-Anforderungen?
• ●
  Wie werden Sicherheitsannahmen getestet?
• ●
  Wie werden Schwachstellen nach Release behandelt?
• ●
  Welche Informationen brauchen Nutzer, Kunden oder Partner?

Diese Lifecycle-Sicht ist auch der Grund, warum CRA-Vorbereitung früh beginnen sollte. Spätere Nacharbeit ist oft schwieriger, wenn Architektur, Updateprozess, Dokumentation und Verantwortlichkeiten schon feststehen.

Welche Produkte und Rollen zuerst eingeordnet werden sollten

Für die erste Orientierung lohnt sich ein kurzer Produkt- und Rollencheck. Dabei geht es nicht darum, sofort eine finale Klassifikation festzulegen. Es geht darum, die richtigen Fragen sichtbar zu machen.

Wichtige Startfragen:

• ●
  Handelt es sich um Software, Hardware, Firmware, ein vernetztes Gerät oder eine Komponente?
• ●
  Wird das Produkt im EU-Markt bereitgestellt oder ist EU-Marktzugang geplant?
• ●
  Gibt es direkte oder indirekte Datenverbindungen zu Geräten oder Netzwerken?
• ●
  Gibt es eine entfernte Datenverarbeitung, ohne die das Produkt eine Funktion nicht erfüllen könnte?
• ●
  Ist das Unternehmen Hersteller, Anbieter, Integrator, Importeur, Distributor oder in einer anderen Rolle beteiligt?
• ●
  In welchem Entwicklungsstand ist das Produkt: Konzept, Entwicklung, Markteinführung, Wartung oder Long-Term-Support?

Gerade bei Cloud- oder SaaS-Bezügen sollte nicht pauschal entschieden werden. Entscheidend ist der Produktzusammenhang: Gehört eine entfernte Datenverarbeitung zur Produktfunktion, oder handelt es sich um einen unabhängigen Dienst?

Produktklassifikation: Kernfunktion statt Bauchgefühl

Für wichtige oder kritische Produktkategorien ist die Kernfunktion eines Produkts ein zentraler Orientierungspunkt. Die Quellen machen deutlich: Die Integration einer Komponente, die selbst einer Kategorie zugeordnet werden könnte, bedeutet nicht automatisch, dass das Gesamtprodukt dieselbe Kategorie erfüllt. Entscheidend ist die Funktion des Produkts als Ganzes.

Für Embedded- und Produktteams ist das praktisch relevant. Beispiele aus den technischen Beschreibungen betreffen unter anderem eingebettete Browser, Bootmanager, physische und virtuelle Netzschnittstellen, Betriebssysteme einschließlich Echtzeit-Betriebssystemen, Router, Modems, Switches und bestimmte Sicherheitskomponenten.

Für die Vorbereitung heißt das:

• ●
  Produktfunktion beschreiben
• ●
  integrierte Komponenten und Abhängigkeiten sichtbar machen
• ●
  mögliche wichtige oder kritische Kategorien prüfen
• ●
  Annahmen dokumentieren
• ●
  offene Punkte für qualifizierte Bewertung markieren

Das ist ein gutes Thema für ein frühes Embedded-Security-Erstgespräch, weil es Produktwissen, Architektur und regulatorische Orientierung zusammenbringt.

Security by Design und sichere Entwicklung

CRA-Vorbereitung berührt sichere Entwicklung sehr direkt. Produkte sollen nicht erst nachträglich abgesichert werden, sondern mit angemessenen Sicherheitsanforderungen, Risikobewertung und nachvollziehbaren Maßnahmen entwickelt werden.

Typische Arbeitspakete:

• ●
  Produkt- und Risiko-Kontext beschreiben
• ●
  Threat Modeling oder vergleichbare Risikobetrachtung durchführen
• ●
  Security-Anforderungen in Entwicklung und Architektur verankern
• ●
  sichere Defaults und Updatefähigkeit berücksichtigen
• ●
  Review- und Testaktivitäten planen
• ●
  Entscheidungen und Restrisiken dokumentieren

Das Ziel ist keine abstrakte Sicherheitscheckliste, sondern ein Prozess, mit dem Produktteams arbeiten können. Gute CRA-Vorbereitung macht Verantwortlichkeiten, Nachweise und nächste Schritte sichtbar.

SBOM-Readiness: Komponenten verstehen, nicht nur Listen erzeugen

Eine Software Bill of Materials (SBOM) ist eine maschinenverarbeitbare Komponentenübersicht. Sie hilft zu verstehen, welche Softwarebestandteile und Abhängigkeiten in einem Produkt enthalten sind.

Wichtig ist die Abgrenzung: Eine SBOM ist nicht automatisch eine Aussage darüber, ob ein Produkt durch eine Schwachstelle tatsächlich betroffen oder ausnutzbar ist. SBOM-Daten sind eher statisch; Schwachstelleninformationen ändern sich laufend. Deshalb gehört SBOM-Readiness immer mit Vulnerability Handling zusammen.

Praktische Fragen:

• ●
  Für welche Produktversionen gibt es SBOMs?
• ●
  Welche Formate und Datenfelder werden verwendet?
• ●
  Wie werden Komponenten, Versionen und Abhängigkeiten gepflegt?
• ●
  Wie werden SBOM-Daten mit CVEs, Security Advisories oder VEX/CSAF-Informationen verbunden?
• ●
  Wer bewertet, ob eine bekannte Schwachstelle das eigene Produkt tatsächlich betrifft?

Das ist der Grund, warum wir öffentlich von SBOM-Readiness sprechen und nicht von einem fertigen SBOM-Monitoring-Produkt.

Schwachstellenprozesse: CVD, PSIRT, Kontaktwege und Advisories

Vulnerability Handling ist ein operativer Prozess. BSI TR-03183 Part 3 beschreibt dafür unter anderem eingehende Schwachstellenberichte, koordinierte Offenlegung, Kontaktwege, Rollen, CVD-Policy, Security Advisories und security.txt.

Für Hersteller heißt das: Es sollte vor dem ersten echten Vorfall klar sein, wie ein Hinweis auf eine Schwachstelle verarbeitet wird.

Typische Klärungspunkte:

• ●
  Wo können externe Personen eine Schwachstelle melden?
• ●
  Welche Kontaktwege, Sprachen und Verschlüsselungsoptionen gibt es?
• ●
  Wer triagiert eingehende Meldungen?
• ●
  Wann wird intern eskaliert?
• ●
  Wie entstehen Security Advisories oder Update-Kommunikation?
• ●
  Welche Rolle spielen Engineering, Produktmanagement, Support, Qualität und Management?

Ein PSIRT muss nicht sofort als große Organisationseinheit starten. Für viele Hersteller beginnt es mit klaren Rollen, einem Kontaktweg, einer CVD-Policy und einem wiederholbaren Ablauf.

Updates, Supportzeitraum und technische Dokumentation

Updatefähigkeit, Supportzeitraum und technische Dokumentation gehören zusammen. Ein Produkt kann nur zuverlässig betreut werden, wenn klar ist, welche Versionen unterstützt werden, wie Sicherheitsupdates verteilt werden und wie Entscheidungen dokumentiert sind.

Relevante Themen:

• ●
  Update-Verteilung und Nutzerinformation
• ●
  Trennung von Sicherheitsupdates und Funktionsupdates, wo sinnvoll
• ●
  Supportzeitraum und Lifecycle-Erwartungen
• ●
  sichere Nutzung und Konfiguration
• ●
  sichere Außerbetriebnahme
• ●
  Nachweise zu Risikobewertung, Tests, Standards und Produktsecurity-Maßnahmen

Auch hier gilt: Die Dokumentation sollte nicht erst am Ende entstehen. Sie ist ein Nebenprodukt sauberer Entscheidungen im Produktprozess.

Was ein erstes Embedded-Security-Erstgespräch klären sollte

Ein gutes Erstgespräch muss nicht alle CRA-Fragen abschließend beantworten. Es sollte aber genug Struktur schaffen, damit die nächsten Schritte klar werden.

Sinnvolle Fragen für den Einstieg:

• ●
  Welches Produkt oder welche Produktfamilie steht im Fokus?
• ●
  In welchem Lifecycle-Status befindet sich das Produkt?
• ●
  Welche CRA-Frage treibt Sie aktuell am stärksten: Scope, Klassifikation, SBOM, Schwachstellenprozess, Updates oder Dokumentation?
• ●
  Welche Rollen sind intern beteiligt?
• ●
  Was gibt es bereits: Risikoanalyse, SBOM, Vulnerability-Kontakt, CVD-Policy, Updateprozess, technische Dokumentation?
• ●
  Soll der nächste Schritt eine Orientierung, ein Gap-Bild, ein Workshop oder Umsetzungsunterstützung sein?

Embedded-Security-Erstgespräch anfragen

Fazit: strukturiert vorbereiten

CRA-Vorbereitung ist für Hersteller vernetzter Produkte vor allem eine Strukturaufgabe. Wer Produktfunktion, Rollen, SBOM-Readiness, Schwachstellenprozesse, Updates und Dokumentation früh ordnet, kann später gezielter entscheiden und besser erklären, wie Produktsecurity im eigenen Lifecycle funktioniert.

Der passende Einstieg ist eine technisch-organisatorische Orientierung: Was ist für Ihr Produkt relevant, was ist bereits vorhanden, und welcher nächste Schritt bringt Klarheit?