CRA Fahrplan 2026/2027: So bereiten Sie Ihr Unternehmen strukturiert vor

Ein brauchbarer CRA-Fahrplan trennt die kurzfristige Meldebereitschaft 2026 von der vollständigen Produkt-Compliance bis Dezember 2027. Dadurch entsteht kein hektisches Mammutprojekt, sondern eine Reihenfolge: Scope klären, Meldeprozess sichern, Produkte priorisieren, Sicherheitsanforderungen in Entwicklung und Dokumentation verankern und anschließend den passenden Konformitätsweg abschließen.

Was muss beim CRA zuerst passieren?

Zuerst muss klar sein, welche Produkte und Unternehmensrollen überhaupt betroffen sind. Ohne diese Scope-Entscheidung lässt sich weder ein realistischer Aufwand schätzen noch sinnvoll priorisieren. Der häufigste Planungsfehler besteht darin, mit Checklisten für technische Anforderungen zu beginnen, obwohl noch nicht feststeht, welche Produktversionen, Komponenten und Rollen betrachtet werden müssen.

1. Produktinventar aufbauen: Produkte, Versionen, Varianten und Verantwortliche erfassen.
2. Rolle je Produkt bestimmen: Hersteller, Importeur, Händler oder mehrere Rollen.
3. Anwendungsbereich dokumentieren: Warum ist ein Produkt erfasst, ausgenommen oder noch zu prüfen?

Phase 1: Bis 11. September 2026 meldefähig werden

Die erste harte operative Frist ist der 11. September 2026. Ab dann gelten die Berichtspflichten nach Artikel 14 für Hersteller. Unternehmen brauchen keinen perfekten Gesamtprozess, aber einen belastbaren Weg für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.

Wer entscheidet über eine mögliche Meldung?

Benennen Sie eine verantwortliche Stelle und eine Vertretung. In einem kleinen Betrieb kann das die technische Leitung gemeinsam mit der Geschäftsführung sein. Entscheidend ist, dass Meldungen nicht erst intern nach einem Ansprechpartner suchen müssen.

Welche 24-/72-Stunden-Daten müssen griffbereit sein?

Produkt, Version, bekannte Auswirkung, betroffene Märkte, Art des Problems, laufende Gegenmaßnahmen und technische Kontaktperson sollten kurzfristig verfügbar sein. Bei der frühen Meldung muss noch nicht jedes technische Detail abschließend feststehen. Der Prozess muss aber Informationen schnell sammeln und aktualisieren können.

Phase 2: Bis Ende 2026 Produkte und Risiken priorisieren

Nach der Meldebereitschaft sollte das Unternehmen alle betroffenen Produktfamilien nach Risiko, Umsatzrelevanz, Entwicklungsstatus und geplanter Marktbereitstellung ordnen. Ein Produkt, das 2027 eingestellt wird, braucht eine andere Priorität als die nächste Hauptversion, die 2028 noch aktiv verkauft werden soll.

Welche Priorisierung ist sinnvoll?

Phase 3: Sicherheitsanforderungen in die Entwicklung einbauen

Der CRA sollte nicht als zusätzliche Schicht nach der Entwicklung entstehen. Die grundlegenden Cybersicherheitsanforderungen gehören in Produktanforderungen, Architekturentscheidungen, Entwicklungsrichtlinien, Tests und Release-Freigaben. So entstehen Nachweise während der normalen Arbeit.

Welche Entwicklungsfragen gehören in den CRA-Prozess?

• Welche Sicherheitsrisiken ergeben sich aus der vorgesehenen und vorhersehbaren Nutzung?
• Welche Schnittstellen, Konten, Berechtigungen und Kommunikationswege existieren?
• Welche externen Softwarekomponenten und Abhängigkeiten werden eingesetzt?
• Wie werden Sicherheitsupdates verteilt und verifiziert?
• Wie werden Schwachstellen entgegengenommen, bewertet und behoben?
• Welche Sicherheitsfunktionen und sicheren Standardkonfigurationen braucht das Produkt?
• Wie lange wird das Produkt unterstützt und wie wird dieser Zeitraum begründet?

Phase 4: Komponenten und Schwachstellen beherrschbar machen

Eine aktuelle Übersicht über Softwarekomponenten erleichtert die Reaktion auf neue CVEs und andere Schwachstellen. Wer nach jeder Sicherheitsmeldung erst manuell herausfinden muss, welche Bibliotheken in welcher Version verbaut sind, verliert Zeit und erhöht das Risiko falscher Entscheidungen.

Das BSI weist in seiner CRA-Orientierung auf die Bedeutung einer SBOM hin. Für Unternehmen sollte die Komponentenliste so in Build- und Releaseprozesse integriert werden, dass sie nicht nach jeder Version veraltet.

Was gehört zusätzlich in den Vulnerability-Prozess?

Ein Eingangskanal für externe Meldungen, definierte Bewertungskriterien, technische Verantwortliche, Patch-Entscheidung, Releaseweg, Nutzerkommunikation und Dokumentation. Der Prozess sollte auch klären, wann aus einer Schwachstelle ein möglicher Artikel-14-Fall wird.

Phase 5: Produktkategorie und Konformitätsweg klären

Nicht jedes Produkt durchläuft denselben Konformitätsweg. Der CRA unterscheidet unter anderem allgemeine, wichtige und kritische Produkte. Die Einordnung wirkt sich darauf aus, welche Bewertungsverfahren zulässig sind und ob eine unabhängige Stelle einbezogen werden muss.

Diese Entscheidung sollte rechtzeitig erfolgen, weil externe Prüfkapazitäten, technische Nachweise und gegebenenfalls Normen die Projektplanung beeinflussen können. Für neue Produkte gehört die Kategorie deshalb in die Produktfreigabe, nicht erst in die letzte Woche vor Markteinführung.

Phase 6: Technische Dokumentation versionsbezogen aufbauen

Gute CRA-Dokumentation ist nachvollziehbar, aber nicht unnötig doppelt. Architekturunterlagen, Risikobewertung, Sicherheitsanforderungen, Testergebnisse, Komponenteninformationen, Releaseentscheidungen und Nutzerhinweise sollten einer konkreten Produktversion zugeordnet sein. Änderungen müssen erkennen lassen, welche Sicherheitsauswirkung geprüft wurde.

Welche Nachweise sollten zusammengeführt werden?

• Beschreibung und bestimmungsgemäße Nutzung des Produkts
• Cybersicherheits-Risikobewertung und relevante Entscheidungen
• Architektur- und Schnittstelleninformationen
• Nachweise zu Sicherheitsanforderungen und Tests
• Schwachstellen- und Updateprozess
• Komponentenübersicht / SBOM
• Supportzeitraum und Nutzerinformationen
• Konformitätsbewertung und EU-Konformitätserklärung, soweit erforderlich

Phase 7: 2027 einen internen CRA-Probelauf durchführen

Bevor das erste Produkt unter vollständiger CRA-Anwendung freigegeben wird, sollte ein internes Audit oder ein strukturierter Probelauf stattfinden. Dabei wird nicht nur geprüft, ob Dokumente existieren, sondern ob Produkt, technische Realität und Unterlagen zusammenpassen.

Welche Fragen sollte der Probelauf beantworten?

• Ist die Unternehmensrolle je Produkt eindeutig?
• Ist die Produktkategorie nachvollziehbar begründet?
• Deckt die Risikobewertung die reale Architektur ab?
• Sind Schwachstellen- und Updateprozesse tatsächlich nutzbar?
• Ist die Komponentenliste aktuell?
• Sind Sicherheitsinformationen für Nutzer vollständig?
• Ist der geplante Konformitätsweg korrekt?
• Kann ein Vorfall intern innerhalb weniger Stunden eskaliert werden?

Phase 8: Ab 11. Dezember 2027 nur CRA-konforme neue Produkte bereitstellen

Ab 11. Dezember 2027 gelten die wesentlichen CRA-Anforderungen vollständig. Produkte, die ab dann neu auf dem Unionsmarkt bereitgestellt werden, müssen die einschlägigen Anforderungen erfüllen. Bei bereits zuvor in Verkehr gebrachten Produkten sind die Übergangsregeln und insbesondere die Frage wesentlicher Änderungen zu beachten.

Der Projektplan sollte deshalb für jede Produktfamilie festhalten, welche Version nach Dezember 2027 weiter vertrieben wird, ob vorher noch eine größere Änderung geplant ist und welche Nachweise für die Markteinführung erforderlich sind.

Wie sieht ein realistischer 12-Monats-Arbeitsplan aus?

Was sollte die Geschäftsführung monatlich sehen?

Ein kleines CRA-Dashboard reicht. Sinnvolle Kennzahlen sind: Anzahl der Produkte mit geklärtem Scope, Anzahl offener Hochrisiko-Lücken, Produkte mit aktueller Risikobewertung, Produkte mit gepflegter Komponentenliste, Stand des Meldeprozesses, geklärter Konformitätsweg und offene Entscheidungen vor der nächsten Marktfreigabe. Mehr Kennzahlen helfen nur, wenn daraus konkrete Entscheidungen folgen.

Wenn der Scope noch nicht geklärt ist, starten Sie beim CRA-Check. Für eine Organisation mit wenig Personal zeigt CRA für KMU, wie sich die Aufgaben schlank verteilen lassen.

Welche Quelle ist für Fristen und Meldungen maßgeblich?

Die Verordnung (EU) 2024/2847 enthält die verbindlichen Vorgaben. Artikel 14 regelt die Meldepflichten; Artikel 71 enthält die Anwendungsdaten. Die EU-Kommission veröffentlicht ergänzend aktuelle Umsetzungsinformationen zur zentralen Meldeplattform und zu Leitlinien.

Cyber Resilience Act auf EUR-Lex