Bildquelle: extern
Cyber Resilience Act im Unternehmensbetrieb: Welche 5 Vorarbeiten IT-Teams 2026 bei Software, Geräten und Lieferanten jetzt beginnen sollten
Der Cyber Resilience Act, kurz CRA, ist keine Randnotiz mehr für Regulierungsabteilungen. Die EU verankert damit verbindliche Sicherheitsanforderungen für Produkte mit digitalen Elementen, also für Hardware, Software und viele Komponenten dazwischen. Laut Europäischer Kommission gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle ab dem 11. September 2026, die Hauptpflichten des Gesetzes folgen ab dem 11. Dezember 2027.
Wichtig ist dabei eine oft übersehene Trennlinie: Der CRA richtet sich primär an Hersteller. Für Unternehmens-IT, Service-Owner, Einkauf und Lieferantenmanagement entsteht der operative Druck aber schon vorher. Denn wer Standardsoftware, Appliances, Clients, Netzwerkprodukte oder spezialisierte Plattformen einkauft und betreibt, muss 2026 anfangen, die künftigen Herstellerpflichten in seine Beschaffungs-, Lifecycle- und Incident-Prozesse zu übersetzen. Sonst kommen Supportfristen, Konformitätsnachweise und Sicherheitsmeldungen später ungeordnet in Betrieb und Service Management an.
Für die Praxis sind vor allem diese fünf Vorarbeiten sinnvoll.
1. Zuerst eine belastbare Produktliste aufbauen, nicht nur eine Lieferantenliste
Viele Organisationen pflegen Verträge sauberer als ihre tatsächlich eingesetzten Produkte. Genau das wird beim CRA zum Problem. Die Verordnung spricht über Produkte mit digitalen Elementen, nicht bloß über Herstellerlogos auf Rahmenverträgen. IT-Teams sollten deshalb 2026 eine Liste aufbauen, die mindestens vier Dinge zusammenführt: Produktname, Hersteller, Einsatzkontext und verantwortlicher Service-Owner.
Praktisch heißt das: Nicht nur Microsoft, Cisco oder Atlassian erfassen, sondern konkret die eingesetzten Produkte, Editionen und Betriebsrollen. Für ein Service Management ist relevant, ob ein Produkt Kernbestandteil eines geschäftskritischen Services ist, ob es internetnah betrieben wird und wie eng es in Identität, Datenhaltung oder Automatisierung eingebunden ist. Ein Collaboration-Tool, ein VPN-Gateway und ein OT-nahes Verwaltungssystem erzeugen sehr unterschiedliche Risiken, auch wenn sie alle formal „Software“ sind.
Ohne diese Produktperspektive lassen sich spätere CRA-Nachweise nicht sauber zuordnen. Dann landet etwa eine Herstellerinformation zu Supportdauer, Konformität oder Schwachstellenhandling im zentralen Einkauf, während die Betriebsverantwortung im Endpoint-Team, beim Plattformbetrieb oder im Service Desk liegt. Wer 2026 sauber segmentiert, spart sich 2027 genau diese Reibungsverluste.
2. Beschaffungsfragen um CRA-taugliche Pflichtfelder erweitern
Die Kommission betont auf ihrer Herstellerseite mehrere Pflichtpunkte: Produkte sollen sicher entworfen sein, standardmäßig sichere Einstellungen mitbringen, über einen angegebenen Supportzeitraum verfügen und mit Konformitätsunterlagen bis hin zur CE-Kennzeichnung in den Markt gehen. Für Käufer heißt das nicht, jedes Produkt juristisch selbst zu bewerten. Aber sie sollten Beschaffung und Lieferantenfreigabe um wenige harte Pflichtfelder ergänzen.
Sinnvoll sind 2026 vor allem diese Abfragen: Wie lange unterstützt der Hersteller das Produkt sicherheitsrelevant? Wo stellt er Sicherheitsupdates und Hinweise zentral bereit? Wer ist zuständig für Schwachstellenmeldungen? Welche Produktvarianten werden in Europa unter welcher Konformitätsaussage vermarktet? Und wie werden sichere Standardeinstellungen, Zugriffssteuerung und Update-Mechanismen dokumentiert?
Das klingt nach Formalie, ist im Alltag aber ein echter Hebel. Viele Einkaufsprozesse fragen Preis, Datenschutzanhang und Betriebsmodell ab, jedoch nicht, wie lange Sicherheitskorrekturen realistisch geliefert werden. Gerade bei Spezialsoftware, Embedded-Systemen und branchenspezifischen Appliances ist genau das später entscheidend. Wenn diese Felder jetzt in RFI-, RFP- und Freigabevorlagen wandern, entsteht aus dem CRA kein hektischer Nachforderungslauf.
3. Supportfristen und Produktende in CMDB, Servicekatalog und Roadmaps verankern
Ein besonders wertvoller CRA-Baustein für Betreiber ist die Pflicht, einen Supportzeitraum anzugeben. Diese Information hilft nur dann, wenn sie nicht in PDFs verschwindet, sondern im laufenden IT-Betrieb sichtbar wird. Deshalb sollten IT-Organisationen Supportfristen künftig wie ein echtes Steuerungsdatum behandeln, ähnlich wie Vertragsende, Zertifikatslaufzeit oder End of Support eines Betriebssystems.
Das gehört in die CMDB, in Lifecycle-Übersichten und in die Service-Roadmaps. Service-Owner müssen erkennen können, welche Produkte in den nächsten 12, 18 oder 24 Monaten in eine kritische Supportphase laufen. Plattformteams können daraus Migrationspfade ableiten, der Einkauf kann Verlängerungen oder Alternativen früher prüfen, und das Management bekommt ein belastbares Bild darüber, wo technische Schuld regulatorisch unangenehm werden könnte.
Gerade im IT Service Management ist dieser Punkt wichtiger als jede Schlagzeile zum CRA. Wenn Supportfristen nur dokumentiert, aber nicht aktiv geführt werden, wird aus einem Compliance-Thema schnell wieder ein Major Incident im falschen Monat. Gute Organisationen verbinden deshalb Produktdaten, Serviceauswirkung und Erneuerungsplanung in einem einzigen Blick.
4. Meldewege für Herstellerhinweise vor September 2026 neu ordnen
Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle über die europäische Meldearchitektur melden, zunächst mit einer Frühwarnung innerhalb von 24 Stunden nach Kenntnis und danach mit einer ausführlicheren Meldung innerhalb von 72 Stunden. Für Betreiber entsteht daraus eine wichtige Folge: Die offizielle Behördenmeldung ersetzt nicht die betriebliche Information an Kunden und Service-Teams.
Deshalb sollten Unternehmen ihre Lieferantenbeziehungen jetzt um klare Spiegelmeldungen ergänzen. Wenn ein Hersteller eine aktiv ausgenutzte Schwachstelle an Behörden meldet, braucht die interne IT idealerweise zeitgleich eine belastbare Information für Triage, Priorisierung, Exposure-Prüfung und Kommunikation. Sonst erfährt das SOC über Medien oder Threat Feeds von einem Thema, zu dem Einkauf, Service Desk und Plattformbetrieb noch keine bestätigte Herstellerlage haben.
Praktisch hilft eine einfache Regel: Für kritische Produkte wird 2026 ein definierter Eingangskanal für Sicherheitsmeldungen festgelegt, samt Vertretung, Prioritätsklasse und Weiterleitung an Incident Management, Vulnerability Management und betroffene Service-Owner. Wer diese Wege nicht vorab festzieht, bekommt im Ernstfall parallele Mailketten statt eines steuerbaren Sicherheitsprozesses.
5. CRA nicht als Rechtsprojekt isolieren, sondern als Betriebsaufgabe mit Einkauf, Security und ITSM führen
Der größte Fehler wäre, den CRA als spätere Pflicht der Hersteller abzuhaken. Operativ betrifft das Thema mindestens Einkauf, Informationssicherheit, Architektur, Plattformbetrieb, Endpoint-Management und IT Service Management. Denn dort entscheiden sich Produktfreigaben, Ausnahmen, Asset-Transparenz, Lebenszyklussteuerung und Incident-Reaktion.
Für 2026 reicht oft schon ein schlanker Arbeitsmodus: ein gemeinsames Backlog, ein verantwortlicher Owner und quartalsweise Reviews für die kritischsten Produktgruppen. Diese Reviews sollten nicht auf Vollständigkeit für alle Assets zielen, sondern auf die 20 Prozent Produkte, die 80 Prozent des Betriebsrisikos tragen. Dazu gehören meist Identitätskomponenten, Netzwerkinfrastruktur, Fernzugang, Endgeräteplattformen, zentrale Collaboration- und Administrationswerkzeuge sowie branchenspezifische Kernsysteme.
Genau hier zeigt sich der praktische Nutzen des CRA. Er liefert einen externen Takt, um Produktverantwortung, Lieferantensteuerung und Sicherheitsbetrieb enger zusammenzuführen. Wer das Thema früh gemeinsam aufsetzt, bekommt nicht nur bessere Compliance, sondern oft auch sauberere Erneuerungsentscheidungen, weniger blinde Flecken bei Supportenden und schnellere Reaktion bei Herstellerwarnungen.
Fazit
Der Cyber Resilience Act verpflichtet vor allem Hersteller, aber seine Folgen landen direkt im Tagesgeschäft der Unternehmens-IT. 2026 ist deshalb das richtige Jahr, um Produktlisten zu schärfen, Beschaffungsfragen anzupassen, Supportfristen sichtbar zu machen, Sicherheitsmeldungen sauber zu routen und den CRA als gemeinsame Betriebsaufgabe zu führen. Wer diese fünf Vorarbeiten jetzt startet, muss 2027 nicht hektisch nachdokumentieren, sondern kann regulatorische Anforderungen in ein brauchbares Steuerungsmodell für Software, Geräte und Lieferanten übersetzen.
Quellen
- Europäische Kommission: Cyber Resilience Act
- Europäische Kommission: Cyber Resilience Act – Implementation
- Europäische Kommission: Cyber Resilience Act – Manufacturers
- Europäische Kommission: Cyber Resilience Act – Reporting obligations
