The layer everyone forgets

When manufacturers talk about data sovereignty, they usually mean production data: OEE dashboards, quality records, historian tags sent to a cloud analytics vendor. That conversation matters. But it skips the most valuable data on the factory floor — the control logic itself.

The ladder logic, function blocks, recipes, setpoints and safety interlocks inside a PLC encode decades of process know-how. They decide how a line runs, how a batch is made and when a machine is allowed to stop. Yet in most plants this data has no clear owner, no version history anyone trusts and no protection beyond the network it happens to sit on.

This post argues that control-logic data deserves to be treated as a sovereign asset: owned, located, governed and defended by the plant that depends on it.

Control logic is the plant's crown jewel

Control-logic data is everything that tells equipment what to do, as opposed to what equipment reports back. In practice it includes:

·       Program code — ladder logic, structured text and function blocks running on PLCs and software PLCs.

·       Configuration — I/O maps, network settings, drive parameters and controller firmware versions.

·       Recipes and setpoints — the values that turn a generic machine into a specific product.

·       Safety logic — interlocks and emergency-shutdown sequences in safety instrumented systems (SIS).

Production data describes the past. Control logic determines the future behavior of physical equipment. If a historian leaks, a competitor learns something. If control logic is altered, product is ruined, equipment is damaged or people are hurt.

NIST's guide to operational technology security makes the same distinction. It stresses that OT systems directly affect the physical world, so integrity and availability often outrank confidentiality (Stouffer et al., 2023). Control logic is where integrity matters most.

The problem is structural. Logic often lives in three places at once: the controller, an engineering laptop and a file share. Integrators hold copies from commissioning. OEMs keep their own versions. When the original engineer leaves, the plant may no longer know which version is running — or who else holds one.

Attackers already know where the value is

The most serious industrial attacks of the past fifteen years share one trait: they went after control logic, not just computers.

Incidents

What happened to the logic

2025

KAMACITE (Dragos)

Adversaries systematically mapped control loops across U.S. infrastructure

2022

PIPEDREAM / INCONTROLLER

Tools could upload malicious code to, and back up or restore, Schneider and OMRON PLCs

2017

TRITON / TRISIS

Malicious logic appended to Triconex safety controller program memory

2010

Stuxnet

Modified Siemens PLC code while showing operators normal values

Ralph Langner's analysis of Stuxnet showed that the weapon was the PLC payload itself. The malware rewrote controller code to damage centrifuges, while replaying normal values to operators (Langner, 2013).

TRITON went further. Mandiant researchers found that the attackers reverse-engineered the proprietary TriStation protocol and appended malicious logic to the program memory of a safety system. The attack was discovered only because the controllers failed safe and shut the process down (Johnson et al., 2017).

In 2022, a joint advisory from DOE, CISA, NSA and FBI described PIPEDREAM-era tools that could upload malicious configuration or code to targeted PLCs and back up or restore their contents (CISA et al., 2022). MITRE ATT&CK for ICS catalogs these moves as standard techniques: Program Upload for theft and Program Download for tampering (MITRE, n.d.).

The trend is accelerating. Dragos's 2026 Year in Review reports that 119 ransomware groups targeted industrial organizations in 2025, up from 80 in 2024. It also found adversaries mapping control loops across U.S. infrastructure. As Robert M. Lee put it, "Adversaries are mapping how control systems work, understanding where commands originate" (Dragos, 2026).

Each of these cases treats control logic as the target. Few plants treat it as the asset.

Sovereignty means knowing who holds the keys

Data sovereignty is usually framed as geography: which country, which cloud region. On the factory floor it is more practical. It comes down to four questions about every piece of control logic:

1.       Ownership — Does the plant hold the rights to the code, or does an integrator or OEM?

2.       Location — Where do the authoritative copies live, and does any of them leave the site?

3.       Access — Who can read it, who can change it, and how is that proven?

4.       Continuity — If a vendor disappears, raises prices or ends support, does the logic keep running?

Three trends make these questions urgent.

Cloud dependency is creeping down the stack. Remote engineering tools, vendor-hosted update services and cloud-managed edge devices all create paths by which logic, or the ability to change it, leaves the plant. Convenience is real, but so is the dependency.

Vendor lock-in reaches the controller. When software is tied to proprietary hardware, the logic effectively belongs to the platform. Migrating means rewriting, which is why many plants run end-of-life controllers long past their support dates.

Regulation is catching up. The EU Data Act became applicable on 12 September 2025. It gives businesses the right to access data produced by their use of "smart objects, machines and devices" and to share it with third parties (European Commission, 2025). The Act focuses on generated data, not program code. But it signals a clear principle: the operator of a machine should not have to ask permission to use what that machine produces. The same logic applies even more strongly to the instructions that run it.

Standards point the same way. IEC 62443 organizes industrial security around zones, conduits and defined responsibilities between asset owners, integrators and product suppliers (IEC, 2013). Sovereignty over control logic is, in effect, making those responsibilities explicit.

What protecting control logic looks like

None of this requires ripping out working equipment. It requires treating logic the way software teams treat source code, with the constraints of a plant that cannot stop.

·       Inventory and version everything. Keep every controller program, recipe and configuration in a version-controlled repository that works offline. Know which version is running on which device, and detect drift.

·       Control who can change logic. Use identity-based access with mutual authentication instead of shared passwords and flat networks. The Mandiant TRITON report recommends keeping safety controllers out of program mode except during maintenance, with change management around that switch (Johnson et al., 2017).

·       Close inbound paths. Remote access should not mean open ports. Outbound-only, authenticated connections shrink the attack surface that tools like PIPEDREAM rely on.

·       Segment around what already runs. NIST and IEC 62443 both recommend zones and conduits that isolate critical controllers from IT networks (Stouffer et al., 2023; IEC, 2013). Brownfield equipment can be wrapped in a protected segment without changing its logic.

·       Keep the authoritative copy on site. Air-gapped or on-premises deployment should be a full option, not a degraded mode. The plant should be able to run, change and recover logic with no internet link.

·       Secure ownership in the contract. Require that code written for you is assigned to you, that software already deployed keeps running if a subscription lapses, and that source escrow protects you from a vendor's failure.

·       Build visibility. Dragos reports that organizations with comprehensive OT visibility contained ransomware incidents in about 5 days, compared with a 42-day industry average (Dragos, 2026). You cannot protect logic you cannot see being read or written.

Assante and Lee's ICS Cyber Kill Chain explains why these controls matter. A real process attack needs a second stage: the adversary must learn the process and develop a capability against it (Assante & Lee, 2015). Protecting control logic is how you deny them that stage.

Conclusion

The industry has spent a decade debating who owns production data. Meanwhile, the data that actually runs the plant sits on laptops, in integrator archives and behind vendor platforms, protected mostly by hope.

Attackers have shown, from Stuxnet to KAMACITE, that they understand what control logic is worth. Plants need to catch up. Sovereignty on the factory floor starts with a simple commitment: the logic that makes you money belongs to you, lives where you decide and changes only when you allow it.

References

·       Assante, M. J., & Lee, R. M. (2015). The industrial control system cyber kill chain. SANS Institute. link

·       Cybersecurity and Infrastructure Security Agency, Department of Energy, National Security Agency, & Federal Bureau of Investigation. (2022, April 13). APT cyber tools targeting ICS/SCADA devices (Advisory AA22-103A). link

·       Dragos. (2026, February 17). Dragos OT cybersecurity report: Adversaries increase real-world impact, map control loops across industrial infrastructure Press release]. [link

·       European Commission. (2025). Data Act. Shaping Europe's digital future. link

·       International Electrotechnical Commission. (2013). IEC 62443-3-3: Industrial communication networks — Network and system security — Part 3-3: System security requirements and security levels. IEC.

·       Johnson, B., Caban, D., Krotofil, M., Scali, D., Brubaker, N., & Glyer, C. (2017, December 14). Attackers deploy new ICS attack framework "TRITON" and cause operational disruption to critical infrastructure. Mandiant. link

·       Langner, R. (2013). To kill a centrifuge: A technical analysis of what Stuxnet's creators tried to achieve. The Langner Group. link

·       MITRE. (n.d.). Program upload (Technique T0845) and Program download (Technique T0843). MITRE ATT&CK for ICS. T0845 · T0843

·       Stouffer, K., Pease, M., Tang, C., Zimmerman, T., Pillitteri, V., Lightman, S., Hahn, A., Saravia, S., Sherule, A., & Thompson, M. (2023). Guide to operational technology (OT) security (NIST SP 800-82 Rev. 3). National Institute of Standards and Technology. link

About EmberNET

EmberNET is an industrial operating platform built by an OT company for OT people, sold and integrated by Fireball Industries. It was designed around the sovereignty questions raised in this post:

·       Your logic, your location. Deploy on-premises, in your own cloud, hybrid or fully air-gapped. There is no dependency on a vendor cloud and nothing has to phone home.

·       Zero-trust by default. Mutual TLS in both directions, no open inbound ports, no VPN, and post-quantum encryption across the mesh.

·       Brownfield first. EmberNET goes in front of existing Siemens, Rockwell and CODESYS equipment. Your controller keeps running, and logic can move to a software PLC on your schedule.

·       Config-as-code. A built-in Git service that works air-gapped keeps configurations versioned on site.

·       No kill switch. Software already on your hardware keeps running if a subscription lapses, custom code is assigned to you, and source escrow protects you from vendor risk.

Bring one real constraint — brownfield equipment, an air gap, a multi-site rollout or a vendor you are locked into — and see what the platform does with it. Contact sales@fireballz.ai or visit embernet.ai.