Cyber Resilience Act (CRA) 2026–2027: Was wir bereits wissen, was noch fehlt und wie Sie Ihr Produkt praktisch vorbereiten können – bevor harmonisierte Normen veröffentlicht werden

Was wir heute sicher wissen (und warum das kein „Thema für 2027“ ist)

Der Cyber Resilience Act kann wie ein weiteres „Papier aus Brüssel“ wirken, das man erst einmal auf später schieben kann. Das ist eine natürliche Reaktion – besonders, wenn ein Unternehmen im Projekttakt arbeitet: Prototyp, Inbetriebnahme, Serienproduktion, Service. Regulierung kommt oft als „Anforderung zum Schluss“ daher – etwas, das man kurz vor dem Zielstrich noch erledigt. Der CRA dreht diese Logik um, weil er sich nicht nur darauf bezieht, was am Tag des Verkaufs am Produkt sichtbar ist. Es geht darum, ob der Hersteller die Sicherheit des Produkts über die Zeit aufrechterhalten kann – und nachweisen kann, dass er das bewusst getan hat und nicht zufällig.

Die wichtigste Tatsache ist einfach, hat aber strategische Konsequenzen: Der CRA ist eine Produktregulierung, eingebettet in die Mechanik des EU-Marktes (einschließlich der CE-Kennzeichnung). Die Europäische Kommission beschreibt ausdrücklich, dass Produkte das CE-Zeichen als Signal der Konformität mit dem CRA tragen sollen, und dass die Durchsetzung bei den Marktüberwachungsbehörden liegt. Das ist also kein „IT-Standard“, den man als internes Verbesserungsprogramm behandeln kann. Es ist ein Rahmen, der die Verkaufsfähigkeit beeinflusst.

Daten, die den Blick schärfen

Schon im Text der Verordnung (EU) 2024/2847 ist eine stufenweise Anwendung erkennbar. Der CRA gilt ab dem 11. Dezember 2027, jedoch mit klaren Ausnahmen. Artikel 14 (Meldungen) gilt ab dem 11. September 2026, und das Kapitel zur Notifizierung von Konformitätsbewertungsstellen (Chapter IV) ab dem 11. Juni 2026. Diese drei Daten sollte man als „Meilensteine“ verstehen, weil sie drei unterschiedliche Arten von Bereitschaft abbilden: operativ, institutionell und produktbezogen.

Die Kommission kommuniziert es noch einfacher: Der CRA ist am 10. Dezember 2024 in Kraft getreten, die wesentlichen Pflichten gelten ab dem 11. Dezember 2027, und die Meldepflichten ab dem 11. September 2026. Wenn im Unternehmen jemand sagt „wir haben Zeit bis 2027“, meint er meist die Konstruktionsanforderungen und die Konformitätsbewertung. Die Meldungen kommen jedoch früher – und betreffen Ereignisse, die nicht auf den Projektplan warten.

Meldungen: eine Pflicht, die einen Prozess erzwingt (nicht ein Dokument)

Die Meldepflicht ist ein guter Lackmustest, weil sie zeigt, wie der CRA „Cybersicherheit von Produkten“ versteht. Das ist keine Absichtserklärung und keine „Policy“. Es ist ein Prozess, der unter Stress funktionieren muss: wenn eine aktiv ausgenutzte Schwachstelle auftaucht oder ein schwerwiegender Vorfall eintritt.

Die Kommission beschreibt das eindeutig: Der Hersteller muss aktiv ausgenutzte Schwachstellen sowie schwerwiegende Vorfälle melden, die die Sicherheit des Produkts beeinträchtigen. Gefordert ist ein „early warning“ innerhalb von 24 Stunden ab Kenntniserlangung, eine vollständige Meldung innerhalb von 72 Stunden sowie ein Abschlussbericht: bis zu 14 Tage nach Verfügbarkeit einer Abhilfemaßnahme bei aktiv ausgenutzten Schwachstellen und innerhalb eines Monats bei schwerwiegenden Vorfällen.

In der Praxis heißt das: Die Organisation braucht mehr als eine Checkliste. Sie braucht einen Mechanismus, der drei Fragen beantwortet: Woher erfahren wir, dass es ein Problem gibt; wer stuft ein, ob es bereits „aktiv ausgenutzt“ oder „schwerwiegend“ ist; und wie organisieren wir Informationsfluss und Korrekturmaßnahme in einem Zeitfenster, das keinen Raum für Improvisation lässt.

Wenn in Schulungen Chaos entsteht, liegt das oft daran, dass der CRA eine Lücke zwischen IT und Produkt trifft. Für die IT ist ein „Incident“ häufig ein Ereignis in der Infrastruktur. Für den Hersteller ist ein „Incident“ ein Ereignis, das das Produkt beim Kunden betrifft – Version, Konfiguration, Art der Implementierung. Der CRA zwingt dazu, diese Welten in einer gemeinsamen Verantwortung zusammenzuführen.

Was der CRA umfasst: das Produkt als Beziehung zum Netz, nicht als „Gerät auf dem Tisch“

In der Praxis haben wir bei Risikobeurteilungen von Maschinen gelernt, dass Risiko keine Eigenschaft der Maschine an sich ist – es entsteht in der Beziehung Mensch–Maschine. Beim CRA gibt es eine ähnliche Perspektivverschiebung: Sicherheit existiert nicht „im Gerät“, sondern in der Beziehung des Produkts zu seiner digitalen Umgebung, in der Art der Nutzung und in der Reaktionsfähigkeit des Herstellers.

Die Kommission weist in ihrer Zusammenfassung des CRA auf die Definition von „Produkten mit digitalen Elementen“ hin sowie darauf, dass die Meldepflichten alle solchen Produkte betreffen, die auf dem EU-Markt bereitgestellt werden – auch diejenigen, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Das ist eine entscheidende Präzisierung, weil sie einen verbreiteten Mythos ausräumt: „Für alte Produkte ist das irrelevant.“ Für die Meldungen gilt das nicht.

Was es noch nicht gibt (harmonisierte Normen) und warum das nicht lähmen sollte

W Gesprächen über CRA taucht immer wieder der Satz auf: „Es gibt noch keine harmonisierten Normen, also kann man nichts machen.“ Das klingt logisch, hat aber einen versteckten Haken. Harmonisierte Normen sind ein Werkzeug, das den Nachweis der Konformität erleichtert (Konformitätsvermutung), aber sie sind nicht der einzige Weg, um echte Produktsicherheit aufzubauen. Und sie sind auch keine Voraussetzung, um von Anfang an richtig zu konstruieren.

Die Kommission steuert das Thema Normen ausdrücklich über die Seite „CRA Standardisation“ und informiert darüber, dass sie die Standardisierungsanfrage M/606 angenommen hat, die ein Paket von 41 Normen zur Unterstützung von CRA umfasst — sowohl horizontale als auch vertikale (produktspezifische). Das ist wichtig, weil es zeigt, dass die EU das Marktproblem versteht: Ohne Normen werden Unternehmen Konformität jeweils auf ihre eigene Art herstellen, und die Marktüberwachung wird es schwerer haben.

Horizontale und vertikale Normen: was das für den Hersteller bedeutet

Vereinfacht gesagt:

• horizontale Normen sollen beschreiben, „wie“ Produktsicherheit unabhängig von der Kategorie aufgebaut und aufrechterhalten wird (Prozesse, Methoden, risikobasierter Ansatz),
• vertikale Normen sollen die Anforderungen für konkrete Produktklassen präzisieren (dort, wo Risiken und Architekturen typisch sind).

Diese Unterscheidung hat praktische Folgen. Wenn du ein Industrieprodukt entwickelst, bei dem ein Teil der Umgebung „OT“ ist und der Lebenszyklus lang ist, brauchst du Normen, die nicht für eine SaaS-Anwendung geschrieben sind. Genau deshalb sind vertikale Normen wichtig: Sie helfen, von allgemeinen Prinzipien herunterzubrechen auf das, was in realen Architekturen tatsächlich zu kontrollieren ist.

Zeitplan der Arbeiten: Normen kommen schrittweise, nicht „als Paket vor 2027“

Die Kommission zeigt in Materialien zur CRA-Implementierung, dass CRA schrittweise umgesetzt wird und Normen diesen Prozess über die Zeit unterstützen sollen. Auf der Ebene der Fakten, die heute sicher sind: Wir haben eine formal angenommene Verordnung und wir haben einen gestarteten Standardisierungsmechanismus (M/606).

Für die Praxis ist am wichtigsten, einen Satz zu verstehen: Selbst wenn eine Norm von Normungsorganisationen erarbeitet wird, entsteht die „Konformitätsvermutung“ im rechtlichen Sinn erst dann, wenn die Fundstelle der Norm als harmonisierte Norm im Amtsblatt der EU veröffentlicht wird. Das ist die Mechanik, die dem EU-Ansatz zur Harmonisierung allgemein zugrunde liegt: Normen sind die Brücke zwischen Recht und Ingenieurpraxis, aber diese Brücke muss von der EU formal „anerkannt“ werden.

Aus Herstellersicht bedeutet das, dass die Jahre 2026–2027 eine Phase sein werden, in der ein Teil der Unternehmen auf Basis eigener Methoden zum Konformitätsnachweis (risk-based + Nachweise) arbeitet, während andere bereits auf die entstehenden Normen abbilden. Und das ist normal.

„Keine Normen“ heißt nicht „keine Pflicht“ — es heißt: Nachweise werden wichtiger

Hier zeigt sich eine wesentliche Konsequenz: Wenn Normen fehlen, die den einfachsten Weg zum Konformitätsnachweis bieten, steigt die Bedeutung dessen, was in der Auditpraxis immer entscheidend ist: eine konsistente Entscheidungskette.

Welche Risiken haben wir bewertet? Welche Szenarien haben wir als realistisch angenommen? Wie haben wir Schutzmaßnahmen ausgewählt? Wie managen wir Schwachstellen? Wie lange unterstützen wir das Produkt? Wie informieren wir den Kunden? CRA verlangt nicht, dass der Hersteller „zukünftige EN-Normen errät“. Es verlangt, dass der Hersteller zeigen kann, dass seine Entscheidungen nicht zufällig waren, sondern risikobasiert und nach dem Stand der Technik getroffen wurden.

Wie man ein Produkt realistisch auf CRA vorbereitet (Roadmap für Hersteller und Integrator)

Der größte Wert von CRA liegt darin, dass es Reife erzwingt: Cybersicherheit ist nicht länger ein Add-on zum Produkt, sondern wird zu einer Produkteigenschaft. Nur entsteht Reife nicht durch Erklärungen. Sie entsteht durch einen Prozess, der präzise genug ist, um in der Praxis zu funktionieren, und zugleich so einfach, dass die Engineering-Organisation nicht beginnt, ihn zu umgehen.

Bei der Risikobeurteilung von Maschinen entstehen die besten Konstruktionsentscheidungen dann, wenn wir aufhören zu fragen „welche Gefährdungen hat die Maschine“, und anfangen zu fragen „bei welchen Aufgaben und in welchen Zuständen ist der Mensch exponiert“. Bei CRA ist es analog: Wir hören auf zu fragen „welche Schwachstellen hat das Produkt“, und beginnen zu fragen „unter welchen Bedingungen wird das Produkt angreifbar und was kann der Hersteller dann tun“. Diese Verschiebung bringt Struktur in die Arbeit.

Schritt 1: Definiere das Produkt als System (nicht als Gerät)

Beginne damit zu definieren, was in deinem Fall ein „Produkt mit digitalen Elementen“ ist. Nicht nur Hardware und Firmware, sondern auch das, was oft weggelassen wird, weil es nicht in die Schachtel passt: Komponenten, Bibliotheken, Update-Mechanismen, Services, ohne die das Produkt seine Funktion nicht erfüllt. Im CRA ist das wichtig, weil sich die Verantwortung des Herstellers auf das bezieht, was als Produkt auf den Markt kommt — und nicht nur auf das, was die Mechanikabteilung gefertigt hat.

Das ist auch der erste Punkt, an dem Integratoren ehrlich zu sich selbst sein sollten: Wenn du Komponenten integrierst und sie so konfigurierst, dass beim Kunden ein „Endprodukt“ entsteht, dann bist du nicht nur „Implementierer“. Du bist Mitgestalter des Risikos und Mitgestalter der Verantwortung.

Schritt 2: Führe die CRA-Risikobewertung so durch, dass sie ein Entscheidungswerkzeug ist

Nie geht es um eine „Matrix“ auf Folien. Es geht um eine Risikobewertung, die zu Konstruktionsentscheidungen führt und reproduzierbar ist.

In der Praxis beginnt ein guter Ansatz für CRA mit einer einfachen Frage: Welche realen Missbrauchsszenarien gibt es in der Umgebung des Kunden – und nicht nur im Labor? Wer hat Servicezugang? Wie ist das Netzwerk aufgebaut? Wie oft aktualisieren wir? Welche Folgen hat ein Stillstand? In der Industrie sind diese Fragen unbequemer als in der IT, weil die Antworten oft lauten: „Wir können nicht jede Woche aktualisieren“ oder „Wir haben keine Telemetrie“. Und genau deshalb muss man sie stellen. CRA ist Recht – aber seine Auswirkungen sind konstruktiver Natur.

Schritt 3: Etabliere „vulnerability handling“ als Produktionsprozess, nicht als Krisenreaktion

Die von der Kommission beschriebenen Meldefristen (24h/72h/14 Tage/Monat) sind gnadenlos für eine Organisation ohne Prozess. Wenn du zum 11. September 2026 bereit sein willst, musst du „vulnerability handling“ als Bestandteil des Produktlebenszyklus behandeln – und nicht als „Aufgabe des Security-Teams“.

Das bedeutet:

• einen zentralen Kanal für eingehende Meldungen (CVD policy + Kontakt),
• eine Triage, die einen Verantwortlichen und Kriterien hat,
• einen Mechanismus zum Erstellen und Ausliefern von Security-Updates,
• ein Kommunikationsmodell für Kunden, das nicht aus Improvisation besteht,
• Bereitschaft zur Meldung (wer meldet, mit welchen Daten, wie schnell).

Das klingt alles nach „organisatorischer“ Arbeit. In der Praxis ist es Produktarbeit, weil es Versionen, Kompatibilität, Update-Architektur und Supportstrategie betrifft.

Schritt 4: Lege den Supportzeitraum als Business-Entscheidung fest, nicht als Mindestanforderung

Wenn deine Produkte in der Industrie 10–15 Jahre im Einsatz sind, ist der Supportzeitraum strategisch. CRA erzwingt, dass Support keine ungedeckte Zusage ist. Das heißt: Der Supportzeitraum sollte aus einer Analyse abgeleitet werden – wie lange das Produkt genutzt wird, wie die Lieferkette der Komponenten aussieht und wie lange du in der Lage sein wirst, Patches bereitzustellen. In der Praxis beginnt der Supportzeitraum, das gesamte Ökosystem „mitzuziehen“: Verträge mit Lieferanten, Verfügbarkeit der Build-Umgebung, Pflege der Toolchains und sogar Entscheidungen darüber, ob das Produkt Remote-Funktionen hat oder isoliert ist.

Wenn du den Supportzeitraum als Formalität behandelst, gerätst du spätestens 2027 in einen Konflikt: Der Kunde erwartet Support, aber dir fehlen bereits Ressourcen und Abhängigkeiten, um ihn zu liefern. CRA schafft dieses Problem nicht – CRA macht es nur sichtbar.

Schritt 5: Ordne die Lieferkette: Das Gespräch mit Lieferanten ist Teil der Konformität

Im CRA gibt es keine „Magie“, die externe Komponenten automatisch sicher macht. Wenn dein Gerät auf Bibliotheken, Kommunikationsmodulen, Betriebssystem, SDK oder Hardwarekomponenten basiert, hängt dein Risiko direkt von der Qualität der Praktiken des Lieferanten ab.

Deshalb lohnt es sich, schon jetzt Gespräche über Dinge zu führen, die nicht nach Marketing klingen, sondern nach Engineering:

• ob der Lieferant Schwachstellen auf vorhersehbare Weise kommunizieren kann,
• welche Reaktionszeit er hat,
• ob er einen Prozess zur Veröffentlichung von Patches hat,
• ob er die Komponente über einen Zeitraum pflegen kann, der zu deinem Supportzeitraum passt.

Hier berührt CRA das Geschäft ganz konkret: Ein Lieferant, der Schwachstellen nicht handhaben kann, ist nicht „günstiger“. Er ist ein regulatorisches Risiko.

Schritt 6: Baue die Dokumentation als konsistente Spur auf: Recht → Risiko → Entscheidung → Nachweis

In Konformitätsaudits gewinnt immer die Konsistenz. Wenn aus der Risikobewertung hervorgeht, dass eine bestimmte Schnittstelle kritisch ist, die Dokumentation aber nicht beschreibt, wie du sie absicherst; wenn du erklärst, dass Updates sicher sind, aber nicht zeigen kannst, wie du die Integrität der Pakete sicherstellst; wenn du sagst, dass du einen Prozess zur Schwachstellenbehandlung hast, aber nicht zeigen kannst, wie du Meldungen triagierst – dann ist das kein „fehlendes Papier“. Das ist fehlender Nachweis, dass der Prozess funktioniert.

Im CRA ist diese Spur besonders wichtig, solange harmonisierte Normen fehlen. Denn sie wird die Grundlage für das Gespräch mit der Marktüberwachungsbehörde, dem Enterprise-Kunden und in einigen Produktkategorien auch mit der Konformitätsbewertungsstelle sein. Und ebenso wichtig: Sie ist die Basis für interne Stabilität. Das Team weiß, warum wir etwas tun – und nicht nur „dass wir müssen“.

Fazit: CRA als neue Konstruktionsanforderung, nicht als „Compliance-Projekt“

Wenn ich einen Gedanken mitgeben müsste, der alle drei Teile zusammenbindet: CRA ist kein Problem, das man am Ende löst. Es ist ein Rahmen, der die Art verändert, wie man über das Produkt nachdenkt. So wie ISO 12100 lehrt, dass Risiko in der Beziehung Mensch–Maschine entsteht, so lehrt CRA, dass Cybersicherheit in der Beziehung Produkt–Umgebung–Lebenszyklus des Herstellers entsteht.

Harmonisierte Normen werden kommen und bestimmte Wege vereinfachen. Aber ihr Fehlen ist kein Grund für Stillstand. Es ist ein Grund, sich auf das zu konzentrieren, was CRA immer bewertet: Entscheidungen, Nachweise und die Fähigkeit, in der Realität zu handeln – nicht in der Präsentation.