Das Third Party Risk Management des CRA ist mehr als nur ein Compliance Thema

Erkenntnisse aus einem Expertenpanel zur Praxis des CRA und zum Third Party Risk Management

Der Cyber Resilience Act (CRA, Verordnung (EU) 2024/2847) wird oft als reines Compliance-Pflichtprogramm wahrgenommen. Eine neue Bürde im ohnehin dichten Regulierungsdschungel zwischen NIS2, DORA und DSGVO. Ein Panel im Rahmen der Prisec Germany mit erfahrenen Praktikern aus Informationssicherheit, Einkauf und CISO-Beratung zeigt jedoch ein anderes Bild: Der CRA ist im Kern ein Qualitäts- und Lebenszyklusthema und betrifft weit mehr Unternehmen, als viele auf den ersten Blick annehmen.

Wer ist betroffen? Auch Ihre mobile App fällt darunter

Eine der ersten Erkenntnisse aus der Diskussion betrifft den Geltungsbereich. Wer kein klassisches Hardware- oder Embedded-Software-Haus betreibt, glaubt schnell, vom CRA nicht betroffen zu sein. Das ist ein Trugschluss.

Ein Beispiel aus der Praxis im Kosmetikhandel: Das Unternehmen verkauft keine Programme und keine Elektronik, betreibt aber eine Mobile App für seine Kunden. Damit bringt es ein Produkt mit digitalen Elementen im Sinne des CRA in Verkehr und unterliegt dessen Anforderungen.

Jedes Unternehmen, das Software direkt oder als Bestandteil eines Produkts auf den europäischen Markt bringt, muss sich mit den CRA-Anforderungen auseinandersetzen. Das gilt auch für Kosmetikhersteller, Maschinenbauer, Pharmaunternehmen oder Dienstleister mit eigenen Apps.

Ein offener Kritikpunkt aus dem Panel: Der CRA gilt nur für Kaufsoftware, nicht für Software as a Service.

Vom Compliance-Häkchen zum Lebenszyklusmanagement

Der zentrale Paradigmenwechsel des CRA liegt im verpflichtenden Lebenszyklusmanagement. Hersteller müssen für mindestens fünf Jahre oder bis zum End of Life des Produkts Sicherheitsupdates bereitstellen und Schwachstellen aktiv managen.

Die Parallele zur klassischen Bill of Materials aus dem Produktlebenszyklusmanagement liegt auf der Hand. Was im Engineering seit Jahrzehnten Standard ist, wird mit der Software Bill of Materials (SBOM) jetzt auch für die Softwarekomponente verbindlich. Mit zunehmendem Softwareanteil in mechatronischen Produkten wird das zur Pflichtaufgabe.

Wer den CRA ernst nimmt, gewinnt nebenbei auch ein robustes Vulnerability Management. Die SBOM-Pflicht zwingt Unternehmen dazu, ihre Lieferkette transparent zu machen und Komponenten kontinuierlich zu überwachen.

Eine plakative Mahnung aus der Diskussion: Hersteller wie Porsche (Macan) oder VW (up!) konnten bestimmte Modelle nachträglich nicht mehr verkaufen, weil die Cybersecurity-Anforderungen der UN Regulation R155 zu spät im Lebenszyklus berücksichtigt wurden. Was bei der Entwicklung gespart wird, kostet später den Marktzugang.

Wer ist verantwortlich?

Die Frage nach der Verantwortlichkeit für die Lieferkettensicherheit zieht sich als roter Faden durch das Panel. Die Antwort fällt differenziert aus und folgt der klassischen Unterscheidung zwischen Rechenschaftspflicht und operativer Verantwortung:

Die Rechenschaftspflicht liegt bei der Geschäftsführung. Sie kann nicht wegdelegiert werden, denn das Unternehmen steht mit seinem Namen für das Produkt ein. Das ist die juristische Realität, die viele Vorstände noch unterschätzen.

Der CISO trägt die übergreifende Verantwortung für Informationssicherheit, kann aber nicht jedes Produkt in der nötigen Tiefe überschauen. In Großunternehmen übernimmt deshalb der Product Security Officer (PSO) die produktspezifische Detailverantwortung und arbeitet dem CISO zu. Bei Bosch etwa wurde diese Rolle früh etabliert.

Die operative Umsetzung verteilt sich auf Entwicklung, Einkauf und PSO/CISO als orchestrierende Funktion. Genau hier liegt in der Praxis das Hauptproblem: Die Bereiche reden zu wenig miteinander. Audits zeigen regelmäßig ein Silodenken, das den CRA-Anforderungen entgegensteht.

Der Einkauf als unterschätzter Schlüsselspieler

Das Third Party Risk Management ist im CRA ein zentraler Pfeiler. Und genau hier liegt eine der größten organisatorischen Hürden. Einkäufer haben Cybersecurity-Anforderungen klassisch nicht auf dem Radar.

Ein typischer Dialog aus der Auditpraxis: Auf die Frage, welche Risiken im Lieferantenmanagement betrachtet werden, kommt zunächst der Hinweis auf Ausfallrisiken. Auf konkrete Nachfrage zu Cybersecurity-Risiken wird dann oft erst die Tragweite sichtbar. Die Lösung erfordert zwei Schritte:

• Erstens muss die gesamte Einkaufsorganisation darauf geschult werden, Cybersecurity-Anforderungen in Verträge und Verhandlungen zu integrieren. Das Veto des PSO oder CISO muss als verbindliches Element im Beschaffungsprozess verankert sein.
• Zweitens braucht es klare Eskalationsmechanismen für den Fall, dass kritische Lieferanten Anforderungen nicht erfüllen können. Das Spektrum reicht von definierten Übergangsfristen über akzeptiertes Restrisiko bis hin zum bewussten Verzicht auf den Lieferanten.

Transparenz schlägt Perfektion

Eine bemerkenswerte Erkenntnis der Diskussionsteilnehmer: Lieferanten, die offen kommunizieren, dass sie bestimmte Anforderungen aktuell nicht erfüllen können, aber einen Plan dafür haben, sind Lieferanten mit pauschalem Desinteresse an Informationssicherheit klar vorzuziehen.

Ein Praxisbeispiel: Ein Anbieter im Bereich KI-gestütztes Social Media Marketing teilte offen mit, Informationssicherheit habe keine Priorität. Die Konsequenz war konsequenterweise das Ende der Geschäftsbeziehung. Hätte derselbe Anbieter Unterstützung beim Aufbau seiner Sicherheitsprozesse angefragt, wäre eine partnerschaftliche Entwicklung möglich gewesen.

Diese Haltung deckt sich mit dem Transparenzgebot des CRA. Wer offen mit Sicherheitsdefiziten umgeht, schafft die Basis für aktives Risikomanagement statt für Augenwischerei.

Das Ende der Checkbox-Mentalität

Third Party Risk Management ist heute oft checkbox-getrieben. Ausgelagerte Assessments mit hunderten Fragen, oft mechanisch durchgeklickt, liefern wenig Mehrwert. Das Panel war sich einig: Solche Fragenkataloge können eine Basis sein, ersetzen aber keine echte Bewertung.

Empfohlen wird stattdessen ein risikoorientierter Ansatz mit folgenden Elementen:

• International anerkannte Zertifizierungen (ISO 27001, SOC 2, branchenspezifische Standards) als Vertrauensanker. Sie ersetzen nicht die individuelle Prüfung, reduzieren aber den Aufwand erheblich.
• Wirtschaftlichkeitsbetrachtung im Verhältnis zum Business Value. Drei Manntage Assessment für eine Software, die 500 Euro kostet, sind selten verhältnismäßig. Der Maßstab muss die Business Impact Analyse sein: Was passiert im Schadensfall? Welche Auswirkungen hätte ein Ausfall oder eine Kompromittierung auf Produktion, Lieferkette und IT?

Vorsicht vor manipulativ wirkenden Fragebögen. Wenn ein Fragenkatalog zu Sicherheitsarchitektur und -maßnahmen unstrukturiert per E-Mail eintrifft, kann dahinter auch ein Social-Engineering-Versuch stehen. Verifizieren bleibt Pflicht.

SBOM: Die Zutatenliste der Software

Die Software Bill of Materials wird ab 2027 für bestimmte Produktklassen verpflichtend. Schon heute fordern fortschrittliche Unternehmen sie bei jedem Lieferantenassessment ein, ob Software as a Service oder Installationssoftware.

Die Analogie aus der Diskussion ist eingängig: Die SBOM ist wie die Zutatenliste auf einem Lebensmittel. Niemand will das Rezept, aber jeder will wissen, was drin ist. Und ein Hersteller, der von der Qualität seiner Zutaten überzeugt ist, hat keinen Grund, sie zu verbergen.

Wer keine SBOM liefern will oder kann, hat häufig eines von zwei Problemen: mangelnde Transparenz über die eigene Lieferkette oder mangelndes Vertrauen in die eigene Codequalität. Beides sind handfeste Warnsignale.

Wo Lieferanten die SBOM nicht direkt herausgeben, können unabhängige Prüfinstanzen als Fourth Party einspringen und die Compliance bestätigen, ohne dass der Quellcode beim Kunden landet.

Sicherheit als Qualitätsmerkmal: Schätzt das der Kunde?

Ein interessanter Spannungsbogen ergibt sich beim Endkunden. Wird der CRA tatsächlich zum Verkaufsargument? Oder bleibt es dem Kunden egal, welches Gütesiegel auf einem Gerät klebt?

Die Position des Panels: Sicherheit ist kein Zusatzfeature, sondern integraler Bestandteil der Qualitätserwartung. Wer ein Qualitätsprodukt kauft, erwartet implizit auch Sicherheit. Hersteller können also nicht damit werben, dass ihr Produkt sicher ist, und dafür einen Aufpreis verlangen. Sicherheit wird vorausgesetzt.

Die Gegenprobe: Marktplätze wie Temu, Shein oder AliExpress zeigen, dass diese Erwartung nicht universal ist. Vor allem bei jüngeren Konsumenten dominiert der Funktionsnutzen, das Risikobewusstsein für Datenflüsse ins außereuropäische Ausland ist gering. Hier entsteht ein gesellschaftlicher Bildungsauftrag in Sachen Medien-, Daten- und Risikokompetenz, den der CRA mittelbar mitadressiert.

Unterstützungszeitraum in komplexen Lieferketten

Eine der konkretesten Praxisfragen aus dem Publikum betrifft den vom CRA geforderten Unterstützungszeitraum: Wie lange müssen Hersteller Sicherheitsupdates bereitstellen, wenn sie selbst auf Drittkomponenten mit kürzerer Lebensdauer angewiesen sind?

Die Antwort des Panels ist klar: Der Unterstützungszeitraum darf nicht auf den kleinsten gemeinsamen Nenner der Komponentenlebensdauer reduziert werden. Stattdessen braucht es aktives Lebenszyklusmanagement mit mehreren Strategien:

• Modularer Produktaufbau, der den Austausch einzelner Komponenten ermöglicht.
• Ersatzlieferanten und Ersatzkomponenten, die als Backup verfügbar sind.
• Lagervorratshaltung kritischer Komponenten für die Restlaufzeit.
• Sicherung von Patenten oder Fertigungsrechten, um im Notfall selbst produzieren zu können.
• Geplante Produktrevisionen mit neuen Komponenten, die den Sicherheitsstandard weiterhin erfüllen.

Letztlich ist es eine Risiko- und Wirtschaftlichkeitsentscheidung. Ohne aktives Lebenszyklusmanagement wird der CRA zur strategischen Falle.

Was das für jede Organisation bedeutet

Aus dem Panel lassen sich mehrere konkrete Handlungsempfehlungen für DSB, ISB und Geschäftsführung ableiten:

Für die Geschäftsführung: Die Rechenschaftspflicht für CRA-Compliance liegt bei ihr und kann nicht wegdelegiert werden. Verankern Sie klare Strukturen mit CISO, PSO und Entwicklungsleitung und sorge für ausreichende Ressourcen.

Für CISO und ISB: Verstehen Sie ihre Rolle als Orchestrator. Die Detailarbeit machen andere, aber das Zusammenspiel zwischen Entwicklung, Einkauf und Produktmanagement zu sichern, ist Ihre Kernaufgabe. Ohne diese Brückenfunktion zerfällt der CRA in lauter Silo-Initiativen.

Für Datenschutzbeauftragte: Die Schnittstellen zwischen CRA und DSGVO sind eng. Privacy by Design und Security by Design verschmelzen im CRA-Kontext. Nutzen Sie die Gelegenheit, gemeinsam mit der Informationssicherheit integrierte Prozesse aufzubauen.

Für Einkauf und Beschaffung: Cybersecurity-Anforderungen gehören in jeden Lieferantenvertrag, der Software oder digitale Komponenten betrifft. Schulen Sie ihre Einkäufer und etablieren sie klare Eskalationspfade zum CISO oder PSO.

Fazit: Der CRA als Hebel für Qualität

Wer den Cyber Resilience Act als Compliance-Pflicht abhakt, verpasst die strategische Chance.

Richtig umgesetzt bedeutet der CRA: bessere Produktqualität, transparentere Lieferketten, robusteres Vulnerability Management und letztlich stärkere Kundenbindung.

Die größte Hürde liegt nicht in der Technik, sondern in der Organisation. Entwicklung, Einkauf und Sicherheit müssen miteinander reden, sich verstehen und gemeinsam Verantwortung tragen. Wer diese kulturelle Hürde nimmt, gewinnt mehr als ein Compliance-Häkchen. Er baut ein Unternehmen, das auch in der digital vernetzten Welt belastbar bleibt.

Dieser Beitrag basiert auf einem Expertenpanel mit Praktikern aus Informationssicherheit, Einkauf und CISO-Beratung. Mrak Consulting begleitet Unternehmen bei der Umsetzung des Cyber Resilience Act und beim Aufbau integrierter Compliance-Strukturen zwischen CRA, NIS2, DORA und DSGVO.

Transparenzhinweis: Dieser Beitrag wurde mit Unterstützung generativer KI (Claude Opus 4.7, Anthropic) erstellt und vor Veröffentlichung redaktionell geprüft.