We've partnered with ICA, one of Scandinavia's largest brands, as IT Country Partner in Bosnia and Herzegovina. We're hiring 100+ engineers, designers, and specialists for a long-term collaboration supporting ICA across their retail, banking, and insurance operations.
75% of OT attacks start as IT breaches. Not because someone hacked your DeltaV directly. Because somewhere between your on-premises system and a remote device, a connection was built fast instead of built right.
That connection point, the integration layer, is where most industrial security problems actually live. Yet most OT security planning focuses on hardening the systems themselves. The gaps between them get less attention. And that's where attackers look first.
Your control systems, your tank servers, your SCADA infrastructure — these are usually well understood. You know what they do, who accesses them, and roughly what your exposure looks like.
The integration layer is harder to see. It includes every API endpoint, every relay connection, every remote access tunnel your teams have built over time to connect those systems to the outside world. Sometimes it was built by a vendor during commissioning. Sometimes by an internal team solving a problem quickly. Sometimes by a contractor who no longer works there.
Dragos's 2025 OT Cybersecurity Report puts a number on this: 65% of OT environments had insecure remote access conditions in 2024. 45% had SSH communicating to publicly routable addresses. These aren't compromised systems. They're connection points built without security as the first requirement.
DeltaV, TankMaster, and similar industrial systems were designed for uptime and stability. Security updates that would be routine on an IT server can conflict with strict OT availability requirements. You can't patch your way to a secure architecture when patching itself is a risk to operations.
Emerson's own DeltaV zero trust white paper acknowledges this directly: "applying patches and security updates can conflict with strict OT uptime requirements." The document goes on to describe compensating controls and bolt-on solutions being evaluated with partners like BeyondTrust and CyberArk.
These tools have their place. But they solve problems created by insecure architecture. If the connection itself is built wrong, you're managing risk permanently instead of removing it.
Security has to be built around these systems at the connectivity layer. That's an architecture decision, not a product purchase.
IEC 62443 is the international standard for securing industrial automation and control systems. Emerson's own TankMaster Mobile is built to IEC 62443-3-3. Project Beyond's zero trust security architecture references it explicitly.
Most of the standard's requirements come down to a few core principles at the connectivity level.
Zones and conduits. Systems are grouped into security zones based on risk. Communication between zones happens through controlled conduits. Every integration point between your OT zone and an IT system, a cloud platform, or a remote device is a conduit. It needs to be defined, controlled, and monitored.
Outbound-only connections. The standard strongly discourages inbound connections from outside the OT network boundary. An on-premises system should initiate connections outward, not accept them from external sources. This removes the need to open inbound firewall ports, which is one of the most common ways OT systems get exposed.
Least privilege access. Users and systems get only the permissions required for their specific task. At the API level, this means scoped tokens with defined expiry - not shared credentials or permanent API keys.
These aren't aspirational principles. They're design requirements. And they're decisions that get made when the integration is built, not after it's running.
A Nordic industrial site needed remote HMI access to an on-premises process management server. The server held live operational data. Field operators needed to view it from mobile devices over the internet.
The obvious solution: open an inbound port and expose the REST API. Fast to build. Completely wrong from a security standpoint.
The right solution uses an outbound relay architecture. The on-premises server opens an outbound WebSocket connection to Azure Relay Hybrid Connections. No inbound ports. No firewall exceptions. The relay creates a controlled conduit — encrypted with TLS 1.2, authenticated with SAS keys. Mobile clients connect through the relay endpoint, not directly to the server.
Each customer site gets its own relay endpoint and connection string. Onboarding a new site takes under an hour. Revoking access for a specific site means rotating one key. Nothing else in the architecture changes.
This aligns directly with IEC 62443 zones and conduits design. The OT zone never exposes an inbound surface. The conduit is monitored, authenticated, and scoped to a single endpoint.
The architecture does the security work. The bolt-on tools aren't needed because the problem was removed at the design stage.
Building security in from the start means making different architectural choices. Outbound-only connections instead of inbound ports. Token-based authentication with expiry instead of static credentials. One relay endpoint per customer instead of a shared gateway. Structured access per user role instead of flat network access.
None of these decisions require a separate security product. They require building the integration with security as a first-order requirement, the same way uptime is a first-order requirement.
Project Beyond's stated architecture includes a zero trust security plane, secure APIs and connectors for legacy OT systems, and a data fabric bridging on-premises and cloud. These are the right goals. The question is how each individual integration is built to support them. A platform commitment to zero trust doesn't automatically make a custom API endpoint secure. That happens at implementation.
If you're connecting on-premises industrial systems to remote devices, cloud platforms, or external APIs, the security of those connections comes down to how they were built.
We work with industrial technology teams building these integration layers. We don't do threat monitoring or compliance auditing. We build the connections correctly from the start, so the architecture does the security work.
Book a 30-minute call and we'll tell you honestly whether we can help.
FAQ
Frequently asked questions
The standard requires remote access to be treated as a conduit between security zones. Connections should be outbound-initiated from the OT side, authenticated with scoped credentials, and limited to the minimum access required for the task. Inbound connections from external networks to OT systems are explicitly discouraged. TankMaster Mobile's own compliance with IEC 62443-3-3 is built around these principles — outbound relay, encrypted transport, and role-based access control.
Yes. Outbound relay architectures like Azure Relay Hybrid Connections allow on-premises servers to initiate an outbound WebSocket connection to a cloud relay endpoint. Remote clients connect to the relay, not to the on-premises system directly. No inbound ports are required. This is the architecture pattern recommended by IEC 62443 and used in Emerson's own TankMaster Mobile deployment model.
A VPN creates a network-level tunnel and typically requires inbound connectivity or a shared network gateway. It grants access to a network segment, not a specific application endpoint. An outbound relay scopes access to a single application endpoint. Each connection is authenticated independently. There's no shared network access, no lateral movement risk, and no inbound port exposure. For industrial systems where the principle of least privilege applies at every level, a scoped relay is the more appropriate architecture.
OT systems prioritize availability. Applying security patches, restarting services, or modifying system configurations carries a real risk of downtime. In a manufacturing or process environment, downtime has direct operational and safety consequences. This means security can't be achieved through the same ongoing patching and update cycle used in IT. It has to be built into the connectivity architecture around the system — at the integration layer — where changes can be made without touching the OT system itself.
Each API connection should use a scoped credential that grants access only to the specific endpoint and data required. Credentials should have a defined expiry, not be permanent. Separate credentials should exist per customer, per site, or per integration — not shared across deployments. This means a compromised credential exposes one integration point, not the entire system. In practice, this is implemented through SAS keys with defined permissions, short-lived access tokens, or OAuth scopes mapped to specific API resources.
When the architecture is defined correctly from the start, onboarding a new site is a configuration task, not a rebuild. With an outbound relay pattern, adding a new customer or site means creating a new relay endpoint, generating a connection string, and applying it to the application config. That process takes under an hour. The security properties — encryption, authentication, no inbound exposure — are inherited from the architecture. They don't need to be re-engineered per site.
See how Kalmar Cargotec achieved 103% efficiency gains with a custom mobile app. Read the case study & learn more about the solution that supports 17 languages.
