CRA-SUPPORT: Prioritäten für CRA-Konformität systematisch ermitteln

Der Cyber Resilience Act kommt – und die Uhr tickt

2027 klingt noch weit weg. Ist es aber nicht – jedenfalls nicht, wenn man bedenkt, was bis dahin zu leisten ist. Der Cyber Resilience Act ist seit Dezember 2024 in Kraft, und die Übergangsfrist läuft: Ab September 2026 greifen erste Meldepflichten für aktiv ausgenutzte Schwachstellen, ab Dezember 2027 gelten die vollständigen Anforderungen für Hersteller und Händler von Produkten mit digitalen Elementen.

In meinen Beratungsgesprächen mit Schweizer Unternehmen – Softwareherstellern, Anbietern von Embedded Systems, aber auch mittelständischen IoT-Anbietern – erlebe ich immer wieder dasselbe Muster: Man hat den CRA im Radar, aber die eigentliche Auseinandersetzung mit dem konkreten Handlungsbedarf wurde aufgeschoben. Der Grund ist selten Gleichgültigkeit, sondern schiere Komplexität. Die Verordnung umfasst Anforderungen an Secure-by-Default-Konfigurationen, an Vulnerability Handling, an Konformitätsdokumentation und an den produktbegleitenden Support über einen Zeitraum von bis zu fünf Jahren. Das Lesen des Gesetzestexts ist dabei noch das Einfachste – das Ableiten des individuellen Handlungsbedarfs ist die eigentliche Herausforderung.

Genau hier setzt ein Tool an, das ich seit einiger Zeit in meiner Beratungspraxis einsetze und empfehle.

Was CRA-SUPPORT ist – und was es leistet

CRA-SUPPORT ist ein kostenloses Analyse-Tool, das EACG gemeinsam mit metaeffekt entwickelt hat. Es führt Unternehmen und Open-Source-Projekte durch einen strukturierten Fragebogen und mappt die Antworten systematisch auf die relevanten CRA-Anforderungen – insbesondere auf die Anhänge I und II der Verordnung.

Das Ergebnis ist kein generischer Compliance-Leitfaden, den man auch durch eine Stunde Lektüre der Verordnung selbst erhalten würde. Stattdessen entsteht ein individuelles Anforderungsprofil, das nach Reifegrad und Produktkategorie priorisiert ist. Wer das Tool durchläuft, erhält den ersten, belastbaren Schritt einer echten Gap-Analyse – mit konkretem Bezug zur eigenen Situation.

Was mich an dem Ansatz überzeugt: CRA-SUPPORT operiert nicht auf dem Niveau eines generischen Compliance-Checks, sondern denkt in Reifegrad-Dimensionen. Das ist der entscheidende Unterschied zwischen einer Checkliste und einer strukturierten Analyse.

Für wen das Tool relevant ist

Die offensichtliche Zielgruppe sind Hersteller von Softwareprodukten, Embedded Systems und vernetzten Geräten, die unter den Anwendungsbereich des CRA fallen. Das sind, vereinfacht gesagt, alle Produkte mit digitalen Elementen, die direkt oder indirekt mit einem Netzwerk verbunden werden können – eine Definition, die erheblich weiter reicht als viele zunächst annehmen.

Aber auch für Open-Source-Projekte und deren kommerzielle Stewards ist das Tool relevant. Der CRA enthält spezifische Regelungen für Open-Source-Software, und die Frage, ob ein Projekt als kommerziell einzustufen ist und damit unter die Herstellerpflichten fällt, ist alles andere als trivial. Wer hier zu spät mit der Analyse beginnt, riskiert Überraschungen.

Schliesslich richtet sich CRA-SUPPORT an Compliance- und Security-Verantwortliche, die intern eine fundierte Ersteinschätzung brauchen – bevor sie externe Beratung beauftragen. Ich erlebe es häufig, dass Unternehmen in ein Beratungsgespräch kommen, ohne eine gemeinsame Ausgangsbasis zu haben. CRA-SUPPORT ändert das: Man kommt vorbereitet.

Wie die Systematik hinter dem Tool funktioniert

Das Tool arbeitet mit einem Reifegrad-Modell. Die Fragen decken drei zentrale Dimensionen ab: erstens die Produktklassifizierung – also ob es sich um ein Standardprodukt oder ein kritisches Produkt der Klasse I oder II handelt – zweitens die bestehenden Sicherheitsprozesse im Entwicklungszyklus und drittens den Dokumentationsreifegrad.

Die Antworten werden auf die Anforderungen der Anhänge I und II des CRA gemappt. Anhang I definiert die wesentlichen Cybersicherheitsanforderungen – von der sicheren Konfiguration über Zugangskontrollen bis zur Verschlüsselung. Anhang II regelt die Informationspflichten gegenüber Nutzern. Aus dieser Zuordnung entsteht ein priorisierter Massnahmenkatalog, keine undifferenzierte Checkliste.

Der methodische Ansatz orientiert sich an etablierten Frameworks wie IEC 62443 für industrielle Automatisierungssysteme und dem SSDF (Secure Software Development Framework) des NIST. Das macht die Ergebnisse auch für Teams anschlussfähig, die bereits mit diesen Frameworks arbeiten – und ermöglicht eine regulatorische Einordnung auch ohne tiefes CRA-Vorwissen.

Typische Erkenntnisse aus der Analyse

Was lernen Unternehmen konkret, wenn sie CRA-SUPPORT durchlaufen? In meiner Erfahrung gibt es drei wiederkehrende Erkenntnismuster.

Erstens: Bestehende SDL-Prozesse (Secure Development Lifecycle) decken oft mehr CRA-Anforderungen ab als gedacht. Wer bereits strukturiertes Threat Modelling betreibt, Dependency-Scans in die CI/CD-Pipeline integriert hat und einen definierten Vulnerability-Disclosure-Prozess führt, hat relevante Vorarbeit geleistet. Das Tool macht sichtbar, wo man bereits steht – und wo die tatsächlichen Lücken sind.

Zweitens: Die Anforderungen an die Konformitätsdokumentation werden systematisch unterschätzt. Der CRA verlangt nicht nur technische Massnahmen, sondern auch deren nachvollziehbare Dokumentation – inklusive der Risikoanalyse und der Begründung für getroffene Sicherheitsentscheidungen. Viele Unternehmen haben die Praxis, aber nicht die Dokumentation.

Drittens: Die Pflichten rund um den Support-Zeitraum kommen oft überraschend. Der CRA schreibt vor, dass Hersteller Sicherheitsupdates für den gesamten Lebenszyklus eines Produkts bereitstellen müssen – mindestens jedoch für fünf Jahre. Das hat direkte Auswirkungen auf Produkt-Roadmaps, Lizenzmodelle und die Frage, wann ein Produkt als "End of Life" deklariert werden kann.

Für Open-Source-Projekte ergibt sich häufig eine spezifische Erkenntnis: Das Tool hilft einzuordnen, ob das Projekt aufgrund kommerzieller Aktivitäten – etwa durch bezahlten Support oder Integration in kommerzielle Produkte – als Wirtschaftsakteur im Sinne des CRA gilt. Das ist keine akademische Frage, sondern hat konkrete rechtliche Konsequenzen.

CRA-SUPPORT im Beratungskontext einsetzen

Ich setze CRA-SUPPORT als strukturierten Einstieg vor tiefergehenden Beratungsmandaten ein – und zwar aus einem pragmatischen Grund: Es schafft eine gemeinsame Sprache. Wenn ein Unternehmen mit den Ergebnissen des Tools in ein Beratungsgespräch kommt, haben wir sofort einen Ausgangspunkt. Wir diskutieren nicht abstrakt über den CRA, sondern konkret über das individuelle Anforderungsprofil des Unternehmens.

Die Ergebnisse lassen sich direkt in eine Roadmap überführen. Auf der einen Seite stehen Quick Wins: etwa das Formalisieren eines CVE-Prozesses, das Nachziehen der technischen Dokumentation oder das Implementieren eines Vulnerability-Disclosure-Policies. Auf der anderen Seite stehen strategische Massnahmen wie die Vorbereitung einer Konformitätsbewertung nach Annex VIII – die für kritische Produkte der Klasse II verpflichtend ist – oder der Aufbau eines strukturierten SBOM-Prozesses (Software Bill of Materials).

Unternehmen, die jetzt mit CRA-SUPPORT beginnen, verschaffen sich einen messbaren Vorsprung. Nicht weil 2027 morgen ist, sondern weil der Aufbau nachweisbarer Compliance Zeit braucht – und weil die frühe Analyse Fehlinvestitionen verhindert.

Fazit & nächste Schritte

Der CRA ist komplex – aber er ist kein unüberwindbares Hindernis für Unternehmen, die strukturiert vorgehen. Das Problem ist nicht die Regulierung selbst, sondern der Einstieg: Wo fange ich an? Was ist für mein Produkt relevant? Was kann ich auf bestehenden Prozessen aufbauen?

CRA-SUPPORT beantwortet genau diese Fragen – kostenlos, in kurzer Zeit und mit einem Ergebnis, das als Grundlage für interne Priorisierungen und externe Beratungsgespräche unmittelbar nutzbar ist.

Meine Empfehlung ist klar: Nutzen Sie das Tool jetzt, nicht in sechs Monaten. Der CRA-Reifegrad Ihres Unternehmens ist eine Information, die Sie haben sollten – bevor andere (etwa Kunden, Auditoren oder Behörden) anfangen, ihn einzufordern.

CRA-SUPPORT jetzt kostenlos starten – oder EACG direkt kontaktieren, wenn Sie eine begleitete Analyse mit strukturierter Roadmap-Entwicklung bevorzugen.

Zur Person

Berät Schweizer Unternehmen zu DevSecOps und EU-Regulierungs-Mapping. Kooperationspartner von EACG.

Kooperationsbeitrag. Tobias Reinhardt ist Kooperationspartner von EACG.