Was Unternehmen wirklich über den Cyber Resilience Act lernen

Willkommen bei OmniTrusts Serie „CRA Lessons Learned“.

Als der Cyber Resilience Act (CRA) der Europäischen Union erstmals vorgestellt wurde, behandelten die meisten Organisationen ihn wie jede andere neue Regulierung. Die ersten Fragen waren vorhersehbar: Gilt er für uns? Welche Produkte fallen in den Anwendungsbereich? Welche Dokumentation wird verlangt? Wie viel Aufwand bedeutet die Compliance?

Mit dem Übergang von der Planung zur Umsetzung zeigt sich jedoch eine andere Realität.

Die Organisationen, die die größten Fortschritte machen, konzentrieren sich nicht mehr darauf, die Verordnung an sich zu verstehen. Sie konzentrieren sich darauf, wie sie sie über ganze Produktportfolios, Entwicklungsorganisationen, Lieferketten und Support-Lebenszyklen hinweg operationalisieren können.

Genau dort beginnt die eigentliche Arbeit.

Und dort entstehen auch die wichtigsten Erkenntnisse.

In den vergangenen Monaten hat OmniTrust mit Herstellern, Softwareanbietern und Anbietern vernetzter Produkte zusammengearbeitet, die ihre CRA-Programme aufbauen. Trotz sehr unterschiedlicher Branchen, Produktarten und Reifegrade wiederholen sich viele Herausforderungen.

Diese Serie „Tales From the Trenches“ fasst diese praktischen Erkenntnisse zusammen – nicht als juristische Auslegung der CRA, sondern als Beobachtungen dazu, was Unternehmen tatsächlich bewältigen müssen, wenn sie Compliance in die Praxis überführen.

CRA-Compliance ist größer als ein Sicherheitsprojekt

Eine der deutlichsten Erkenntnisse ist, dass der CRA kein Projekt ist, das ein Cybersecurity-Team allein lösen kann.

Natürlich ist Sicherheit zentral. Schwachstellenmanagement, sichere Entwicklung, Incident Response, Kryptografie und Software-Supply-Chain-Sicherheit spielen eine wichtige Rolle.

Doch nachhaltige Compliance verlangt viel mehr. Unternehmen müssen wissen, welche Produkte sie unterstützen, welche Software darin enthalten ist, welche Verpflichtungen für jedes Produkt gelten, wer für Entscheidungen verantwortlich ist, welche Lieferanten beteiligt sind, welche Nachweise vorhanden sind und wie Risiken über Jahre hinweg verwaltet werden.

Das verbindet Engineering, Produkmanagement, Security, Qualität, Recht, Compliance, Beschaffung, Support und Führungsebene.

Viele Unternehmen stellen deshalb fest, dass ihre größte Herausforderung nicht darin besteht, eine einzelne Sicherheitskontrolle einzuführen. Die Herausforderung besteht darin, ein Betriebsmodell zu schaffen, das all diese Funktionen über den gesamten Produktlebenszyklus hinweg verbindet.

Warum wir diese Serie schreiben

Es gibt bereits zahlreiche Zusammenfassungen des Cyber Resilience Act. Diese Serie verfolgt einen anderen Zweck.

Wir möchten die praktischen Lektionen teilen, die bei realen CRA-Readiness-Programmen sichtbar werden: die überraschenden Schwierigkeiten, die wiederkehrenden Fehlannahmen, die organisatorischen Engpässe und die Fähigkeiten, die am Ende den größten Unterschied machen.

In den kommenden Beiträgen behandeln wir unter anderem:

  • warum die Definition des Produktumfangs häufig schwieriger ist als erwartet,
  • warum ein hoher Security-Reifegrad allein keine CRA-Bereitschaft garantiert,
  • warum die schwierigste Arbeit oft erst nach der Produkteinführung beginnt,
  • warum die 24-Stunden-Meldepflicht in Wahrheit ein Sichtbarkeitsproblem ist,
  • warum auf endgültige Standards zu warten eine riskante Strategie ist,
  • warum CRA-Compliance eine unternehmensweite Koordination erfordert,
  • warum Lieferanten zu einem der größten Compliance-Risiken werden können,
  • warum Open-Source-Software inzwischen ein Thema für die Führungsebene ist und
  • warum die Bewertung oft einfacher ist als die anschließende Behebung.

Die gemeinsame Erkenntnis: Compliance muss kontinuierlich sein

Hinter all diesen Themen steht dieselbe Grundidee: CRA-Compliance ist kein einmaliger Check.

Produkte ändern sich. Software ändert sich. Schwachstellen werden entdeckt. Lieferanten ändern sich. Vorschriften und Leitlinien entwickeln sich weiter. Kundenanforderungen verändern sich. Support-Verpflichtungen laufen über Jahre.

Deshalb müssen Unternehmen einen kontinuierlichen Prozess schaffen, mit dem sie Risiken erkennen, Entscheidungen dokumentieren, Maßnahmen steuern, Nachweise pflegen und ihren Compliance-Status erneut bewerten können, sobald sich relevante Bedingungen ändern.

Das ist Lifecycle Governance.

Und genau hier überschneidet sich CRA-Compliance mit einem breiteren Wandel in der Cybersecurity: weg von punktuellen Bewertungen, hin zu kontinuierlicher Steuerung von Vertrauen, Risiko und Compliance.

Was erfolgreiche Organisationen anders machen

Die Unternehmen, die bei der CRA-Vorbereitung am schnellsten vorankommen, warten nicht auf perfekte Klarheit. Sie bauen die Grundlagen, die unabhängig von einzelnen Detailfragen erforderlich sein werden.

Dazu gehören ein belastbares Produktinventar, klare Verantwortlichkeiten, Software- und Lieferkettentransparenz, gepflegte SBOMs, wiederholbare Risikobewertungen, dokumentierte Entscheidungen, Evidence Management und Prozesse zur laufenden Neubewertung.

Mit diesen Grundlagen können Unternehmen neue Leitlinien leichter aufnehmen, ohne ihr gesamtes Programm neu aufzubauen.

Die eigentliche Frage

Die wichtigste Frage für Hersteller und Softwareanbieter lautet daher nicht mehr nur: „Sind wir heute CRA-konform?“

Die bessere Frage lautet: „Haben wir ein System, das uns in der Lage hält, konform zu bleiben, wenn sich Produkte, Risiken und Anforderungen ändern?“

Diese Blogserie untersucht, was dafür in der Praxis nötig ist.

Folgen Sie der Serie, um die nächsten „Tales From the Trenches“ zu lesen und zu erfahren, welche Lektionen Unternehmen auf ihrem Weg zur CRA-Bereitschaft tatsächlich lernen.