Cyber Resilience Act – what does the EU regulation mean for decades-old IBM i applications that are still in production?
Management Summary
The European Union's Cyber Resilience Act (CRA)1 establishes binding cybersecurity requirements for certain hardware and software products made available on the EU market. For companies using IBM i (AS400), this does not mean that proven RPG applications must be replaced simply because of their age.
What matters is the role a company plays: manufacturers and suppliers of software products may be directly affected by the CRA. By contrast, an application developed in-house and used exclusively internally does not fall under its product requirements merely because it is in use. Transitional provisions also apply to existing products, while certain reporting obligations are already in force.
Regardless of the specific legal obligations, controlled access, secure interfaces, documented applications and the availability of specialist knowledge remain essential for secure ongoing operation. The CRA is therefore less a reason to replace proven IBM i applications than an opportunity to examine their security and maintainability carefully.
Does the old AS400 now have to go?
The original idea for this article was the somewhat provocative title 'Cyber Resilience Act – does the old AS400 now have to go?' It captures a concern that quickly arises when new legal requirements are introduced: must long-established systems now be replaced with new software?
The short answer is: No, certainly not simply because of the CRA. The regulation does not require old IT systems to be phased out across the board. Its aim is to make digital products more secure and oblige their manufacturers to manage security risks and vulnerabilities in a structured manner. Whether these obligations apply, and to what extent, depends on the particular product and how it is made available on the EU market.2
For IBM i, a distinction must also be made between the platform itself, its components and the applications running on it. An RPG application used internally for decades is not automatically treated in law in the same way as a commercially distributed software product.
Two key dates – different consequences
11 September 2026
The reporting obligations under Article 14 of the CRA have applied since this date. Manufacturers of software products covered by the CRA must report actively exploited vulnerabilities and severe security incidents affecting the security of their products.
In principle, an early warning must be submitted within 24 hours of becoming aware of the issue, followed by a further notification within 72 hours. Additional final reports are required depending on the nature of the event. These reporting obligations also apply to products already on the market. They are directed primarily at manufacturers, not at businesses that merely use the software.3
In principle, an early warning must be submitted within 24 hours of becoming aware of the issue, followed by a further notification within 72 hours. Additional final reports are required depending on the nature of the event. These reporting obligations also apply to products already on the market. They are directed primarily at manufacturers, not at businesses that merely use the software.3
11 December 2027
The main remaining provisions of the CRA will apply from this date. Products newly placed on the EU market and falling within its scope will be subject to requirements covering security, vulnerability management, documentation, security updates and conformity assessment, among other matters. Products already placed on the market will, as a general rule, be subject to these additional requirements only if they undergo a substantial modification. Whether a change constitutes a substantial modification must be assessed case by case.4 5 The reporting obligations already in force remain unaffected.
What does this mean for IBM i and RPG?
For a manufacturer that develops software on IBM i and offers it as a product on the EU market, the CRA may be directly relevant. By contrast, using an in-house application exclusively within a company does not create manufacturer obligations under the CRA. If an application is made available to third parties or substantially modified, the specific circumstances need closer examination.6 7
From a technical perspective, many of the security questions raised are not new: who may access which data? Are user and object authorities configured appropriately? How are interfaces secured? Are changes tested and documented in a traceable way? Is there a structured process for addressing identified vulnerabilities?
A modern appearance does not automatically make an application secure. Conversely, an RPG application that has evolved over many years is not insecure simply because of its age. Security depends on architecture, configuration, operations, maintenance and the responsible management of changes.
The underestimated risk: loss of specialist knowledge
What happens when a security-related vulnerability is discovered in an important application, but nobody sufficiently understands the associated RPG programs or CL processes any more?
Missing updates are not the only problem: inadequate documentation and lost application knowledge can be just as serious. Anyone unfamiliar with dependencies and interfaces will struggle to assess risks or implement corrections reliably. This relates directly to our earlier blog article: 'You'll have to ask our administrator'.
Targeted maintenance, documentation and further development of existing IBM i applications may therefore be a better solution than replacing them in haste. The prerequisite is that risks can genuinely be identified and remedied.
An important distinction: CRA, NIS2 and DORA
The CRA is not a general IT operational security regulation for every company and all its internal IT systems. Its focus is on digital products and the obligations of the relevant economic operators, particularly manufacturers.
Other rules may, however, be relevant to the secure operation of IT systems. The NIS2 Directive8 addresses cybersecurity in certain businesses and organisations operating in covered sectors; their specific obligations arise from the relevant national implementation. DORA9 sets out particular requirements for digital operational resilience in the financial sector. These rules must not be confused with the CRA's product-related manufacturer obligations.
IBM i – security has a long tradition
Amid all the discussion about the Cyber Resilience Act, one thing should not be forgotten: for decades, AS400/IBM i has been among the platforms with a particularly rigorous security architecture. From the outset, the operating system was designed with a sophisticated authority model, an object-based architecture and close integration between the operating system and the database. Many security mechanisms that other platforms had to add later were built into this system early on.
Nor has IBM been resting on its laurels. With new versions, releases, Technology Refreshes and PTFs, IBM continuously enhances and improves the platform's security capabilities. A recent example is the integrated multi-factor authentication (MFA) introduced with IBM i 7.6. In addition to a password, a time-based one-time code can be required, providing substantially stronger protection for system access.10
Of course, IBM i is not immune to security risks. Incorrectly configured authorities, unsecured interfaces or missing security updates can undermine even the best architecture.
But the fact that an RPG application is decades old certainly does not mean it is running on an outdated or insecure platform.
IBM i's continuous development demonstrates that proven applications and modern security requirements need not be contradictory.
Conclusion
The Cyber Resilience Act is not an expiry date for IBM i or RPG. It does, however, sharpen our awareness of responsibilities, security risks and the ability to remedy vulnerabilities throughout the lifecycle of a software product.
For operators of existing IBM i applications, a review is therefore worthwhile: are access rights and interfaces secure? Are programs and dependencies documented? Is sufficient specialist knowledge available to make critical corrections reliably?
An application's age does not determine its security; what matters is how it is developed, operated, maintained and protected.
