Ahmet Ö.
Corporate
- Thread Author
- #1
Modern software runs on products and systems released ten, twenty, or even thirty years ago. Making this situation even more complex is the fact that many industrial organizations lack sufficient visibility into what's inside their systems. This is not good! We explore these challenges and solutions for running new software on legacy assets with Matt Wyckhouse, CEO of Finite State.
🔍 Are Industrial Organizations Still in the Dark?
Yes! Many industrial organizations can identify physical assets connected to the operational technology (OT) network, but visibility often stops at the device boundary. An asset inventory can tell an operator what the device is and where it is on the network. But that same record often cannot show the full firmware composition, what software that composition includes, or whether a newly disclosed vulnerability applies to that configuration.
This blind spot is significant because much of the risk lives below the network layer. Industrial organizations have made real progress in discovering physical assets and monitoring network traffic, but most still lack a validated view of the software running inside those assets. Without this view, every new vulnerability disclosure becomes a lengthy investigation across products, versions, and sites.
🤔 Why Is This the Case?
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 vendor software development kits and other pre-compiled code. Manufacturers often receive some of these elements as binaries without the underlying source code.
Traditional application security tools work best when source repositories and package manifests accurately declare software dependencies. Firmware often breaks this assumption, so useful source-based findings can still miss components that went into the finished binary.
Over a long deployment lifetime, the original software record can lose accuracy. A vendor may backport a security fix without changing the version number, while later product variants may outlive the engineers who understood the initial composition.
💡 Does Digitalization Solve This Problem?
Digitalization has created some risks, but it also offers organizations better ways to manage risk. As factory floor systems connect to enterprise and cloud environments outside the factory, remote access creates additional avenues into operations. Software-defined functionality also brings more frequent updates, giving more opportunities for product configurations to drift.
At the same time, modern engineering workflows can maintain a much stronger security record. Each product release can link the 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 this digital record to the finished product. Documentation describes what a device should contain. Direct firmware analysis shows what the shipped device actually contains. Keeping these two views aligned throughout the product lifecycle makes digitalization part of the security solution rather than another source of uncertainty.
⏳ 30-Year-Old Assets: Software Lifecycle and Security
Industrial equipment and embedded software will age at very different rates. While a controller or pump may operate reliably for decades, the software stack inside it will reach end-of-support much earlier. Researchers may continue to discover vulnerabilities in the operating system, cryptographic libraries, or vendor code long after the equipment has entered service.
Operational reliability can mask a growing security problem: while the asset remains stable in production, new research changes the risk profile of the software inside it.
Updating industrial equipment also has real operational consequences. A firmware change may require a planned outage or physical access. Before deployment, teams may need to coordinate with a vendor, validate the security, and test the change against a specific production configuration. In some environments, immediately applying an update may create more operational risk than managing a well-understood vulnerability with 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 version deployed, the software record needs to stay current as new vulnerabilities emerge. Reachability analysis can help determine whether an affected function can actually be executed in that particular composition.
Regulations like 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 rationale behind each risk decision, must stay current as products and threats evolve.
📊 Case Study: Manufacturer Reduces Vulnerability Noise
In a recent Finite State case study, a global manufacturer using five different SBOM generators spent weeks manually reconciling data for each compliance audit. Disconnected reports lacked critical product context, leaving evidence scattered across different teams.
By centralizing software records, normalizing SBOM data, and adding context for reachability and exploitability, the manufacturer reduced vulnerability noise by 95% and shortened compliance preparation time by 90%. Work that previously took weeks was completed in days.
The lesson here is that manufacturers need a reliable, continuously updated view of the software inside their products. When teams can quickly understand what components are present, which vulnerabilities truly matter, who owns the fix, and the evidence behind each decision, security becomes a repeatable process, not a recurring fire drill.
🔗 Challenges of Securing Long-Lived Connected Systems
Securing long-lived connected systems is challenging because operational constraints and ownership boundaries remain in place while software continues to age.
A scanner may flag a vulnerable component, but the finding alone doesn't answer the most important questions: Is this component present in this specific firmware composition? Is the vulnerable functionality reachable? Does the fix require a disruptive update to a critical production system?
The context needed to answer these 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 the field configurations. The operator understands what taking the asset offline would mean for production. No single organization has the full 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, composition-specific visibility, teams are forced to repeat the same analysis.
