Cyber Resilience Starts With Software Engineering

Cyber Resilience Starts With Software Engineering

by | Jun 4, 2026 | Article

Cyber Resilience Starts With Software Engineering

What the UK Cyber Security & Resilience Bill and Software Security Code of Practice Mean for Organisations Operating Critical Systems

Introduction

For many years, cyber resilience has largely been viewed through the lens of security controls, monitoring, governance and compliance. While these remain important, they represent only part of the picture.

Increasingly, the resilience of critical systems is being determined much earlier in the lifecycle by software architecture, technology choices, systems integration decisions and the ability to maintain software over decades of operation.

The proposed UK Cyber Security & Resilience Bill and the UK Software Security Code of Practice both point in the same direction: cyber resilience must be engineered into systems from the outset rather than added later.

For organisations operating critical infrastructure, that shift has significant implications.

The Growing Gap Between Infrastructure and Technology

One of the defining characteristics of critical infrastructure is longevity.

Rail signalling systems, industrial control systems, defence platforms, transport systems and utilities infrastructure are often expected to remain operational for decades. Yet the software, hardware and development environments on which they depend evolve at a dramatically faster rate.

This creates a growing disconnect between the operational life of infrastructure and the lifecycle of the technologies embedded within it.

Historically, this was viewed primarily as an obsolescence issue. Today it is increasingly becoming a cyber resilience issue.

Many organisations are discovering that software and hardware require replacement not because they have failed, but because they can no longer be adequately secured, supported or maintained.

The UK Government’s response to the Software Security Code of Practice consultation highlighted that 59% of organisations globally are believed to have been impacted by a software supply-chain attack or exploit, yet only 11% of businesses assess risks posed by immediate suppliers.

The implication is clear: software lifecycle management and supply-chain understanding are becoming fundamental components of cyber resilience.

Why Cyber Resilience Starts Long Before Deployment

The Software Security Code of Practice places significant emphasis on secure-by-design principles.

At first glance this may appear to be a software development concern. In reality, it is a systems engineering challenge.

Cyber resilience is influenced by decisions made long before a system enters service, including:

  • Software architecture
  • Interface design
  • Technology selection
  • Third-party dependencies
  • Verification strategies
  • Update mechanisms
  • Systems integration approaches

Many organisations understand these principles. The challenge is applying them within complex operational environments where legacy systems, operational constraints and long asset lifecycles must also be considered.

This is particularly true within critical infrastructure, where replacing a system is rarely straightforward and where changes often carry operational, safety and regulatory implications.

Beyond Cyber Security: Engineering Resilience

A resilient system is not simply a system that is secure today.

It is a system that can still be understood, maintained, tested, modified and supported years into the future.

Many organisations possess source code but no longer possess the build environments, test frameworks, engineering knowledge, configuration baselines or specialist tooling required to safely evolve their systems.

Over time:

  • Original engineering teams retire
  • Suppliers cease trading
  • Development tools become obsolete
  • Documentation becomes incomplete
  • Knowledge gradually disappears

As software lifecycles continue to shorten while infrastructure lifetimes continue to extend, engineering resilience is becoming an increasingly important part of cyber resilience.

This is an area that receives far less attention than vulnerabilities and threat detection, but it often determines whether organisations can respond effectively when change becomes necessary.

The Hidden Cyber Risk: Software Lifecycle Management

Cyber security discussions often focus on vulnerabilities, threats and incidents.

Less attention is paid to the engineering capability required to support software over time.

Questions organisations should be asking include:

  • Can we still build the software?
  • Can we still test it?
  • Do we understand how it behaves?
  • Are the original development tools still available?
  • Can security updates be implemented safely?
  • Do we understand all external dependencies?

In many cases, source code still exists, but the surrounding engineering ecosystem has disappeared.

Compilers, build environments, test harnesses, simulators and specialist diagnostic tools may no longer be available.

The result is that seemingly small software changes become increasingly difficult, expensive and risky.

Where Cyber Resilience and Obsolescence Converge

For many organisations, cyber resilience and obsolescence are still managed as separate challenges.

In practice, they are becoming increasingly interconnected.

The same factors that create software obsolescence often create cyber resilience risks:

  • Unsupported operating systems
  • Unsupported software libraries
  • Obsolete development tools
  • Disappearing technical knowledge
  • Inability to test or modify software safely
  • Loss of supplier support

A system does not need to fail in order to become a risk.

It may continue to operate exactly as intended while becoming progressively more difficult to maintain, secure and evolve.

As a result, organisations are increasingly discovering that software lifecycle management, obsolescence management and cyber resilience are no longer separate disciplines. They are different perspectives on the same underlying challenge: how to maintain confidence in software-intensive systems over long operational lifecycles.

This is particularly relevant for organisations operating long-life infrastructure, where software may remain operational for decades while the technologies, tools, suppliers and security expectations around it continue to evolve.

When Operational Systems Can No Longer Be Maintained Securely

One of the most significant trends emerging across critical infrastructure is that cyber security is becoming a direct driver of obsolescence.

Historically, systems were replaced because they failed functionally or became unreliable.

Increasingly, systems are being replaced because they can no longer meet modern security expectations.

Examples include:

  • Unsupported operating systems
  • Unsupported software libraries
  • Insecure communication protocols
  • Inability to implement security patches
  • Lack of secure update mechanisms
  • Regulatory and compliance requirements

This creates a new category of obsolescence where systems remain operationally functional but become increasingly difficult to justify from a cyber resilience perspective.

As explored in Zircon’s previous articles on Artificial Intelligence Obsolescence, Cybersecurity and Obsolescence, and The Challenge of Obsolescence in UK Infrastructure, software obsolescence and cyber resilience can no longer be treated as separate disciplines.

What Organisations Should Be Doing Now

Rather than waiting for failures, vulnerabilities or compliance pressures to force action, organisations should adopt a more proactive approach.

1. Assess Software Lifecycle Risks

Understand not only what software is deployed, but how it is maintained, supported, tested and updated.

2. Review Obsolescence Exposure

Identify unsupported technologies, ageing platforms, disappearing development environments and supplier dependencies before they become operational problems.

3. Preserve Critical Engineering Knowledge

Source code alone is rarely enough. Development environments, test systems, configuration baselines, build processes and engineering knowledge may be equally important to long-term resilience.

4. Apply Secure-by-Design Principles

Consider security, maintainability, supportability and update mechanisms from the outset of any development or modernisation programme.

5. Plan for Continuous Evolution

Long-life infrastructure increasingly requires managed evolution rather than periodic wholesale replacement.

How Zircon Helps

For more than 25 years, Zircon has helped organisations address complex software and systems engineering challenges across rail, highways, defence and industrial sectors.

Our expertise spans software engineering, systems engineering, assurance, software obsolescence management, systems integration, lifecycle management and technology modernisation.

Whether the challenge is modernising a legacy system, understanding software lifecycle risk, addressing technology obsolescence or applying secure-by-design engineering principles, our focus remains the same: helping organisations build and maintain resilient operational systems.

Further Reading

To explore these topics in more detail, we recommend:

Together, these papers explore how ageing software, technology evolution, cyber security requirements and operational resilience are becoming increasingly interconnected challenges for organisations operating critical systems.

Looking Ahead

The future of cyber resilience will be influenced as much by engineering decisions as security controls.

Organisations that understand the relationship between software engineering, lifecycle management, obsolescence and cyber resilience will be better positioned to manage risk, maintain operational capability and adapt to evolving regulatory expectations.

For critical infrastructure operators and suppliers, cyber resilience no longer starts with security controls.

It starts with software engineering.

More From The Blog

Cyber Resilience Starts With Software Engineering

Cyber Resilience Starts With Software Engineering

What the UK Cyber Security & Resilience Bill and Software Security Code of Practice Mean for Organisations Operating Critical SystemsFor many years, cyber resilience has largely been viewed through the lens of security controls, monitoring, governance and...

Zircon Software Accepted onto Aurora Engineering Partnership

Zircon Software Accepted onto Aurora Engineering Partnership

Zircon Software Accepted onto Aurora Engineering PartnershipZircon Software is excited to announce our selection as a specialist supplier on the Aurora Engineering Partnership, marking a significant milestone in our continued growth and commitment to growing our...

AI Obsolescence: Is your Algorithm as accurate today as it was yesterday?

AI Obsolescence: Is your Algorithm as accurate today as it was yesterday?

by | Dec 16, 2025 | Article

AI Obsolescence: Is your Algorithm as accurate today as it was yesterday?

So far in our series on software obsolescence, we’ve covered the lifespan disparity between digital and physical systems in critical infrastructure, and the inescapable link between cybersecurity and obsolescence.

But there’s another area that we specialise in, with its own unique form of obsolescence; artificial intelligence.

If we were to ask you, could you tell us how accurate your AI algorithm is? Not at the time it was first purchased or developed, but right here right now? This week compared to last week?

To help get a grasp on what this question really means, we sat with Dr. Peter Overbury, a foremost expert in the field of ML and AI – and Head of AI at Zircon Software. We discussed obsolescence management in AI, and what the organisations dependent on these algorithms should be doing to safeguard their futures.

A form of Obsolescence unique to AI

As history has shown, factors that work to cause typical obsolescence within software include end of vendor support, changing user requirements and hardware end of life or incompatibility. These are all things that are easy to spot and address.

AI on the other hand, though it will also have to deal with the “traditional” forms listed above, also has its own unique flavour of obsolescence. Black box AI systems can degrade or even fail – sometimes rapidly – despite no change in the hardware or the models employed.

This is because, while progress in AI is often stop-start with occasional seismic shifts, as evidenced by the seemingly overnight one-upping of ChatGPT by Deepseek, obsolescence in AI doesn’t necessarily arise from quantum leaps in hardware or modelling, but from data.

Sudden environmental changes, temporary pattern shifts, biases built into data, and outlier events can all cause AI algorithm accuracy to degrade. And this can be due to how AI systems are trained.

Peter explains that AI training comes in two main groups; supervised and unsupervised.

“Supervised [training] is like teaching someone French in a classroom, and unsupervised is like dropping them in France.

Some unsupervised systems adapt to new data over time, but they can make the wrong assumptions if they learn too fast; like nobody ever using trains again because of COVID.”

The COVID pandemic presented a sudden striking change to long-established behaviours, and to AI training. During the lockdown periods, people being forced to stay home and the use of face masks whilst in public led to widespread issues in everything from passenger flow prediction algorithms, to the facial recognition algorithms behind the iPhone’s FaceID. For example – in Uruguay, during the pandemic, public transportation usage in Montevideo decreased by 71.4%.

As Peter shared:

“COVID wrecked a lot of these systems because suddenly it went from ‘I can predict how many people are going to be using your trains based on unsupervised learning’, to ‘oh, no one’s using the trains – well, no one will ever use trains. No one will ever use trains ever again…”

Peter shared another example, where pre-pandemic AI models for urban traffic flow prediction struggled to handle how remote work and hybrid schedules altered commuting patterns. A post pandemic study developed an artificial neural network model to correlate the impact of COVID-19 response measures on urban traffic flows.

As anyone who had an iPhone in their possession can tell you, recognising the sudden obsolescence within their software Apple rushed to make adjustments to allow users to enable mask compatible FaceID recognition. Even now despite being several years out of the pandemic this adjustment is still in place and has become an optional part of the set up process for new devices.

These examples highlight how a sudden, rapid change brought on by external factors can suddenly cause system-wide prediction failures.

And if change is the only constant, then AI will remain perpetually vulnerable to obsolescence.

The difference a pixel can make

COVID is quite an extreme example of a sudden large shift in data input, however it doesn’t always take such a significant change – in fact, just changing the value of one single pixel can fool a neural network into thinking it’s seeing something totally different.

When is a horse not a horse? When it’s a frog. A “one pixel attack” can make an algorithm say it’s looking at an image of a frog, with 99.9% certainty, when in fact it has been fed an image of a horse. By modifying just a single pixel horses can become frogs and turtles can become rifles. AI is susceptible to drops in accuracy over time, without any kind of malicious intent or attacks being coordinated. Changing conditions, from new street lighting installations to changing fashions, can cause algorithm accuracy to drop – because it’s acting on “obsolete” data. And that drop in accuracy can be anywhere from tolerable to unusable.

Peter puts it this way;

“The challenge for businesses is, ‘What’s an acceptable level of accuracy?’ If your system is identifying trespassers on railway tracks, how often is a false alarm acceptable?

There’s a famous example in computer vision about a person wearing a shirt with a full-body image of another person on it – would [the system] count that as another person? A lot of the time, we rely on logical rules to separate that out.

But if conditions change, like new lighting, new clothing, the accuracy might start to degrade – and eventually it becomes unusable. That’s a big part of managing AI obsolescence.”

Do you know if you've got a problem?

As we stated at the beginning of this article, could you tell us how accurate your AI algorithm is? For some organisations the answer is probably not.

Peter notes;

“Many businesses never check their systems again after deployment. Others set up ways to detect performance drops and retrain.”

For organisations that don’t check in, or that lack self-monitoring systems, the only warning sign they’ll get is failure. For those that do check, the red flags will be clear; increased interventions and a drop in accuracy. But the root causes may be less obvious, and the AI might not be able to adapt.

Which brings us to whether an AI system could simply train itself out of obsolescence.

Largely, the answer is no. Self-evolving AI has practical risks. As we briefly touched on when we mentioned unsupervised learning, this kind of error in detection can be a major problem for algorithms designed to continuously improve.  Once horses start becoming frogs and turtles are being registered as rifles, like an ever decreasing circle this negative reinforcement will do nothing but continue to confirm these detections to be true regardless of the high degree of inaccuracy.

It’s best practice to use a hybrid of the two – allowing the AI to make discoveries and pathways for itself – in semi-unsupervised approaches. This involves partial automation, plus human checks, or periodically retraining the system manually from new data.

It’s not a one-size-fits-all situation, but Zircon can help swap out modules and retrain a system that has fallen foul of faulty data.

Overcoming obsolescence

First, businesses and organisations need to ask themselves;

  1. How accurate is our system today, versus when it was implemented?
  2. Would we be able to notice a problem before it becomes too big?
  3. If there are problems, can we change individual components of our system?
  4. Is our system self-monitoring – and is it training itself unsupervised?
  5. Scrutinise the training data; is it clean, reliable – unbiased?
  6. Is our system open source or is it closed, with vendor tie-in?
Organisations need to adopt a future-thinking mindset rather than being swept up in the new things AI technology can do today. They need to remember that an AI system will only ever be as good as the data it’s trained on, and that unsupervised training can lead to unwanted results if completely unmonitored.

Seek a modular design

Central to managing obsolescence in AI is the adoption of a modular system architecture. Peter stresses the importance of designing AI systems with interchangeable components:

“Businesses that sank money into older models now realise they can be outdated quickly…. Businesses want modular solutions, so they can replace parts without throwing everything away. Data pipeline, predictor module, retraining… Each part can be swapped out – you’re not stuck.”

A modular approach has a few benefits, and it’s emerging as current best-practice in AI. It allows for easier updates and maintenance, but it also diminishes your reliance on a single vendor or proprietary technology.

Comprehensive documentation and standardised application interfaces will also make the seamless integration of newer, more efficient algorithms possible, as they become available.

This is really at the heart of overcoming obsolescence in AI.

Maintain algorithm accuracy with continuous monitoring and retraining

How often should businesses be checking in on their accuracy? Peter recommends continuous, automated self-monitoring.

“Build a self-monitoring system. If accuracy dips, retrain or raise an alert.”

These systems can provide early warnings if accuracy falls below a predetermined threshold. With regular performance evaluations and automated alerts, companies can respond to emerging issues more quickly.

Uphold documentation religiously – and be vigilant of biased data

The secret to easier obsolescence management – in AI or otherwise – is accurate, complete documentation. Without it, you won’t know what material you’re working with, and will likely have to reverse-engineer a system to pick out its various components and diagnose problems.

Documenting training methods (and the data supplied for training) must also be extremely thorough – beyond the normal level of documentation that other forms of software engineering would require.

“You’re almost having to keep documentation of the experiments you run, rather than just the end product.”

So – if we were to ask you right now, could you tell us how accurate your AI algorithm is?

Hopefully, you’ll now see why this question is so important.

With hardware, obsolescence is obvious; chips go out of production, with plenty of prior warning. It’s the same for software, too – libraries are decommissioned, with plenty of warning.

But AI is a black box. it can be totally hidden, masking its obsolescence. If you need to peer into that black box and understand what needs to change, we’re here to help.

Let's work together

At Zircon, we specialise in analysing, updating, and securing obsolete systems.

Our obsolescence management solutions include AI, helping you identify losses in accuracy, and implement self-monitoring systems – as well as giving our partners better documentation and an actionable plan.

We provide ongoing support, too, but we’ll always strive to leave you with a modular system that can be updated and augmented by anyone.
Interested in learning more?

Get in touch – call 01225 764 444, or send your message to enquiries@zirconsoftware.co.uk.

About Dr. Peter Overbury, Head of AI at Zircon Software

Peter’s education and career history are unique, and he’s been deep in the world of AI for at least 10 years. Peter earned his undergraduate degree in neuroscience, and his PhD in the use of genetic algorithms before his career began. Peter knows first-hand the intricate details of ML, and he’s overseen its evolution (quite literally) from the fledgling machine vision systems learning to drive, into the hyper-accurate models and LLMs we have today.

References

More From The Blog

Cyber Resilience Starts With Software Engineering

Cyber Resilience Starts With Software Engineering

What the UK Cyber Security & Resilience Bill and Software Security Code of Practice Mean for Organisations Operating Critical SystemsFor many years, cyber resilience has largely been viewed through the lens of security controls, monitoring, governance and...

Zircon Software Accepted onto Aurora Engineering Partnership

Zircon Software Accepted onto Aurora Engineering Partnership

Zircon Software Accepted onto Aurora Engineering PartnershipZircon Software is excited to announce our selection as a specialist supplier on the Aurora Engineering Partnership, marking a significant milestone in our continued growth and commitment to growing our...

Cybersecurity, obsolescence – and why testing alongside system development is the key to secure infrastructure

Cybersecurity, obsolescence – and why testing alongside system development is the key to secure infrastructure

by | Jan 29, 2025 | Article

Cybersecurity, obsolescence

-and why testing alongside system development is the key to secure infrastructure

In our 2024 paper, The Challenge of Obsolescence in UK Critical Infrastructure, we highlighted an area of growing concern; the intersection of cybersecurity and obsolescence.

The UK’s National Cyber Security Centre (NCSC) wrote that 2023 has seen the addition of state-aligned actors to the ongoing threat from state actors, as a new and emerging cyber threat to Critical National Infrastructure (CNI). While the cyber activity of these groups often focuses on DDoS attacks, website defacements and/or the spread of misinformation, some have stated a desire to achieve a more disruptive and destructive impact against western CNI, including in the UK.  In fact, the UK is the third most targeted country in the world for cyber attacks

The convergence of outdated infrastructure and the rapidly evolving cyber threat landscape presents significant challenges for the UK’s CNI. Recent reports and legislative initiatives highlight the urgent need to modernise these legacy systems and implement comprehensive cybersecurity measures to protect against current and future threats.

But what exactly are the risks? Are lives at stake? And how can cybersecurity be better managed in ageing software systems?

Zircon’s panel of experts explores the key risks associated with cybersecurity and obsolescence in this article, with key insights from our Principal Software Engineer, Matt Endicott – joined by Mark Parsons from our Board of Directors, and Nadia Hutchings, our Marketing Manager.

Why is obsolescence a cybersecurity issue?

Obsolescence is an inevitable byproduct of long-term infrastructure and technology investments.

Systems like railway signalling, ticketing platforms, electronic road signage, and industrial control mechanisms were all designed to last decades – mostly without considering modern cybersecurity threats. This is understandable; the shapeshifting technological landscape means that, while educated predictions can be made, future threats can’t be known in advance.

As, these systems age, they are less likely to receive updates or patches, leaving them exposed to vulnerabilities.

Historically, critical systems were built to operate autonomously and disconnected from wider networks. While this limited external attacks, modern demands for connectivity have introduced new risks.  Key examples being the 2015 Jeep hack, 2016’s Mirai Botnet, 2021’s Verkada Hack and of course the now infamous Stuxnet (an event we cover below).

Mark introduces the risks with interconnected systems that have known (or unknown) vulnerabilities – and why they might be exploited;

“You could easily cause disruption to the UK infrastructure, be it road, rail, nuclear – or whatever industry you’re talking about. It would be fairly easy to take down the power grid… or cause traffic chaos.”

As for motives? Mark adds;

“Financial gain is the most obvious one for non-state actors. Private hacking companies – they’re after cash, of course. But state actors … They would be more after disruption and embarrassment.”

In sectors like energy, defence, road, and rail, connectivity introduces serious cybersecurity vulnerabilities. But exactly how big are the risks?

What are the biggest risks of cybersecurity vulnerabilities in obsolete systems?

The risks associated with outdated systems can impact safety. But the risk to life is actually quite low.

As Nadia explains;

“Trains are designed to fail safely… It’s not like in the movies where someone’s taken control of the train remotely – it’s actually really hard to do that – but you can create chaos without even touching the core systems… you can cause massive disruption to Rail Operators just by stopping people from getting tickets.”

The key risks are financial and operational. Disruption is usually the key goal of cyber attacks, along with ransom – but state-sponsored actors are also a threat.

1. Operational disruption

Hackers targeting critical infrastructure can cause significant delays and inefficiencies. For example, disabling ticketing systems or luggage tracking at an airport can lead to cascading disruptions across the entire network.

As an example, in September 2024, a major cyber attack targeted 20 railway stations across the United Kingdom – disrupting services and highlighting vulnerabilities within the transport network’s digital systems.

This came shortly after a separate attack on TfL, which exposed sensitive consumer data and prompted a wave of attacks in its wake. The incident is ongoing.

2. Ransomware attacks

As famously seen with the NHS cyber attack, an event that cost the NHS approximately £92m, ransomware exploits outdated systems to encrypt critical files, demanding payment to restore access.

3. State-sponsored attacks

Countries may target critical infrastructure in “enemy states”, not for financial gain, but to cause embarrassment, disruption, or chaos. These attacks can provide a political or tactical advantage, be used as a show of strength – or a demonstration of opponents’ weaknesses.

Matt adds;

“…If you want to read about what’s really possible, read about Stuxnet, which was maybe 15 years ago, but that was… A virus that could be installed on controller devices. These are embedded bits of kit… They had a virus that could install on these controllers and report back where it was, where it was being run from…”

Stuxnet was a sophisticated digital weapon, and one of the most prominent cyberwarfare moments in history. It is known to have attacked several nuclear weapons programmes, with varying levels of success –  as well as telecoms systems. Stuxnet highlighted to the world that CNI  networks we all depend on are more vulnerable than we like to think, and arguably could be said to have provided the catalyst for the approaches we have developed to secure these critical infrastructures today.

What about safety risks?

Critical systems are designed to fail safely. They tend to be highly isolated from wider networks, to mitigate risk – and have layered subsystems that prevent catastrophic failure.

While some disruptions can pose indirect safety risks, attacks that target critical safety systems – like the railway’s interlocking system – would require an “inside job” of considerable effort to pull off. And such an effort wouldn’t go unnoticed.

That said, any successful attack would be highly localised, and human intervention at the point of failure would provide an additional layer of security.

Mark adds that to sabotage a safe system would require intricate knowledge of how it works and how it’s configured – as well as direct access to it;

“The best you could hope for is to turn it off… It’ll be very difficult to make them act in a way that will put somebody’s life in danger.”

How often is critical infrastructure targeted?

Cyberattacks on railway systems have increased by 220% in the last five years, with incidents increasing worldwide over the last decade.

Attacks on road infrastructure are rarer – but as Mark explains;

“… If you set all of the signals at a set of traffic lights to red – that’s going to cause chaos.

And if you set them all to green, that will cause chaos. But in both cases, they’re unlikely to cause somebody to do something that’s going to have a serious impact.”

“Because, as I’m sure you’re aware, green does not mean go. It means ‘proceed with caution’, as stated in section 17.3 of the Highway Code…”

Again, human intervention will add another layer to reduce the risk.

In the industrial sector, the UK government’s Cyber security breaches survey 2024 reveals that;

“Half of businesses (50%) and around a third of charities (32%) report having experienced some form of cyber security breach or attack in the last 12 months.”

“This is much higher for medium businesses (70%), large businesses (74%) and high-income charities with £500,000 or more in annual income (66%).”

Attacks are increasing across the board. So – why can’t we just update these systems?

Why are security updates challenging in critical infrastructure?

Updating ageing systems is easier said than done.

Many were not designed with regular updates in mind, and the environments they operate in – like railways or nuclear power stations – pose significant logistical challenges.

Matt says that because of these challenges, many systems have simply been ignored;

“In the past, people just kind of ignored it. There are systems where regular security updates have been considered, but many others didn’t account for it until probably the last five years, and maybe not even that long.”

These overlooked systems now represent a massive risk, as they weren’t designed to handle today’s demands for connectivity.

That being said, some systems are not connected to broader networks at all, making remote updates impossible. These require engineers on-site, to manually install updates – but even this may not be possible due to ageing hardware, unsupported software, and everything else that can arise with legacy systems.

Shutting down infrastructure for updates is also hugely disruptive to operations, and can potentially cost millions. UK railways, for example, have to carefully coordinate any operational downtime to reduce disruption. Highways face a similar issue, although to a lesser extent.

How can industries rise to these challenges – and make sure that critical infrastructure is kept as secure as possible?

The solution combines proactive testing, robust system design, and continuous monitoring.

Addressing the challenge of obsolescence and cybersecurity

1. Developing rigorous testing environments

In software development, testing often gets left to the last minute. Project deadlines overrun, and testing is often what suffers.

Mark says;

“Projects always run late. Testing comes at the end of the project, so it gets squeezed. That’s bad for a million reasons, but the main one is that people don’t spend enough time creating a test environment to properly test the system before deployment.”

For critical systems, it’s absolutely vital to begin testing alongside system development.

This can be achieved by creating test environments; simulated systems where code can be validated against a variety of scenarios, including cyber threats.

An example of where testing failed was the CrowdStrike outage of July 2024, which caused approximately 8.5 million Microsoft Windows operating systems to crash worldwide, leading to global disruption of critical services.

As Mark notes;

“CrowdStrike fell over on one of the most basic errors that you can possibly believe in software engineering… Does it fail properly? In the case of CrowdStrike, that was a zero length file.”

Failure to test adequately is what led to the “largest outage in the history of information technology”. This could have been avoided with a more diligent and rigorous testing procedure, and a robust testing environment running in parallel.

2. Implementing Continuous Integration and Deployment (CI/CD)

CI/CD allows systems to be continuously updated and tested in smaller increments, reducing the risks associated with larger, more infrequent updates. Automated pipelines can identify vulnerabilities as they arise, for faster resolutions without significant downtime.

Matt explains the advantages of CI/CD;

“With modern development techniques like continuous integration, everything is automated. Developers write unit tests, and those tests run automatically whenever code is pushed. It saves time and ensures everything is repeated exactly the same way, every time.”

In CI/CD, software developers build the right unit, integration and system tests to run automatically as soon as code is pushed to repositories. After these automated tests, the system creates releases automatically.

This is far more rigorous than human testing could ever be, and far more efficient. It does take more time to develop initially, with a greater effort required at the start – but after the initial investment, updates are swift, precise, and reliable. As Matt puts it;

“Ten weeks writing some automated tests, then suddenly you can release every two weeks.”

Organisations should invest up front, building that environment once, so that they can continuously update without the traditional risks of downtime and disruption.

As systems approach obsolescence, or evolve into modern technologies, this cycle of continuous integration and deployment can help alleviate backlog – as new items can be bolted on to testing scripts.

3. Retrofitting legacy systems

Even older systems can benefit from modern testing and update mechanisms. Retrofitting may include:

  • Adding automated testing environments to legacy software systems
  • Introducing network connectivity for remote updates
  • Updating documentation to ensure current functionality aligns with system specifications

Documentation is often a big stumbling block with obsolescence management, and sometimes the lack of good documentation requires software to be reverse-engineered, so that it can be properly documented and understood.

Nadia reflects on some past retrofitting challenges;

“We’ve worked with clients where the documentation didn’t match the actual functionality. Some systems were written by one engineer 20 years ago, and now no one knows how they work. Bringing them up to date is a big task, but it’s worth it in the long run.”

Retrofitting, in both hardware and software, needs to be carefully managed, to close any security loopholes that might lead to breaches. Documentation can help this process greatly.

4. Addressing technical debt

Organisations that prioritise ongoing maintenance of software and hardware systems are less likely to fall into “technical debt”. This is where neglected systems become costlier to repair or replace over time, because of a buildup of issues.

In the first instance, tackling technical debt can be intensive and costly – but the benefits include increased resilience to cyber threats, as well as smoother operations.

5. Continued best practice in cybersecurity

Organisations should implement cybersecurity measures across all systems, including regular vulnerability assessments, multi-layered security protocols, and employee training to recognise and mitigate cyber threats.

Cyber attacks are all too often a human and social engineering issue as much as they are a software engineering one, so training should always be up to date.

The UK government offers several resources on standards.

There’s guidance freely available from the National Cyber Security Centre (NCSC), the UK’s cybersecurity authority. The NCSC developed the Cyber Assessment Framework (CAF) for operators of essential services – which is the best place to start.

There’s also GovS 007 – a cybersecurity standard that sets out expectations and reasons for the security activities which organisations need to carry out, to protect government assets specifically.

Next steps for infrastructure and industry

While initial investments in automated testing, CI/CD pipelines, or system retrofits may seem costly, the long-term savings and risk reduction far outweigh these expenses.

Mark highlights the cost-benefit dynamic;

“It’s scary when you see the upfront costs, but in the long run, it’s worth it. The cost isn’t in replacing the equipment – it’s in accessing the infrastructure to replace it.”

Matt says;

“Software doesn’t rust – but the environments it runs in change. If you don’t maintain it, technical debt will catch up with you. It costs more in the long run not to act.”

Cybersecurity and obsolescence present a significant challenge. But it’s not insurmountable.

By addressing the issues facing infrastructure and industry now, we can collectively ensure smoother operations, reduced risks, and greater resilience – in an increasingly connected world.

How can Zircon help?

With our 25 years of expertise in Software and Systems engineering, one area we have come to specialise in is the analysis, update and securing of ageing infrastructure systems.

Our obsolescence management solutions include a thorough system analysis, to identify vulnerabilities and recommend solutions – giving our partners better documentation and an actionable plan.

From there, we oversee the implementation of CI/CD pipelines for continuous updates, and the retrofitting of legacy systems with modern integrations.

And we provide ongoing support, to ensure systems remain secure and compliant.

If you’re interested in learning more, get in touch – call 01225 764 444, or send your message to enquiries@zirconsoftware.co.uk.

More From The Blog

Cyber Resilience Starts With Software Engineering

Cyber Resilience Starts With Software Engineering

What the UK Cyber Security & Resilience Bill and Software Security Code of Practice Mean for Organisations Operating Critical SystemsFor many years, cyber resilience has largely been viewed through the lens of security controls, monitoring, governance and...

Zircon Software Accepted onto Aurora Engineering Partnership

Zircon Software Accepted onto Aurora Engineering Partnership

Zircon Software Accepted onto Aurora Engineering PartnershipZircon Software is excited to announce our selection as a specialist supplier on the Aurora Engineering Partnership, marking a significant milestone in our continued growth and commitment to growing our...