When you walk an automation trade show floor, you hear the same word at every booth: Open. Open platform, open architecture, open ecosystem. It has become the default adjective for anything in industrial automation, and that is the problem. When a word describes everything, it tells a buyer almost nothing.

Five questions to ask suppliers

So what does “Open” mean? Openness is not one thing. A supplier can be open on one measure and closed on another. The fastest way past the marketing speak is a short list of concrete questions you can ask the person who is using the term “Open.”

• Can you run third-party software on the device, including software that competes with the supplier’s own, and on whose approval?
• Can you reach the operating system, and what does the supplier document about doing that?
• Can you move your application to another supplier’s hardware later, or are you locked in the moment you build?
• Does the supplier publish a software bill of materials, a vulnerability process and a support end date?
• What does exercising that open access do to your warranty and your certification?

A platform can pass one test and fail the next. A controller can host any container you like and still trap your application when you try to leave. A supplier can publish high-quality APIs and say nothing about what happens to support when someone opens a shell.

Openness is a set of independent measures, not a single dial, and honest suppliers let buyers check each one.

How the definition has shifted

Open Automation 1.0 meant interoperability. Could a controller talk to another supplier's I/O or SCADA without a custom driver? That fight is largely won. Open communication standards like OPC UA and MQTT are now common, and Automation World covered that ground in April with Ken Crawford, senior director of Strategic Automation Solutions.

Open and open source are not the same. Open source describes software whose code users may inspect, modify and redistribute. For our purposes, open describes buyers' freedom to run third-party software and move applications to other hardware.

Open Automation 2.0 means application freedom.

The litmus test is: Can you run someone else's software on the control or edge device itself? Consider a single controller running a PLC runtime from one supplier, a data-logging application from a second and an HMI panel from a third, all at the same time. Those pieces share data through a common protocol rather than through custom glue code.

The payoff is practical: fewer forced purchases, less custom integration and the freedom to pick the best tool for each job.

What openness costs

Openness is a cost a supplier chooses to pay, not a free virtue. Letting a competing application onto a platform means giving up some exclusivity. A buyer should treat every open decision as a tradeoff and ask what the supplier gave up.

For those who continue to push back on a truly open system, security is the objection suppliers hear most often. It’s true: opening a system does add surface area, and it shifts some decisions onto the customer. Openness and security are not opposites, but the tension is real.

However, the relevant standard, ISA/IEC 62443, already accounts for host devices running general-purpose operating systems. What matters is the discipline around it: signed software, segmented networks, role-based access and a working vulnerability process. Governed openness does not mean disabling integrity controls that block unsigned code. It gives customers a documented way to sign and run their own software while preserving those controls.

Serviceability is the part people forget. If a team modifies an open system and it breaks at 2 a.m., who owns the problem? Most suppliers do not answer that in writing. A buyer needs specifics: which modifications void support, which do not, and what it takes to get back to a supported state. Suppliers should publish that position plainly as an industry standard.

Balancing the demands of OT and IT

Open systems land on the seam between OT and IT. IT teams expect containers, fleet management and observability. OT teams need deterministic timing, safety certification and change control that resists casual edits. Both are right, and the requirements can genuinely conflict. An open platform does not erase that tension. It gives each side room to work on the same hardware.

How industries balance those demands helps explain their uneven progress. The process industries have done the most visible standards work through NAMUR and The Open Group's Open Process Automation Forum, though deployment at scale is still catching up. Discrete manufacturing and OEM machine builders often move faster in practice, because the payback on flexible, multi-supplier systems shows up quickly. Look at what is actually running in plants, not only at what is being specified in committees.

Give open a stress test

The next standard of openness is already being shaped by regulation as much as by technology. The EU Cyber Resilience Act turns vulnerability handling, security documentation and a stated support period into a baseline for anything sold into that market. Reporting obligations land first, with full requirements following in 2027. Once that floor is in place, security disclosure stops being a differentiator and becomes the price of entry.

The suppliers who win on openness will not be the ones who say the word most often. They will be the ones who let a buyer verify it, in an afternoon, on the bench. So, the next time a datasheet says open, put your supplier to the test.