Cyber Resilience Act – was bedeutet die EU-Verordnung für jahrzehntealte, aber weiterhin produktive IBM-i-Anwendungen?

Management Summary

Der Cyber Resilience Act (CRA)1 der Europäischen Union stellt verbindliche Anforderungen an die Cybersicherheit bestimmter Hardware- und Softwareprodukte, die auf dem EU-Markt bereitgestellt werden. Für Unternehmen, die IBM i (AS400) einsetzen, bedeutet das nicht, dass bewährte RPG-Anwendungen allein wegen ihres Alters ersetzt werden müssten.
Entscheidend ist vielmehr, welche Rolle ein Unternehmen einnimmt: Hersteller und Anbieter eines Softwareprodukts können unmittelbar vom CRA betroffen sein. Eine ausschliesslich intern eingesetzte Eigenentwicklung fällt dagegen nicht schon aufgrund ihrer Nutzung unter dessen Produktvorschriften. Auch für bestehende Produkte gelten Übergangsregeln, während bestimmte Meldepflichten bereits greifen.
Unabhängig von der unmittelbaren Rechtslage bleiben kontrollierte Zugriffe, sichere Schnittstellen, dokumentierte Anwendungen und verfügbares Fachwissen zentrale Voraussetzungen für einen sicheren Weiterbetrieb. Der CRA ist deshalb weniger ein Argument für den Ersatz bewährter IBM-i-Anwendungen als ein Anlass, deren Sicherheit und Wartbarkeit sorgfältig zu prüfen.

Muss die alte AS400 jetzt weg?

Ursprünglich war für diesen Beitrag der etwas provokative Titel «Cyber Resilience Act – muss die alte AS400 jetzt weg?» vorgesehen. Er bringt eine Befürchtung auf den Punkt, die bei neuen gesetzlichen Anforderungen schnell auftaucht: Müssen langjährig eingesetzte Systeme nun durch neue Software ersetzt werden?
Die kurze Antwort lautet: Nein, sicherlich nicht allein wegen des CRA. Die Verordnung verlangt keine pauschale Ausmusterung alter IT-Systeme. Sie verfolgt das Ziel, digitale Produkte sicherer zu machen und ihre Hersteller zu einem geregelten Umgang mit Sicherheitsrisiken und Schwachstellen zu verpflichten. Ob und in welchem Umfang diese Pflichten greifen, hängt vom konkreten Produkt und von dessen Bereitstellung auf dem EU-Markt ab.2
Bei IBM i ist zudem zwischen der Plattform selbst, ihren Komponenten und den darauf betriebenen Anwendungen zu unterscheiden. Eine jahrzehntealte, intern eingesetzte RPG-Anwendung ist rechtlich nicht automatisch mit einem kommerziell vertriebenen Softwareprodukt gleichzusetzen.

Zwei Stichtage – unterschiedliche Konsequenzen

11. September 2026

Seit diesem Datum gelten die Meldepflichten gemäss Artikel 14 CRA. Hersteller von Softwareprodukten, die unter den CRA fallen, müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, welche die Sicherheit ihrer Produkte beeinträchtigen.
Vorgesehen sind grundsätzlich eine Frühwarnung innerhalb von 24 Stunden und eine weitere Meldung innerhalb von 72 Stunden nach Kenntniserlangung. Weitere Abschlussberichte folgen je nach Ereignis. Diese Meldepflichten gelten auch für bereits auf dem Markt befindliche Produkte. Sie richten sich grundsätzlich an die Hersteller und nicht an Unternehmen, welche die Software lediglich einsetzen.3

11. Dezember 2027

Ab diesem Datum finden die wesentlichen übrigen Vorschriften des CRA Anwendung. Für neu auf den EU-Markt gebrachte Produkte im Anwendungsbereich gelten unter anderem Anforderungen an die Sicherheit, das Schwachstellenmanagement, die Dokumentation, Sicherheitsupdates und die Konformitätsbewertung. Bereits auf dem Markt befindliche Produkte unterliegen diesen zusätzlichen Anforderungen grundsätzlich nur dann, wenn sie wesentlich verändert werden. Was als wesentliche Veränderung gilt, muss im Einzelfall beurteilt werden.4 5 Die bereits geltenden Meldepflichten bleiben davon unabhängig bestehen.

Was bedeutet das für IBM i und RPG?

Für einen Hersteller, der Software auf IBM i entwickelt und als Produkt auf dem EU-Markt anbietet, kann der CRA unmittelbar relevant sein. Bei der ausschliesslich unternehmensinternen Verwendung einer Eigenentwicklung entsteht dagegen keine Herstellerpflicht nach CRA. Wird eine Anwendung für Dritte bereitgestellt oder wesentlich verändert, so sind die konkreten Umstände genauer zu prüfen.6 7
Aus technischer Sicht sind viele der angesprochenen Sicherheitsfragen nicht neu: Wer darf auf welche Daten zugreifen? Sind Benutzer- und Objektberechtigungen angemessen eingerichtet? Wie sind Schnittstellen abgesichert? Werden Änderungen nachvollziehbar getestet und dokumentiert? Besteht ein geregelter Prozess für die Behandlung erkannter Schwachstellen?
Ein modernes Erscheinungsbild macht eine Anwendung nicht automatisch sicher. Umgekehrt ist eine über viele Jahre gewachsene RPG-Anwendung nicht allein wegen ihres Alters unsicher. Die Sicherheit ergibt sich aus Architektur, Konfiguration, Betrieb, Wartung und dem verantwortungsvollen Umgang mit Änderungen.

Das unterschätzte Risiko: fehlendes Fachwissen

Was geschieht, wenn eine sicherheitsrelevante Schwachstelle in einer wichtigen Anwendung erkannt wird – aber niemand mehr die zugehörigen RPG-Programme oder CL-Abläufe ausreichend versteht?
Nicht nur fehlende Updates, sondern auch unzureichende Dokumentation und verlorenes Anwendungswissen können zum Problem werden. Wer Abhängigkeiten und Schnittstellen nicht kennt, kann Risiken nur schwer beurteilen und Korrekturen kaum zuverlässig umsetzen. Hier besteht ein unmittelbarer Bezug zu unserem früheren Blogbeitrag: «Da müssen Sie unseren Administrator fragen».
Die gezielte Pflege, Dokumentation und Weiterentwicklung bestehender IBM-i-Anwendungen kann daher eine bessere Lösung sein als ihre überstürzte Ablösung. Voraussetzung ist, dass Risiken tatsächlich erkannt und behoben werden können.

Eine wichtige Abgrenzung: CRA, NIS2 und DORA

Der CRA ist keine allgemeine Betriebssicherheitsverordnung für sämtliche Unternehmen und deren interne IT-Systeme. Im Mittelpunkt stehen digitale Produkte und die Pflichten der jeweiligen Wirtschaftsakteure, insbesondere der Hersteller.
Für den sicheren Betrieb von IT-Systemen können dagegen weitere Regeln relevant sein. Die NIS2-Richtlinie8 betrifft die Cybersicherheit bestimmter Unternehmen und Einrichtungen in den erfassten Sektoren; ihre konkreten Verpflichtungen ergeben sich aus der jeweiligen nationalen Umsetzung. DORA9 stellt besondere Anforderungen an die digitale operationelle Resilienz im Finanzsektor. Diese Vorschriften dürfen nicht mit den produktbezogenen Herstellerpflichten des CRA verwechselt werden.

IBM i – Sicherheit hat Tradition

Bei aller Diskussion über den Cyber Resilience Act darf eines nicht vergessen werden: Die AS400/IBM i gehört seit Jahrzehnten zu den Plattformen mit einer besonders konsequenten Sicherheitsarchitektur. Das Betriebssystem wurde von Anfang an mit einem ausgefeilten Berechtigungskonzept, objektbasierter Architektur und einer engen Integration von Betriebssystem und Datenbank entwickelt. Viele Sicherheitsmechanismen, die bei anderen Plattformen nachträglich ergänzt werden mussten, waren hier bereits früh Bestandteil des Systems.
Und IBM ruht sich darauf keineswegs aus. Mit neuen Versionen, Releases, Technology Refreshes und PTFs erweitert und verbessert IBM die Sicherheitsfunktionen der Plattform kontinuierlich. Ein aktuelles Beispiel ist die mit IBM i 7.6 eingeführte integrierte Multi-Faktor-Authentifizierung (MFA). Zusätzlich zum Passwort kann ein zeitabhängiger Einmalcode verlangt werden. Damit lässt sich der Zugriff auf das System wesentlich besser absichern.10
Natürlich ist auch IBM i nicht von Sicherheitsrisiken ausgenommen. Eine falsch konfigurierte Berechtigungsstruktur, ungeschützte Schnittstellen oder fehlende Sicherheitsupdates können selbst die beste Architektur unterlaufen.
Aber eine jahrzehntealte RPG-Anwendung läuft deshalb noch lange nicht auf einer veralteten oder unsicheren Plattform.
Gerade die kontinuierliche Weiterentwicklung von IBM i zeigt, dass bewährte Anwendungen und moderne Sicherheitsanforderungen keineswegs im Widerspruch stehen müssen.

Fazit

Der Cyber Resilience Act ist kein Ablaufdatum für IBM i oder RPG. Er schärft jedoch den Blick für Verantwortlichkeiten, Sicherheitsrisiken und die Fähigkeit, Schwachstellen während des Lebenszyklus eines Softwareprodukts zu beheben.
Für Betreiber bestehender IBM-i-Anwendungen lohnt sich deshalb eine Bestandsaufnahme: Sind Zugriffe und Schnittstellen sicher? Sind Programme und Abhängigkeiten dokumentiert? Steht genügend Fachwissen zur Verfügung, um kritische Korrekturen zuverlässig vorzunehmen?
Nicht das Alter einer Anwendung entscheidet über ihre Sicherheit, sondern wie sie entwickelt, betrieben, gewartet und geschützt wird.

Hinweis: Dieser Beitrag gibt einen allgemeinen Überblick und ersetzt keine rechtliche Prüfung des konkreten Einzelfalls.