Modern software is now running inside products and systems that were originally deployed 10 or 20 or 30 years ago. Compounding this situation is that many industrial organizations lack visibility into what's actually inside their systems. Not good. Here we connect with Matt Wyckhouse, CEO of Finite State, to explore the challenges and fixes related to new software running on old assets. 

AW: Do industrial organizations still lack visibility into their products and systems?

MW: Yes. Many industrial organizations can identify the physical assets connected to an operational technology (OT) network, but visibility often stops at the device boundary.

An asset inventory may tell an operator what a device is and where it sits on the network. The same record usually cannot show the exact firmware build, what software that build contains, or whether a newly disclosed vulnerability applies to that configuration.

That blind spot matters because a lot of risk lives below the network layer. Industrial organizations have made real progress in discovering physical assets and monitoring network traffic, but many still lack a verified view of the software operating inside those assets. Without that view, every new vulnerability disclosure becomes a lengthy investigation across products, versions and sites.

AW: Why is this the case?

MW: Industrial products are difficult to inspect because compiled firmware looks very different from a typical enterprise application.

A single firmware image may combine an operating system and its drivers with supplier software-development kits and other precompiled code. Manufacturers often receive some of those elements as binaries without the underlying source code.

Plant operators usually have even less visibility into the software embedded in equipment already running in production.

Traditional application-security tools work best when source repositories and package manifests accurately declare the software dependencies. Firmware often breaks that assumption, so useful source-based results can still miss components that ended up in the finished binary.

Over a long deployment, the original software record can lose fidelity. A supplier may backport a security fix without changing the version number, while later product variants can outlive the engineers who understood the first build.

Years later, the software history is split across the supply chain. A supplier documents the components it delivered, the manufacturer tracks the finished build, and the integrator or operator may be the only party that knows which configuration remains in service. Those views rarely stay aligned, leaving few organizations able to say exactly what every deployed product contains.

AW: Is digitalization now helping this problem?

MW: Digitalization created some of the exposure, but it also gives organizations better ways to manage the risk.

As plant-floor systems connect beyond the factory to enterprise and cloud environments, remote access creates additional paths into operations. Software-defined functionality also brings more frequent updates, giving product configurations more opportunities to drift.

At the same time, modern engineering workflows can preserve a much stronger security record. Each product release can connect its firmware and Software Bill of Materials (SBOM) to vulnerability findings and deployment status. Operators can then see which versions remain active across different sites.

The real value comes from comparing that digital record with the finished product. Documentation describes what a device should contain. Direct firmware analysis shows what the shipped device actually contains. Keeping those two views aligned throughout the product lifecycle makes digitalization part of the security solution rather than another source of uncertainty.

AW: Assets may stay deployed for 30 years. What are the ramifications for software life, updates, vulnerabilities, compliance and related issues?

MW: Industrial equipment and embedded software will age at very different rates. A controller or pump may perform reliably for decades, while the software stack inside it reaches end of support much sooner. Researchers may continue to uncover vulnerabilities in the operating system, cryptographic libraries, or supplier code long after the equipment enters service.

Operational reliability can mask a growing security problem: the asset remains stable in production while new research changes the risk profile of the software inside it.

Updating industrial equipment also carries real operational consequences. A firmware change may require a planned outage or physical access. Before deployment, teams may also need to coordinate with a supplier, validate safety, and test the change against a specific production configuration. In some environments, applying an update immediately can create more operational risk than managing a well-understood vulnerability through segmentation, access controls, or another compensating measure.

Security teams need to maintain the software record for as long as the asset remains in service. For every deployed version, the software record must stay current as new vulnerabilities emerge. Reachability analysis can then help determine whether an affected function can actually execute in that particular build.

Get your subscription to Automation World's tri-weekly newsletter.

Regulations such as the European Union Cyber Resilience Act (CRA) are increasing the urgency. Manufacturers cannot wait for an audit and then reconstruct years of software evidence. The software record, along with the reasoning behind each risk decision, has to remain current as products and threats evolve.

AW: Can you reference an example or case study?

MW: In a recent Finite State case study, a global manufacturer using five different SBOM generators spent weeks manually reconciling data for every compliance audit. Disconnected reports lacked critical product context, leaving evidence scattered across disparate teams.

By centralizing software records, normalizing SBOM data, and adding reachability and exploitability context, the manufacturer reduced vulnerability noise by 95% and cut compliance preparation time by 90%. Work that previously took weeks moved to a matter of days.

The lesson here is that manufacturers need a trusted, continuously updated view of the software inside their products. When teams can quickly understand what components exist,  which vulnerabilities actually matter, who owns remediation, and the evidence behind each decision, security becomes a repeatable process rather than a recurring fire drill.

AW: What are the challenges with securing long-lived connected systems?

MW: Long-lived connected systems are difficult to secure because the software keeps aging while operational constraints and ownership boundaries remain in place.

A scanner may flag a vulnerable component, but the finding alone does not answer the questions that matter most: Is that component present in this specific firmware build? Is the vulnerable functionality reachable? Does remediation require a disruptive update to a critical production system?

The context needed to answer those questions is often spread across the supply chain. A component supplier sees the library it provided. The manufacturer understands the finished firmware. The integrator controls field configurations. The operator understands what taking the asset offline would mean for production. No single organization has the whole technical and operational picture.

Product variation adds another layer of complexity. A risk decision made for one firmware version may not apply to a later build or a customer-specific configuration. Without continuous, build-specific visibility, teams are forced to repeat the same analysis every time a new vulnerability emerges.

Point-in-time assessments simply do not fit systems expected to operate for decades. Security needs to become an ongoing part of industrial lifecycle management.

AW: So we've discussed the challenges. What are the opportunities in addressing this problem?

MW: The challenge of industrial software visibility has become a solvable engineering problem. Direct firmware analysis can reveal the components in each build, making it possible to map a newly disclosed vulnerability across an entire product portfolio. Reachability analysis can then distinguish between vulnerable code that happens to be present in a binary and vulnerable functionality that the product can actually execute. That context gives engineers a clear, evidence-backed basis for deciding what needs immediate action.

AI and automation are most useful when applied to repetitive work that consumes expert time. For example, automation can connect component data to new vulnerability intelligence, carry that context into triage, and keep the resulting evidence organized for compliance.

But AI is only as effective as the information it works with. It does not replace the underlying analysis or the engineers making high-consequence decisions. The most valuable role for AI is helping security teams move faster while preserving human judgment where safety, reliability and business impact are involved.

The larger opportunity is to replace periodic assessments and emergency spreadsheets with a continuous, reviewable process. At any point in an asset’s life, an organization should be able to verify what software is running, which risks matter in that specific configuration, and what evidence supports the remediation decision.

When that information stays current, product security becomes a manageable part of industrial lifecycle management instead of another fire drill.