Cyber Resilience Act ab September 2026: Welche 5 Betriebsaufgaben IT- und Service-Teams jetzt verbindlich organisieren sollten

Der Cyber Resilience Act, kurz CRA, ist für viele IT-Organisationen noch immer ein Thema, das vor allem in Produktentwicklung, Compliance oder Rechtsabteilung verortet wird. Das greift zu kurz. Die EU-Kommission macht in ihren Umsetzungsunterlagen inzwischen sehr deutlich, dass der CRA den gesamten Lebenszyklus digitaler Produkte adressiert, also Planung, Entwicklung, Auslieferung, Wartung, Schwachstellenbehandlung und Meldeprozesse. Spätestens mit den Reporting-Pflichten ab dem 11. September 2026 wird daraus kein fernes Regulierungsthema mehr, sondern eine operative Aufgabe.

Wichtig ist dabei die saubere Einordnung: Rechtlich adressiert der CRA vor allem Hersteller von Produkten mit digitalen Elementen. Operativ betroffen sind aber deutlich mehr Teams. Denn in der Praxis hängen Produktsicherheit, Supportzeiträume, Patch-Auslieferung, Incident-Kommunikation und technische Nachweise selten an einer einzigen Stelle. Wer Software vertreibt, Appliances betreibt, OEM-Komponenten integriert, White-Label-Lösungen anbietet oder digitale Services eng mit einem Produkt koppelt, braucht dafür belastbare Betriebsabläufe. Genau hier treffen Regulierung und IT Service Management direkt aufeinander.

Die offiziellen EU-Seiten zum CRA sowie die ENISA-Informationen zur Single Reporting Platform liefern bereits genug Substanz, um 2026 konkrete Hausaufgaben abzuleiten. Für IT-Leitungen, Service Owner, Product Operations, Support und Security-Verantwortliche sind vor allem diese fünf Betriebsaufgaben jetzt entscheidend.

1. Zuerst klären, welche Produkte und Komponenten überhaupt in den CRA-Scope fallen

Der häufigste Fehler wird nicht bei der Meldung passieren, sondern viel früher, beim Geltungsbereich. Die Kommission beschreibt den CRA ausdrücklich für Produkte mit digitalen Elementen, also nicht nur für klassische Endgeräte, sondern auch für Software, Komponenten, Betriebssysteme und andere digitale Bausteine in der Lieferkette. Genau deshalb reicht es nicht, nur auf das eigene Hauptprodukt zu schauen. Viele Organisationen müssen erst einmal sichtbar machen, welche verkauften oder bereitgestellten Leistungen überhaupt als betroffenes Produkt, integrierte Komponente oder unterstützender Service gelten.

Praktisch heißt das: Ein sauberes CRA-Inventar wird zur Pflichtaufgabe. Darin sollten mindestens Produktname, Version, verantwortliches Team, zentrale Drittkomponenten, Auslieferungskanal, Supportstatus und Marktbezug dokumentiert sein. Besonders wichtig ist die Verbindung zwischen Produktkatalog und Betriebsrealität. Wenn Service Desk, Asset Management, Produktteam und Security mit unterschiedlichen Listen arbeiten, fehlt später genau die Zuordnung, die bei Schwachstellen, Rückfragen oder Audits gebraucht wird.

Für ITSM-nahe Organisationen ist das kein neues Denken, sondern ein bekanntes Muster: Ohne belastbare Configuration Items, Servicezuordnung und Ownership scheitern auch Incident-, Change- und Problem-Prozesse. Der CRA macht diese Disziplin jetzt aber regulatorisch relevanter.

2. Supportzeitraum, Schwachstellen-Ownership und Patch-Fähigkeit verbindlich festlegen

Die Hersteller-Seite der EU-Kommission betont drei operative Punkte besonders klar: Produkte müssen sicher gestaltet werden, Hersteller müssen eine Risikobewertung durchführen, und sie müssen ihre Produkte für den angegebenen Supportzeitraum betreuen. Genau hier steckt für viele Organisationen mehr Arbeit als bei der späteren Formalmeldung. Denn ein kommunizierter Supportzeitraum ist nur dann belastbar, wenn intern auch geregelt ist, wer Schwachstellen entgegennimmt, bewertet, priorisiert, entwickelt, testet und ausrollt.

Viele Teams haben heute zwar ein Security- oder PSIRT-Postfach, aber keinen wirklich durchgängigen Ablauf vom Hinweis bis zur korrigierten Version. Typische Brüche liegen zwischen Entwicklung und Betrieb, zwischen Produktteam und Support oder zwischen Hersteller und Zulieferer. Für 2026 sollte deshalb jedes relevante Produkt einen dokumentierten Vulnerability-Owner, einen Patch- und Release-Pfad sowie definierte Eskalationsstufen bekommen.

Besonders wertvoll ist hier die Kombination aus klassischem Service Management und Product Security: Change Enablement sorgt für kontrollierte Freigaben, Release Management für planbare Auslieferung und Incident Management für den Störfall. Wenn diese Disziplinen nicht zusammenspielen, werden Supportzeiträume schnell zu Marketingversprechen ohne operative Deckung.

3. Meldepflichten nicht als Security-Sonderweg behandeln, sondern in Incident- und Major-Incident-Prozesse integrieren

Ab dem 11. September 2026 gelten die CRA-Reporting-Pflichten. Laut Kommission und ENISA müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle über die Single Reporting Platform melden. Die Taktung ist eng: Frühwarnung innerhalb von 24 Stunden nach Kenntnis, weitergehende Meldung innerhalb von 72 Stunden, dazu ein Abschlussbericht innerhalb von 14 Tagen nach verfügbarer Korrekturmaßnahme bei Schwachstellen beziehungsweise innerhalb eines Monats bei schweren Incidents.

Diese Fristen sind für viele Organisationen nicht mit improvisierten Mailketten beherrschbar. Wer sauber arbeiten will, muss jetzt festlegen, wann ein technischer Befund vom Security-Event zum CRA-relevanten Fall wird, wer die regulatorische Bewertung vornimmt, welche Datenfelder im Incident-Ticket zwingend vorhanden sein müssen und wer die Freigabe für externe Meldungen erteilt. Ebenso wichtig ist die Verzahnung mit Kommunikationsprozessen, weil technische Analyse, Kundeninformation, Patch-Status und Behördenmeldung zeitlich auseinanderlaufen können.

Ein praxistauglicher Ansatz ist, CRA-relevante Fälle im Major-Incident- oder Product-Security-Prozess mit eigener Kennzeichnung zu führen. Dann lassen sich Fristen, Verantwortlichkeiten und Nachweise systematisch überwachen, statt sie im normalen Ticketstrom zu verlieren. Für Service-Organisationen ist das die eigentliche Reifeprüfung: Nicht die Meldemaske wird schwierig, sondern die Fähigkeit, in kurzer Zeit konsistente und belastbare Informationen bereitzustellen.

4. Technische Dokumentation und Konformitätsnachweise an den Release-Prozess anbinden

Vor dem Inverkehrbringen verlangt der CRA laut Hersteller-Leitseite unter anderem Risikobewertung, technische Dokumentation und ein Konformitätsbewertungsverfahren. Viele Unternehmen behandeln solche Nachweise noch als Projektarbeit kurz vor einem Release. Das wird auf Dauer nicht tragen. Sobald Produktlinien häufiger releasen, Varianten pflegen oder mehrere Komponenten von Zulieferern übernehmen, müssen Nachweise in den normalen Delivery-Prozess hinein.

Für IT- und Plattformteams bedeutet das ganz konkret: Sicherheitsanforderungen, Architekturentscheidungen, eingesetzte Kryptografie, Update-Mechanismen, bekannte Abhängigkeiten und Supportzusagen dürfen nicht nur in Präsentationen oder Einzelordnern liegen. Sie müssen versioniert, releasebezogen auffindbar und in der Betriebsdokumentation anschlussfähig sein. Sonst fehlt bei Rückfragen zwar nicht die Information an sich, aber der belastbare Nachweis, welche Aussage zu welcher Version gehörte.

Hier lohnt sich ein nüchterner Governance-Schritt: Jedes produktive Release sollte eine minimale CRA-Dokumentationsspur hinterlassen. Dazu gehören etwa Risikobewertung-Referenz, Software Bill of Materials oder Komponentenübersicht, Freigabestatus, Supportfenster und Kontaktweg für Vulnerability Disclosure. Das klingt trocken, spart im Ernstfall aber enorm viel Zeit.

5. Zulieferer, Open-Source-Bausteine und Betriebsrollen früh in ein gemeinsames Modell ziehen

Der CRA wird oft so gelesen, als sei er nur eine Herstellerpflicht am Rand des Betriebs. Tatsächlich zeigt schon die Umsetzungsseite der Kommission, dass die gesamte Lieferkette und auch Open-Source-Konstellationen in der Praxis mitgedacht werden müssen. Für viele IT-Organisationen ist deshalb nicht die Einzelfrage „Sind wir Hersteller?“ die wichtigste, sondern: Welche externen Komponenten und Partner beeinflussen unsere Fähigkeit, Sicherheitsanforderungen einzuhalten, Schwachstellen zu beheben und Fristen einzuhalten?

Gerade Service- und Betriebsorganisationen sollten deshalb kein getrenntes CRA-Projekt neben dem Lieferantenmanagement laufen lassen. Sinnvoller ist ein gemeinsames Modell aus Supplier Management, Product Security und Betrieb. Darin wird für kritische Komponenten festgehalten, wer Sicherheitsinformationen liefert, wie schnell Patches erwartet werden, wie ein Upstream-Issue intern eskaliert und ab wann ein Kundenfall regulatorische Relevanz bekommen könnte.

Das ist auch deshalb wichtig, weil die knappen Meldefristen wenig Raum für Verantwortungsdebatten lassen. Wenn im Vorfall erst geklärt werden muss, ob das Plattformteam, der OEM-Lieferant, der Managed-Service-Partner oder das Produktmanagement zuständig ist, ist wertvolle Zeit verloren. Gute CRA-Vorbereitung ist deshalb vor allem Rollenklärung.

Fazit

Der Cyber Resilience Act ist 2026 kein Thema mehr, das man mit einem späten Compliance-Projekt abräumen kann. Die Reporting-Pflichten ab September 2026 und die volle Anwendung ab Dezember 2027 machen deutlich, dass Produktsicherheit im EU-Markt dauerhaft als Betriebsaufgabe organisiert werden muss. Für IT- und Service-Teams bedeutet das: Scope sauber definieren, Support und Schwachstellenbearbeitung verbindlich regeln, Meldewege in Incident-Prozesse integrieren, Nachweise releasefest machen und Lieferkettenrollen klären.

Wer diese fünf Punkte früh anpackt, reduziert nicht nur regulatorisches Risiko. Er gewinnt auch etwas, das im Tagesgeschäft fast noch wertvoller ist: schnellere Orientierung im Störfall, klarere Verantwortlichkeiten und deutlich weniger Reibung zwischen Produkt, Security und Betrieb.

Quellen

• Europäische Kommission: Cyber Resilience Act, Überblick und Zeitplan
• Europäische Kommission: Cyber Resilience Act, Manufacturers
• Europäische Kommission: Cyber Resilience Act, Reporting obligations
• ENISA: Single Reporting Platform (SRP) zum Cyber Resilience Act