Obsolescence | 26 October 2026

Following a cyber incident affecting an industrial control system, one of the most difficult recovery decisions is establishing which software and configuration can be trusted. Without that information, even a well-rehearsed recovery plan can stall.

For operators in oil and gas, utilities, renewables and other industrial sectors, working that out is harder than it sounds. Control systems often run for decades. They are modified along the way, several software versions can end up in circulation, and some dependencies may never make it into the documentation.

The UK's National Cyber Security Centre (NCSC) has recently published guidance called Preparing for a highly disruptive cyber incident. It emphasises the importance of preparing for recovery before an incident occurs, covering business continuity, people, technical recovery and critical decision-making.

For anyone responsible for industrial control systems, the recommendations on asset information, backups and restoring systems to a known good state matter most.

Recovery starts with knowing what you're restoring

Consider a cyber incident affecting the control systems on an offshore installation or industrial processing plant.

The immediate priority is to contain the incident and establish which systems have been affected. Once the threat has been addressed, engineering and operations teams need to determine how to restore the affected equipment and return the process to a safe operating condition.

Having backups available does not necessarily make that straightforward.

Which software version was running before the incident? Has the configuration changed since the last backup? Were those changes approved and tested? Are the installation files and dependencies still available?

If the answers are spread across engineering workstations, shared folders, maintenance records and the knowledge of individual engineers, establishing a reliable starting point takes time.

For critical infrastructure operators, that uncertainty has consequences. Extended downtime can affect production, revenue and service delivery. Restoring an incorrect configuration could also introduce operational or safety risks.

What restoring to a known good state involves

Section 3.6 of the NCSC guidance deals directly with OT. It advises organisations to ensure systems can be safely managed, recovered and restored, with a full understanding of operational and regulatory impacts. This includes identifying where manual intervention may be needed, testing restoration to a known good state and aligning IT and OT recovery plans where systems are interconnected.

A known good state is not necessarily the most recent backup. That backup might predate an authorised modification, contain an unresolved issue or no longer match the equipment installed on site.

Engineers need to establish the appropriate restoration point through technical assessment and validation, using trusted software and configuration records alongside established engineering and operational procedures.

Configuration management provides the information needed to support that assessment: a controlled record of software versions, approved configurations and changes made throughout an asset's operational life.

With accurate, accessible records, recovery teams have a stronger basis for identifying the appropriate restoration point and checking that the recovered system matches the intended configuration.

Why configuration backups and change histories matter

The NCSC's technical recovery section asks organisations to store network and asset information securely, maintain tested backups, plan and test restoration, and document infrastructure dependencies. Its list of what backups should be able to restore includes configuration, alongside data, applications and identity systems.

In OT environments, that detail matters because the information needed to rebuild a system can be highly specific. A controller may depend on a particular application version, firmware revision, hardware arrangement and set of configuration parameters. A backup of the application alone may not be enough to restore its operation.

Reliable recovery means knowing which software and configuration files belong to each asset, whether the backups are current and trustworthy, and what has changed since they were taken.

Change history is where many organisations can be exposed.

Consider a control system modified during a planned maintenance shutdown. The change is approved and implemented successfully, but the configuration backup is not updated. Months later, the system needs to be restored, and the available backup no longer reflects its approved operating state.

Without a clear record of the modification, engineers must investigate the difference while the system is unavailable.

Controlled versions and a clear engineering change management process reduce much of that uncertainty. They also help establish why a configuration changed, who approved it and which version should be considered during recovery.

This exposes an important weakness in recovery planning. A restoration procedure may have been tested successfully, but if configuration records and backups have not kept pace with subsequent plant modifications, the original restoration point may no longer be appropriate.

Recovery readiness therefore needs to be maintained throughout an asset's operational life, particularly following modifications, upgrades and maintenance activities.

The NCSC also recommends protecting backups from unauthorised modification or deletion, making them immutable where possible, storing them separately from primary systems and testing them regularly, including through third-party audits.

A backup that exists is not necessarily one that can be trusted or successfully restored.

There is also the question of when the backup was taken. A configuration saved after a compromise may contain unauthorised changes, making it unsuitable for restoration. Recovery teams need a way to verify backup integrity and compare the proposed restoration point against an approved baseline, reducing the risk of reintroducing the problem.

The added challenge of ageing OT systems

Recovery becomes more complicated when equipment has been operating for many years.

Industrial control systems often remain in service long beyond the typical lifecycle of enterprise IT equipment. While they may continue to perform reliably, their software, firmware and supporting hardware can become obsolete.

An organisation might have a valid configuration backup but discover that the software required to restore it is no longer supported. A replacement engineering workstation may be incompatible with an older application, or the original hardware may be difficult to obtain.

Finding suitable alternatives and assessing whether they can be implemented safely is challenging during an unplanned outage.

This is why software obsolescence management belongs in recovery planning.

Understanding which systems rely on unsupported software, where replacement components may be difficult to obtain and which assets carry the greatest operational risk allows organisations to address potential recovery obstacles in advance.

It also supports more informed decisions about maintenance, upgrades and the continued operation of ageing equipment.

Software is rarely the whole story. Licence keys, access credentials and the procedures for retrieving them securely, vendor support contracts and spare parts can all hold up a restore if they are not recorded and to hand.

Recovery depends on understanding system dependencies

Restoring an individual controller may be only one part of returning an industrial process to operation.

That controller could depend on communication networks, supervisory systems, engineering applications or other equipment that must also be available and functioning correctly.

The NCSC highlights the importance of documenting infrastructure dependencies and understanding the sequence in which systems need to be restarted.

In an OT environment, that information must be considered alongside the operational requirements of the plant.

Re-establishing communications to a control system may be technically possible, but bringing the connected equipment back into service can still require further checks, manual intervention and authorisation from operations personnel.

Restoring the correct software and configuration is only one stage of recovery. Depending on the system, engineers may also need to verify I/O, alarms, interlocks and communications with connected equipment before the process can safely restart.

These checks need to be planned alongside technical restoration, particularly where safety-critical systems are involved.

Safety instrumented systems need particular care. Restoring a previous configuration may itself be a change that calls for management of change and safety validation before the system returns to service, so those requirements belong in the recovery plan.

Accurate asset and configuration records help engineering teams understand the systems involved. Restoration still requires coordination between engineering, operations, OT security and incident response specialists, supported by established procedures that have been tested in advance.

Could you restore a critical OT system today?

A practical way to apply the NCSC guidance is to select one critical OT system and assess its recovery readiness against six questions:

• Can you identify the latest approved software and configuration backups, and confirm that they are trustworthy?
• Can you establish which configuration was running before an incident and trace subsequent changes?
• Do you have the software, hardware information and dependencies needed to rebuild the system?
• Are there obsolete or unsupported components that could delay restoration?
• Has restoration been tested, including the checks required before returning the system to operation?
• Do you know which systems would be restored first, who would carry out the restore, how long it would take, and whether it relies on any one person?

There is a difference between confirming that recovery information exists and demonstrating that it works.

A controlled restoration test can reveal missing software dependencies, incompatible hardware, incomplete configuration records or undocumented steps that might otherwise only become apparent during an outage. Where dedicated test systems are unavailable, organisations may be able to use spare hardware, vendor test facilities or virtual and emulated environments. Certain restoration activities may also be tested during planned maintenance windows, subject to appropriate risk assessment, change control and operational approval.

The exercise should also consider whether the relevant information would remain accessible if normal networks, engineering workstations or shared storage systems were unavailable.

The NCSC recommends keeping asset information and recovery documentation securely stored and separate from production systems to support access during a disruptive incident.

When time is limited and an incorrect decision could have serious consequences, recovery teams need reliable information available to support their decisions.

Making configuration management part of OT resilience

The NCSC's guidance is a reminder that cyber recovery is practical work.

For industrial organisations, that includes understanding the systems they operate, maintaining trusted software and configuration records, managing changes and identifying potential obstacles to restoration.

Asset Guardian supports this work by bringing OT asset information, software and configuration records, change history and obsolescence information into one controlled environment.

For example, Stena Drilling uses Asset Guardian to manage control system software and configuration backups across its offshore fleet. Regular audits verify that stored software versions match those running on board, so discrepancies are caught early.

Effective recovery also depends on incident response, business continuity planning, technical testing and safe operational procedures. Configuration management supplies the records those activities depend on.

How confident are you in your OT recovery readiness?

Explore how Asset Guardian helps organisations manage critical OT software, configurations and changes to support operational resilience.

See how Asset Guardian works