There is a familiar comfort in industrial environments that still keeps critical systems isolated from the outside world. The argument sounds sensible. If the plant is air gapped, exposure is lower. If exposure is lower, updates can wait. If updates can wait, stability wins. That logic has carried many sites for years, but it is becoming harder to defend as open source components sit deeper inside historians, engineering workstations, remote access stacks, vendor appliances, monitoring tools, and the layers around control.

In operational technology, it is clear that outages are often unacceptable, must be planned days or weeks in advance, software changes must be thoroughly tested, and deployed technology often remains in service for 10 to 15 years or longer. It is also important to note that OT frequently relies on older operating systems that may no longer be supported. That is the environment in which the paradox appears. The safest plant is not always the one that updates most often, but it is also not the one that quietly ages into unmanageable software risk.

That is why the phrase secure but stale matters. In plants, stale software is rarely the result of negligence alone. It is often the result of rational operational discipline. The trouble is that rational local decisions can create strategic drift. A component that was acceptable when commissioned can become difficult to patch, harder to support, and poorly understood by the people still operating it years later. This is not a niche problem. It is part of the structural difference between IT and OT.

The wrong objective is patch speed

Many security discussions still assume that the right answer is to push plants closer to enterprise patching cycles. That is usually the wrong lesson. In industrial settings, speed without operability becomes its own risk. Software updates in OT cannot always be implemented on a timely basis, need vendor and end user testing, and may require revalidation with control engineers, security teams, and IT working together. If leaders ignore that and set patch velocity as the headline metric, they will force either unsafe change or quiet non-compliance. Neither outcome is mature.

A better objective is controlled freshness. By that I mean something more realistic than always current and more responsible than indefinitely deferred. Controlled freshness means every open source component has a known origin, a known owner, a known operational purpose, and a known path to replacement or containment. That is a more serious standard for plants because it respects the reality of shutdown windows while refusing blind trust as a long-term operating model.

Also Read: How to navigate the investment opportunity in climate tech sector

Many software supply chain guidance points in exactly this direction. It treats SBOM, vendor risk assessment, open source controls, and vulnerability management as complementary capabilities, not substitutes, and it stresses that open source provenance, integrity, support, and maintenance are often not well understood or easy to discover.

Open source is not the problem, unmanaged open source is

There is no value in pretending plants can avoid open source. They already depend on it, often indirectly. The real issue is that many sites do not know precisely where it sits, which versions are deployed, or whether a vendor appliance that looks closed is in fact carrying a stack of ageing open components underneath.

Organisations should understand suppliers’ use of open source components, acquire those components through secure channels from trustworthy repositories, maintain sanctioned internal repositories, and use hardened internal repositories or sandboxes before introducing components into development environments. It also says that when no vendor-supplied SBOM exists, organisations should perform binary decomposition to generate SBOMs for legacy software where technically and legally feasible.

That changes the leadership question. The issue is no longer whether a plant uses open source. The issue is whether the organisation has operationally useful visibility into that open source estate. In practice, that means knowing which components matter enough to affect production, safety, recovery, vendor support, or incident response. Perfect visibility can wait. Actionable visibility cannot.

The real control layer is the offline intake model

Air-gapped environments need a better software intake discipline than most enterprises because they cannot rely on frequent corrections later. The strongest plants do not treat updates as downloads. They treat them as engineered releases.

The Secure Software Development Framework is helpful here because it is not written only for fast-moving cloud products. It recommends release integrity verification, including cryptographic hashes and code signing, and it says organisations should securely archive each software release together with integrity verification information and provenance data.

It also calls for provenance data to be maintained and updated whenever software components change, and for policies to cover the full life cycle, including notifying users of the impending end of support and end of life. It further recommends maintaining older versions until transitions from those versions have been completed successfully. In a plant context, that is not administrative overhead. It is the basis for being able to trust an offline release years after it was first imported.

Also Read: What big tech won’t show you about the future of AI

This is where many industrial organisations still fall short. They have changed control for plant operations, but not a proper intake pipeline for software artefacts entering the isolated estate. That gap matters. If a site cannot verify what was entered, what dependencies came with it, what integrity checks were performed, and which baseline it replaced, then the air gap is only reducing exposure. It is not creating a trustworthy software discipline.

Compensating controls matter more in OT than most security teams admit

There will always be software that cannot be updated on the timetable security teams would prefer. The mature response is not denial. It is containment.

In OT, it is recommended to do security controls such as antivirus and file integrity checking, where technically feasible, to prevent, deter, detect, and mitigate malware. Patches should be tested on a sandbox system before production deployment, and notes that bump in the wire devices can be installed inline with devices that cannot be updated or are using obsolete operating systems. This is important because it reframes the conversation. When patching is slow, the answer is not to pretend the exposure does not exist. The answer is to tighten the surrounding trust boundary, preserve evidence, and buy time safely.

Vendor discipline is part of plant discipline

A second mistake organisations make is to assume that air gapped constraints excuse weak supplier behaviour. They do not. In fact, they make supplier quality more important. Users should be able to understand which vulnerabilities a patch closes, that the status and applicability of patches should be documented, that asset owners should have a documented list of available and applicable patches, and that hardening should be retained after patching.

SBOM repositories should be digitally signed and accessible, and open source controls should include secure acquisition channels and component visibility. Buyers should prioritise configuration management, logging, data protection, secure by default design, vulnerability handling, and upgrade tooling when selecting OT products.

That combination points to a harder commercial stance. If a supplier cannot explain what open source is inside the product, how upgrades are packaged, how long components are supported, and how integrity is verified offline, then the product is not merely harder to manage. It is strategically expensive to own.

—

Editor’s note: e27 aims to foster thought leadership by publishing views from the community. You can also share your perspective by submitting an article, video, podcast, or infographic.

The post Air gapped open source and the secure but stale paradox appeared first on e27.