Wednesday, 16 September 2026

How to manage the software lifecycle

IEC eTech 

article here


Software and AI systems become less secure with age. The issue is gaining increasing momentum with the IEC developing much needed standards.

As digital systems age, they become harder to secure, harder to maintain and increasingly vulnerable to exploitation. In sectors where outages or cyber attacks can threaten public safety, the question of how to retire software safely is now an issue of national resilience. While AI systems are much more recent than old software packages, the issue still must be dealt with as it could become a huge problem sooner than later. (For more on the decommissioning of AI Systems, read this interview in e-tech.) IEC and ISO have prepared standards dealing with both.

The scale of the problem is huge

A study published in November 2025 by WPI Strategy, commissioned by Cisco, highlights the scale of the problem across critical national infrastructure (CNI). According to WPI Strategy: “In 2020, nearly half of business network infrastructure globally was estimated to be obsolete or ageing, making it harder to patch, harder to secure, and easier to exploit.”

The report compares end‑of‑life (EOL) exposure across the US, UK, France, Germany and Japan. It found that the UK has the highest relative exposure to EOL systems. Japan exhibited the lowest exposure, reflecting sustained investment in lifecycle management. In the US, 80% of federal IT spend goes to maintaining existing systems.

Healthcare sector at risk from using outdated systems

Healthcare is one of the most exposed sectors. A 2025 report from one local trust within the UK’s National Health Service outlines the risks: “The network infrastructure… has become obsolete, lacking vendor support. This increases the risk of failure.” The report confirms that legacy issues affect electronic patient records (EPR) and the electronic prescribing and medicines administration (EPMA) as well as clinical decision support systems.

It warns that failure of certain EOL components could be “catastrophic” by impacting the whole of the organization. It is not without precedent. A 2024 cyber attack demonstrated how outdated systems amplify ransomware attacks, leading to cancelled surgeries and huge financial losses.

This case is emblematic of a broader trend. Institutions like hospitals often rely on outdated network hardware, unsupported operating systems and legacy applications that cannot easily be patched or upgraded.

Legacy problems for critical infrastructure

Legacy systems can put public infrastructure at risk. While grid systems increasingly rely on new AI models for processes such as load forecasting and predictive maintenance by ingesting vast amounts of telemetry from substations, sensors and grid assets, they also rely on legacy software systems. If these are not retired appropriately, they can play a part in producing inaccurate predictions that cascade into operational instability. They also can be easily hacked, especially if they are older systems that are not kept up to date with security patches and updates.

The US Environmental Protection Agency (EPA) issued an enforcement alert in May 2024 urging water system operators to conduct cyber security risk assessments. Software systems do not simply expire. Instead, they become misaligned with new systems and data inputs. They may continue operating long after they become outdated or their performance degrades.

In hospitals, this could mean a triage model that once performed well begins making unsafe recommendations. In electricity networks, a forecasting model may become unreliable as consumption patterns shift.

Keeping the machine running

Retiring software isn’t a matter of deleting files or shutting down servers. It’s a question of preserving national capabilities whose functionality must endure long after the hardware they are operating on has been replaced.

Hardware ages quickly; software, at least conceptually, does not. But the two are inseparable. And in that tension lies one of the most pressing challenges for modern infrastructure. “Even though software designers try to reduce hardware dependency through abstractions, and standards help with that, there is always some dependency. Changing hardware often forces changes in software,” explains Sundeep Oberoi, Chair of ISO/IEC JTC 1/SC 7, the joint subcommittee between ISO and IEC responsible for software and systems engineering standards.

While hardware churns, software persists: servers are replaced every few years, networking technologies leapfrog one another, mobile phones are frequently discarded because they can’t support the latest operating system. “This is where technology debt accumulates,” Oberoi says. “Legacy systems, such as COBOL-based tax platforms for instance, continue to perform essential functions, but the ecosystems around them move on. Re‑architecting them becomes risky, expensive and unavoidable.”

The industry’s answer is evergreening: treating software renewal as a continuous process rather than a crisis-driven overhaul. “We’re nowhere near that ideal, but it’s the direction of travel,” Oberoi agrees. The hope is that AI will assist in evergreening by identifying dependencies, mapping impacts, and guiding change. “Conceptually, software has always had the ability to examine itself, self-replicate and change. This is inherent in the idea of a universal machine. AI sharpens those techniques and makes them much more powerful,” Oberoi adds.

But there are limits he acknowledges. “We’re nowhere close to the point where AI decides something needs to change - such as requiring a different processor - and can build that processor on its own,” he says. “Biological systems contain enough information to assemble themselves but AI systems do not. AI may help us realize what needs to be done. But the ecosystem still has to do it.”

Standards are essential for decommissioning both AI and software systems

International standards supported by rigorous lifecycle management, proactive investment and transparent governance are one of the ways of ensuring that critical infrastructure remains resilient, secure and trustworthy, as technology evolves.

ISO/IEC/IEEE 15288 brings structure and consistency to the way organizations engineer and manage AI systems from concept through maintenance and evolution, including disposal. Recently published ISO/IEC/IEEE 12207 is to software what ISO/IEC/IEEE 15288 is to AI systems and deals with retiring software rather than disposal. ISO/IEC 5338 describes the lifecycle of AI systems based on machine learning and heuristic systems. It is based on ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 with modifications and additions of AI-specific processes. These internationally recognized guidelines define clear decommissioning triggers which could be due to regulatory changes; replacement by a validated successor; end of business need; risk of cyber security exposure; and model drift.

Yet another standard, ISO/IEC 8183, defines explicit “data decommissioning” and “system decommissioning” of an AI systems’ stages to manage data and model artefacts responsibly.  This is essential in hospitals, where patient data must be retained for legal reasons but protected from exposure. ISO/IEC 42001 requires organizations to: “plan and manage the decommissioning of AI systems in a controlled manner… ensuring that data and model artefacts are disposed of appropriately.”

These documents define how engineered systems evolve from conception to retirement. But even they have limits. Oberoi explains, “SC 7 models systems only to the extent they can be represented as information. It doesn’t model the physics of a hard disk, only the way data is stored on it. As a result, the committee has not yet confronted the question of what to do with obsolete equipment - only how to preserve the information it contains.”

Of course, software is no longer the domain of large corporations with deep process expertise. It’s built everywhere into startups, micro-businesses and small development shops. That’s why SC 7 developed ISO/IEC 29110-7-1:2026 for Very Small Entities (VSEs). “Smaller entities don’t necessarily have the competence or resources that large organizations do,” Oberoi explains. The VSE work takes existing SC 7 standards for testing frameworks and lifecycle models and scales them down without diluting their intent.

Together, these standards give critical infrastructure operators a structured way to plan for end‑of‑life and manage AI drift, to retire systems safely and reduce cyber security exposure. Those charged with decommissioning software must leave a clear audit trail for how the system operated including its known limitations, the reasons for retirement plus evidence of safe disposal.



No comments:

Post a Comment