Secure Remote Access to Machines and PLCs: Remote Service Without Open Ports

A machine is down, the customer is on the phone — and the nearest service engineer is hundreds of kilometers away. For machine builders and maintenance teams, remote service stopped being optional long ago: it is a precondition for running service profitably. The question is not whether but how: how do you reach a machine inside your customer’s network without compromising their IT security — and without launching a dedicated VPN project for every single site?

This guide shows how remote service works with IronFlock: over outbound, encrypted connections, without a single open port on the machine.

Why traditional remote service hits its limits

The established approaches bring recurring problems with them:

• Site-to-site VPNs are projects, not solutions. Every customer connection requires coordination between two IT departments, firewall rules, IP addressing schemes, and ongoing upkeep. That does not scale across hundreds of sites.
• Open inbound ports are attack surface. Every externally reachable service on a machine — SSH, HTTP, VNC — is a potential entry point, and in many OT networks it simply will not pass approval.
• Remote-service routers create islands. One maintenance module per machine means separate hardware, separate administration, separate credentials — and no shared view of the fleet.
• Traceability is missing. Who had access to which machine, and when? Without complete logging, that question is nearly impossible to answer for customers and auditors.

The principle: connections from the inside out

IronFlock reverses the direction. On the machine — or on an edge device next to it — runs the IronFlock device agent. It initiates all connections outbound to the platform, encrypted over TLS. That has immediate consequences:

• No open ports on the device. The machine is neither discoverable nor directly addressable from the internet. There is no service an attacker could scan.
• No inbound firewall rules on the customer side. A single outbound HTTPS/WSS connection is all it takes — the same kind of connection every browser uses. Operation behind corporate proxies is supported as well.
• Remote access through reverse tunnels. When you access a local web interface or service, the platform establishes the connection through a managed reverse proxy architecture over the existing channel — the direction of the original connection stays outbound.

This zero-trust architecture is described in detail in the security documentation.

What you can reach remotely

Remote access is not limited to a single protocol. Tunnels can be enabled per app and device for different kinds of services:

On top of that, two system-level access paths are available:

• Host access — a browser-based terminal on the device’s host operating system, for system diagnostics, network debugging, and Docker administration. No local intervention, no site visit.
• SSH access — for advanced debugging with key-based authentication; password login is disabled by default.

Tunnels can also be embedded straight into a board via an embed widget: your service team monitors fleet data and interacts with an individual machine’s web interface — on the same dashboard.

How it works in practice

Remote service with IronFlock is set up in three steps:

1. Declare ports. The app developer describes in port-template.yml which ports and protocols the app exposes — say, the HMI on port 8080. This happens once, in the app, not per machine.
2. Enable the tunnel. A privileged user enables the tunnel in the device’s app settings — with a toggle, no network configuration.
3. Use the secure URL. The platform generates a protected URL behind which the local service is reachable — for authenticated, authorized users only.

If the network connection drops, agent and tunnels reconnect automatically — the agent is built for connectivity and resilience and retries reconnection indefinitely.

A typical service case

What this feels like is best shown by a walkthrough of the kind a machine builder’s service team goes through every day:

1. The report. An alarm or a customer call reports a fault on a machine in France. In the project, the engineer sees immediately: the device is online, the app is running.
2. First diagnosis on the board. The machine’s board shows live data and history charts revealing when the behavior started — often enough on its own to narrow down the cause.
3. Access the HMI. The engineer enables the HTTPS tunnel and opens the machine’s interface in the browser — the same view the operator sees on site.
4. Go deeper if needed. If that is not enough, next comes the TCP tunnel to the controller for the PLC engineering environment — or host access for a look at containers, network, and system load.
5. Close with a paper trail. Every step is in the audit log. The customer can verify at any time who accessed their machine, and when.

No VPN client, no on-call duty for the customer’s IT, no travel — and in the best case, the machine is producing again before an on-site visit could even have been scheduled.

Security and control: who may do what — and who did what?

Remote access is a matter of trust. IronFlock makes it controllable and traceable:

• Fine-grained permissions. Only users who hold at least the update permission on a device can enable tunnels. The privilege model works with targeted per-asset permissions instead of blanket admin roles.
• A complete audit trail. Every tunnel activation and every use is recorded in the device’s audit log — who, when, which port, including the actual proxy connections.
• Encrypted throughout. From browser to device, all components communicate over TLS-secured channels; sign-in uses OpenID Connect with optional two-factor authentication.
• Access revocable at any time. Permissions for external service partners can be granted granularly and withdrawn at any moment — the project owner retains data sovereignty.

For machine builders: remote service as part of the product

If you ship machines, you don’t want to reinvent service for every site. With IronFlock, remote service becomes part of the machine itself:

• One app, the whole fleet. The service app is installed at project level and assigned to devices — ten machines or a thousand, the access path stays the same.
• Flexible deployment. Whether IronFlock Cloud, an appliance in the customer’s local network, or a private cloud — the feature set, including remote access, is identical.
• You deliver machine expertise, not infrastructure. Tunnel management, encryption, user management, and audit logging come with the platform.

Frequently asked questions

Does my customer’s IT need to open firewall ports?

No. The device agent establishes exclusively outbound, TLS-encrypted connections — comparable to a browser opening a website. Inbound firewall rules, port forwarding, and static IP addresses are not required. Environments with a corporate proxy are supported as well.

Can I program my PLC remotely?

Yes. Through TCP tunnels you reach your controller with your familiar engineering tools — such as Siemens TIA Portal, CODESYS, or TwinCAT — as if you were on the local network. The ports are declared once in the app and enabled selectively per device.

How is remote access logged and controlled?

Only users who hold the corresponding permission on a device can enable tunnels. Every activation and every use lands in the device’s immutable audit log — including user, timestamp, and port. That lets you prove to customers and auditors at any time who had access, and when.

What happens if the machine is offline or the connection drops?

The device agent retries reconnection indefinitely and automatically re-establishes remote access tunnels after a network interruption. Even under memory or disk pressure, the agent maintains remote reachability as its top priority — the device stays remotely manageable.

Where to go next

The fastest way to your first remote access session: create a project with the getting started guide, connect a device, and enable a tunnel — it takes a few minutes and is free in the cloud. The technical details are in the documentation on remote access and security.