Only 443 Open?
Here's How We Make Sure It Still Works
In the most locked-down OT networks, the only thing that reliably works is what a web browser needs. That is exactly the network Simplinx is built for — and we test it on every single software change.
Industrial and OT networks are deliberately locked down. Customers close unused ports, block inbound connections, disable UDP — and increasingly they do this to satisfy security frameworks like NIS2 and the Cyber Resilience Act. In many sites the only thing that reliably works is what a web browser needs: an outbound connection on port 443, ordinary HTTPS.
Most remote-access tools were never built for a network this strict. They need open ports, a VPN client, or protocols the firewall simply drops — so the machine sits there unreachable, and someone gets in a car. Simplinx is built for exactly this network.
The Fastest Path First, a Relay When Needed
Every Simplinx connection tries the fastest path first: a direct device-to-device link that keeps traffic off our servers entirely. On an open network, that is what you get — lowest latency, no middleman, no bandwidth ceiling.
When a locked-down network blocks the direct path — which is precisely where most tools give up — Simplinx falls back to a relay: a neutral meeting-point server between the two ends. The engineer's side and the machine's side each reach the relay on their own, and the tunnel forms between them. Nothing about the user's workflow changes; the software simply takes the road that is open.
One Outbound Connection, Port 443, Nothing Else
The important part is how the machine reaches that relay: a single ordinary outbound connection on port 443 — the same port and the same direction as loading any website. Nothing listens for incoming connections. No firewall rule has to change. No port forwarding, no static IP, no VPN concentrator, no exception ticket.
If the site can browse the web, the machine connects. That one 443 connection carries everything — remote desktop, PLC programming, file transfer, data collection — and the machine never opens a port or sends anything the firewall would reject.
From the firewall's point of view, an SMX-RNS device looks like one more browser tab. That is a deliberate design goal, not a happy accident: it is what makes the product deployable in an OT zone where nothing else is.
A Relay Is a Courier, Not a Reader
Going through a relay does not mean the relay can read the data. Every Simplinx tunnel is encrypted end-to-end between the two devices. The relay forwards sealed traffic it has no ability to open — a courier, not a reader.
Direct or relayed, the security of what flows inside the tunnel is identical. What you lose is a few milliseconds of latency — not confidentiality, and not the guarantee that only the two endpoints can see the traffic.
We Prove This Rather Than Claim It
Every remote-access vendor says their product "works through firewalls". The part worth emphasising is that validating the only-443 path is a permanent part of how we build — not something we checked once before a trade show.
In the lab we deliberately cripple the connection the way a hostile corporate firewall would: first block all UDP, then block everything except outbound 443, so the machine has exactly one way out — and confirm a real connection still forms and carries live traffic.
"Looks connected" isn't enough. We inspect the live connection to confirm it is genuinely riding port 443, and that nothing is slipping out through an unintended side path.
The hard case is when both ends are locked to 443-only. We verify that they still find each other and exchange data through the relay — not just the easy scenario where one side has an open network.
We validate that each device automatically picks the nearest and fastest relay, fails over to another server if one goes offline, and reconnects cleanly after a drop.
All of the above are automated regression tests. A future update cannot silently break the one path a locked-down customer depends on — if it does, the build tells us before the customer does.
And When a Network Really Does Block Something
No amount of testing makes every customer network cooperate. So when something is blocked, the product says so: built-in diagnostics test the connection from the machine's own side and report the result in plain language — "your network is blocking this, here's what to ask IT for" — instead of requiring someone to capture network traffic on the factory floor.
That turns a multi-day back-and-forth between a machine builder, a customer, and an IT department into a single screenshot with a clear answer.
Why It Matters
Bottom Line
A locked-down network isn't an obstacle to remote access. Done right, it's just one open port — and one is all we need.
If you want the detail of how the tunnel itself is built, that is covered in Not a VPN. A Secure Tunnel: How Simplinx P2P Works, and the reasons the traditional approach fails are in Why Standard VPN Fails in Industrial Environments.
Want to Know More About How Simplinx Works?
Talk to our engineering team — we're happy to go deeper on any aspect of the platform.