Introduction

Industrial environments depend heavily on software and firmware supplied by third parties. OT software supply chain security is therefore an essential part of protecting industrial operations, where controllers require firmware updates, engineering workstations rely on vendor tools, and operational servers depend on software packages, drivers, libraries, and supporting applications.

Normally, these components are trusted because they come from an approved supplier. However, that trust creates an important cybersecurity question:

What happens when a legitimate-looking update introduces something the organisation did not expect?

The risk does not necessarily begin with an attacker directly targeting a PLC. A compromised software package, altered firmware image, manipulated update mechanism, or vulnerable third-party component can introduce risk through a process that operators already consider legitimate.

MITRE ATT&CK for ICS specifically recognises Supply Chain Compromise as a technique in which infected products, software, or delivery mechanisms can be used to gain access to control-system environments. It also notes that legitimate software and patches can be replaced or manipulated before reaching the end user.

The challenge is therefore not only deciding whether an update came from a trusted source, but also understanding what changed, which operational assets were affected, and whether behaviour changed after the update was introduced.

When a Trusted Update Becomes a Security Question

Most software and firmware updates are legitimate and necessary. They fix vulnerabilities, improve reliability, add functionality, and help vendors maintain systems throughout their operational lifetime. However, an approved update can still introduce unexpected risk if the package has been altered, contains a vulnerable component, or causes behaviour that was not present before the change.

Consider a production engineering workstation that receives an approved vendor update. The installation completes successfully, the expected version appears, and the system restarts normally. Shortly afterwards, however, the workstation begins communicating with a network destination it has never contacted before.

Neither event automatically proves malicious activity. The update may be legitimate, and the new connection may have a valid technical explanation. The combination of the two is what gives the security team a reason to investigate, particularly when the asset supports production or has access to sensitive industrial systems.

The useful question is therefore not simply:

Was the update successfully installed?

It is:

What changed after the update?

From Software Change to Operational Risk

1. Know What Changed

Before security teams can identify unexpected behaviour, they need visibility into the asset itself. Knowing that “an update happened” is not enough if the organisation cannot identify which system changed, what version was installed, or how important that system is to production.

For a production system, useful context includes the software or firmware version, previous version, asset role, criticality, vulnerabilities, and whether the change occurred during an approved maintenance window.

For example:

This context matters because the same software change can have very different consequences depending on where it occurs. An update on a testing workstation is not equivalent to a change affecting an engineering system connected to an active production environment.

The more operationally important the asset is, the more valuable it becomes to understand what changed before, during, and after the update.

2. Connect the Change with Identity and Timing

Software changes normally happen for a reason and are usually associated with a maintenance activity, administrator, vendor process, or automated management system. Connecting the change to that context helps distinguish expected maintenance from activity that requires further investigation.

An authorised engineer installing an update during a scheduled maintenance period may be expected. However, the same installation occurring outside that window, from an unfamiliar administrative account, deserves additional attention.

The investigation should therefore connect the change with questions such as who performed it, when it happened, where the activity originated, and whether it matched the normal maintenance process.

This turns a simple event such as:

Software updated on ENG-WS-04

into something more meaningful:

A production engineering workstation changed outside its expected maintenance context using an unusual administrative account.

That does not automatically mean the system has been compromised, but it provides much stronger context for deciding whether the event should be investigated.

3. Monitor What Happens Afterwards

The strongest security signal may appear after the update rather than during installation.

A system might return to service normally and then begin communicating with unfamiliar destinations, launching new processes, generating unusual authentication events, or interacting differently with other operational systems. In other cases, the first sign may be subtle: a new connection, an unexpected service, or communication with a device that the asset did not previously contact.

A useful sequence could look like:

Instead, security teams should be able to recognise when behaviour after a trusted change no longer matches what was expected, particularly when several unusual events appear around the same asset and time period.

Example: Post-Update Activity Timeline

The objective is not to treat every update as suspicious. Industrial environments require regular maintenance, and legitimate changes can naturally alter system behaviour.

The important signal is not the update itself, but the sequence of events that follows it.

A legitimate software installation becomes more relevant to security monitoring when it is followed by activity that does not match the asset’s normal operational role.

4. Prioritise According to Operational Impact

Not every unexpected change deserves the same level of urgency.

A software change affecting a low-impact test system may be important, but the same event on a production-critical SCADA server, engineering workstation, historian, or system with access to controllers could have significantly greater consequences.

Prioritisation should therefore consider the importance of the asset, the type of change, existing vulnerabilities, exposure, production dependencies, and any unusual activity observed afterwards.

A simple way to think about it is:

Update Risk = Asset Criticality × Change Context × Exposure × Unexpected Behaviour

The goal is not to create another complicated scoring system. It is to help security teams focus first on changes that could have the greatest impact on operations, rather than treating every software event with the same priority.

High-Value Detection Scenarios

Unexpected Software or Firmware Change

A version change outside an approved maintenance period should be investigated, particularly when it affects production-supporting infrastructure.

The SOC should determine whether the change was authorised, who performed it, which version was introduced, and whether unusual activity appeared afterwards. If the change is accompanied by unexpected authentication, new processes, or unusual network communication, the investigation becomes more significant.

Firmware Downgrade

A system unexpectedly returning to an older firmware version may be the result of legitimate troubleshooting or rollback activity. However, the older version may also reintroduce vulnerabilities that had previously been addressed or remove security improvements introduced by a newer release.

The important question is therefore whether the downgrade was expected, who authorised it, and whether the resulting version changes the asset’s security exposure.

New Communication After an Update

An asset beginning to communicate with a previously unseen destination shortly after a software or firmware change creates a useful correlation point.

Neither event necessarily indicates compromise on its own. However, when a new communication path appears immediately after a change—particularly on a production-critical asset—the timing gives analysts a stronger reason to validate both the update and the resulting behaviour.

Multiple Assets Change Unexpectedly

One unexpected update may indicate a local configuration issue or maintenance mistake.

The same software or firmware change appearing across several production systems without an approved deployment may indicate a broader incident. In that situation, security teams should determine whether the systems share the same update source, administrator, management platform, or vendor process.

Connecting Software Changes to OT Security Incidents

A software or firmware change does not necessarily indicate a security incident. However, when that change is followed by unexpected authentication activity, unfamiliar network connections, or unusual interactions with industrial equipment, security teams need to understand whether the events are related.

The Logstail Security Suite provides a security-operations foundation for collecting and correlating available logs, asset information, vulnerability data, and security events. Where the necessary telemetry and integrations are available, analysts can connect an observed software change with the affected asset, its operational importance, associated identities, and subsequent activity.

AICOT — AI-Driven Cyber Defense Platform for Operational Technology Environments in Critical Infrastructure — aims to extend this foundation with machine learning, anomaly detection, OT protocol analysis, and AI-assisted threat detection tailored to industrial environments.

Returning to the engineering workstation scenario that receives an approved vendor update and subsequently begins communicating with a PLC it has never contacted before. Traditional security monitoring can help establish when the change occurred, which systems were involved, and whether related security events appeared. The OT-specific behavioural analysis targeted by AICOT could provide additional insight into whether the new communication pattern differs from established industrial behaviour.

This does not mean that every deviation represents an attack. Legitimate updates may introduce new functionality or communication patterns. The objective is to combine security-event correlation with OT-specific context so that analysts can identify changes requiring further validation.

Any response that could affect production availability or equipment safety should remain coordinated with the responsible OT personnel.

The result is a more informed investigation: one that considers not only whether a software update was authorised, but also whether the affected system continues to behave as expected within its industrial environment.

Conclusion

Industrial organisations depend on software and firmware supplied by third parties, and regular updates are essential for maintaining secure and reliable operations. However, even an authorised update can introduce unexpected security or operational risks.

Trusted software should not mean invisible change.

By connecting software changes with asset criticality, maintenance context, vulnerability information, and subsequent security events, organisations can better identify activity that requires investigation.

The Logstail Security Suite provides a foundation for monitoring, correlation, and security investigations, while the AICOT project aims to extend these capabilities with OT-specific behavioural analysis, industrial protocol visibility, and AI-driven threat detection.

The objective is not to treat every update as suspicious, but to understand whether the systems supporting critical operations continue to behave as expected after a change.

Led by Logstail, the project builds on expertise in SIEM, data analytics, and security operations while extending these capabilities to the specific requirements and constraints of OT environments.

Follow the AICOT project on LinkedIn and X for project updates and practical insights into AI-driven OT cybersecurity.

AICOT is funded by the European Union’s Digital Europe Programme under Grant Agreement No. 101249826. Views expressed are those of the authors and do not necessarily represent the European Union or the European Cybersecurity Competence Centre.

Contact Our Experts  or Sign Up for Free