Why Armilar invested in Coreflux… and a few insights on bridging Operational with Information Technology

Picture this:

A few years back, around the turn of the century, at a covert nuclear site in the Middle East, scientists quietly pursued a classified uranium-enrichment program. Then, without warning, an unusual number of centrifuges (devices that sort uranium types based on tiny mass differences) began to fail, halting operations. Technicians rushed to the control room — yet every system readout appeared perfectly normal, offering no clue to the sudden breakdowns.

Could a single failing component cause all the centrifuges to fail at once, or could it have been physical sabotage?

Initial investigations pointed to hardware-level, human-led tampering: the machines had reported no prior issues, and their control software was fully air-gapped, in line with the then-guidelines for isolating shop-floor devices and systems — known as Operational Technology (OT) — from external data and business processing systems — known as Information Technology (IT). This left no obvious path for remote intrusion.

Yet months later, a surprising discovery surfaced: several contractor-site Windows PCs would abruptly crash the moment specific USB drives were plugged in …

This may look like the screenplay for a new Hollywood thriller, but the truth is far more unsettling: this scene is drawn from real life. In early 2010, Iran’s Natanz uranium-enrichment plant suffered the failure of several centrifuges, an incident widely attributed to the Stuxnet computer worm. Considered by many the first true digital weapon, Stuxnet exposed the once-invisible bridge between OT and IT.

In simple terms, forensic data suggests that multiple Windows vulnerabilities were exploited by the Stuxnet worm, likely introduced into Iran’s nuclear plant via a USB device. Stuxnet then spread laterally until it reached the workstations controlling the centrifuges, took over communications with the Programmable Logic Controllers (PLC), and injected faulty commands while falsifying sensor data — making the system appear normal as the damage unfolded.

This textbook example shows how a once-essential OT safety measure — air-gapping physical devices from IT systems — became a major liability. The separation allowed the worm to remain hidden inside the OT environment, delaying detection and response. An integrated OT/IT approach could have enabled a faster and more effective defense.

While security has long been a key argument for OT/IT separation, many other factors also drove this divide, as shown in the chart below.

…and for decades that view reigned supreme. But the tide has finally turned — Natanz was just one of several triggers. Strong market trends, along with pressing market challenges, are now pushing OT and IT toward integration, as shown in the chart below.

In addition, OT/IT integration is no longer just a shop-floor requirement — it has become essential across multiple industries:

· Connected cars: predictive maintenance systems (IT) rely on data streamed from onboard sensors (OT).

· Energy infrastructure: power-optimization platforms (IT) must send control commands to grid actuators (OT).

· POS terminals: telemetry and firmware updates must flow from cloud back-end systems (IT) to payment terminals (OT).

Set 1 towards OT/IT integration … establishing a common messaging system

So, if we want to integrate OT with IT, the most fundamental component is a secure communication protocol ensuring reliable message delivery between physical OT devices (let’s assume Internet-of-Things (IoTs) devices) and the various information systems and databases.

In the TCP/IP realm, there are two main approaches to securing this communication, as shown in the chart below: (i) the traditional HTTP protocol, developed in the 1990s and used for web browsing, or (ii) newer message-queuing protocols, like MQTT, developed about a decade later.

HTTP operates on a request-response paradigm, requiring sessions to be opened and closed on each communication (high overhead), with the client and server having to be online for exchanging (long) text-based messages. While relevant upgrades have been introduced (such as RestAPI and Websockets), this is generally not the most suited model to connect IoTs. IoTs constantly send and receive data (so links need to be permanently open) and work on faulty and limited bandwidth channels (so low message overhead is critical).

Message queuing protocols, by contrast, were specifically designed for device connectivity, with MQTT (with its roots back in 1999 inside the IBM’s researching community) being one of the most powerful protocols to integrate OT/IT. At a high level, MQTT works by:

· Having MQTT SW clients (decentralized computing nodes) running on IoT devices and IT systems, interacting with a central broker.

· MQTT clients can be Publishers by writing messages in subscribed topics.

· MQTT clients can also be Subscribers by reading messages from subscribed topics.

· A central computing node (Broker) routes messages between publishers and subscribers within a topic-based framework. Brokers are payload-agnostic, handling everything from video streams to JSON files.

In summary, MQTT overcomes many HTTP limitations in IoT: (i) connections remain open with minimal message overhead, and (ii) transmitters and receivers don’t need to know each other or stay online continuously.

Set 2 towards OT/IT integration … making data interoperable

While MQTT brokers ensure reliable message delivery between OT devices and IT systems, this alone isn’t enough for full OT/IT integration, as shown in the chart below.

In this example, an SAP production management system triggers a shop-floor action — operating a robotic arm via a Siemens PLC. Both use MQTT, so the broker delivers messages between them, but the message payload (e.g. the actual control command) isn’t directly interoperable:

· The broker delivers an MQTT message to the robotic arm containing an SAP command to trigger a specific robotic action.

· The robotic arm can unpack the MQTT message, but cannot interpret it (in simplistic terms, it understands Siemens instructions, not SAP commands).

A second example highlighting the need for OT/IT data interoperability is provided below. The same robotic arm sends telemetry data through an MQTT broker to an AI-powered predictive maintenance system. While the broker ensures message delivery, the payload isn’t directly usable — for instance, the predictive maintenance SW expects imperial units but receives data in the metric system.

Making data interoperable across OT and IT environments is highly complex. Recall our initial diagram showing how distinct these two worlds are, each relying on different computing resources, technologies and even programming languages.

Traditionally, companies try to address OT/IT data interoperability by developing additional software components to read, process, and translate data between systems. This often involves long, complex IT consulting projects, resulting in an unmanageable tangled mix of applications, scripts, APIs (…)

Reimagining the MQTT broker for full OT/IT integration … and so enters Coreflux

Coreflux was founded in 2022, drawing on over 20 years of industrial systems expertise from co-founders Hugo Vaz, Paulo Mota, and Hugo Felgueiras. The team developed a disruptive IoT communication and operations platform by redefining the MQTT broker, directly addressing the OT/IT integration market. Coreflux’s product is built on three layers, summarized in the chart below:

· (A) Coreflux Connecting Layer: Software connectors (MQTT clients) that allow physical devices or systems that don’t natively support MQTT to communicate with Coreflux’s broker.

· (B) Coreflux Broker Messaging Layer: The core MQTT broker component that secures message transfer between clients. While supporting all standard message delivery protocol features, Coreflux’s hardware-level approach is particularly unique in (i) Increasing messaging throughput of resource-constrained IoTs; (ii) reducing scaling costs when using multiple brokers working together in clusters.

· (C) Coreflux’s Broker Computing layer: Coreflux’s data interoperability component, working on top of the core messaging layer (B). This is the building block that truly ensures OT/IT integration, positioning itself as a market disruptor. The concept is based on:

• (i) The MQTT broker is already central to OT/IT communication, as all messages pass through it.
• (ii) Moreover, the broker can leverage existing hardware resources to perform additional computations beyond message delivery.

This allows the broker to open the MQTT messages and be programmed to read and act on message payloads, enabling the transformation of data, or execution of event-driven logic or even locally run phyton-based algorithms.

Thanks to components (A), (B) and (C)together, Coreflux is more than a simple MQTT broker — it’s a solution that delivers true data interoperability and enables full OT/IT integration.

As you might guess, the key question is how Coreflux’s broker can be programmed to act on message payloads. To solve this, Coreflux developed an intermediary English-based programming language for its broker, Language of Things (LoT), which can be used…

• … directly by developers as a programming language.
• … via a simple low-code drag-and-drop interface.
• … through natural-language instructions, powered by an MCP backend which exposes the internal LoT components to be used by external applications or AI workflows.

The LoT is the framework that redefines the way traditional MQTT brokers are used and programmed, proving an interface to setup data flows inside complex OT/IT systems and to act on such data flows bridging the gap to AI/ML workflows

From brown soil to green horizons, leveraging on the MQTT computing layer

Let’s now illustrate, using the chart below, how Coreflux addresses key OT/IT integration challenges.

• Challenge: A production management system (which outputs SAP commands) remotely operating a robotic arm (with inputs being Siemens language instructions).
• Coreflux Solution: The broker decodes SAP commands and translates them into Siemens instructions.
• Value proposition: Reduces IT integration time and costs, eliminating also multiple translation scripts.

Use-case 2 — Data engineering

• Challenge: An AI-powered predictive maintenance SW ingesting data in a different format than that output by a robotic arm.
• Coreflux Solution: The broker performs simple Extraction, Transformation and Load (ETL) tasks, such as filtering and converting data (e.g. from imperial to metric units).
• Value proposition: Reduces cloud networking costs by sending only relevant filtered data and lowers cloud computing costs by handling core ETL on the broker.

Use-case 3 — Real-time system control

• Challenge: A cloud-based facility management SW having to control in real-time HVAC parameters by monitoring environmental conditions on workstations.
• Coreflux Solution: The broker executes internal logic (e.g. if-then-else on device temperature) or supports Python-based scripts on the data stream, triggering actions.
• Value proposition: Speeds up execution (e.g. faster HVAC adjustment) while reducing costs and risks from external, isolated control applications.

In short, Coreflux has the potential to bridge OT and IT seamlessly, transforming complex integration into simple, real-time interoperability. It empowers organizations to unlock the full value of their data while reducing cost, risk, and operational friction.

Coreflux is already the partner of choice for numerous enterprise IoT and industrial customers worldwide, and we’re thrilled to join them on this journey.

Authored by João Miguel Dias, Partner Armilar