Industrial remote access, compared honestly
Trout Access Gate brokers remote sessions on your own network: no third-party rendezvous, policy scoped per user, asset and protocol, and the plant segmented behind it.
Last updated:
Two questions decide this, and neither is about the box
Every product here puts hardware or software at the machine and gets a technician to it. On that job they are all competent, and Ewon in particular is close to unbeatable for a machine builder who needs one connection without involving a customer's IT team.
The first question that separates them is who operates the rendezvous. Talk2M and IXON Cloud are run by the vendor, which is a dependency and, under NIS2 supply-chain review, a question you will be asked to answer. Secomea and Siemens can be self-hosted. Access Gate has no rendezvous outside your network at all.
The second is what the session is scoped to. A VPN lands the engineer on the machine's LAN and stops having opinions. A brokered session names the asset and the protocol, records what happened, and leaves the rest of the plant unreachable. Note that these are not mutually exclusive: most plants are best served by keeping the gateway and putting a control point behind it. The table is built from public vendor documentation, and where something is not documented it says so.
How industrial remote access options compare
Competitor cells are drawn from each vendor's public documentation, linked below. Where a capability is not publicly documented, the cell says so rather than assuming.
| Capability | Ewon + Talk2M | Secomea | Siemens SINEMA RC | IXON | Trout Access Gate |
|---|---|---|---|---|---|
| Who operates the broker | HMS, via Talk2M | You or Secomea; GateManager offers both | You; the SINEMA RC server is yours to run | IXON, via IXON Cloud | You; the gate brokers locally |
| Runs with no third-party service | No; Talk2M is the rendezvous | Yes, with a self-hosted GateManager | Yes; the server runs on your infrastructure | No; IXON Cloud is the rendezvous | Yes; nothing leaves your network |
| What a session is scoped to | A VPN onto the machine LAN | A registered device, reached via LinkManager | A device or subnet over the VPN tunnel | A registered device | One user, one asset, one protocol |
| Session recording | Connection logs | Audit logs of connections | Connection logs | Connection logs; session detail varies by plan | Full session recording and playback |
| Segments the plant behind it | No | No | Partial; with Scalance firewalls deployed alongside | No | Yes; overlay enclaves, no VLAN redesign |
| Automatic asset inventory | No | No; you register what should be reachable | No | Partial; the devices you onboard | Yes; automatic discovery of what is on the network |
| Detection and alerting | No | No | Not part of the remote-access product | No | Yes; Snort rules, curated alert library, SIEM forwarding |
| Compliance evidence (IEC 62443 / NIS2) | Connection logs only | Access logs you assemble yourself | Logs you assemble yourself | Connection logs | Yes; mapped to IEC 62443, NIS2 and CMMC |
| What a 15-machine site looks like | One Cosy per machine, each managed on its own | One SiteManager per machine or cell | One server plus a Scalance per enforced boundary | One gateway per machine | One appliance for the site, one policy set |
Sources: Ewon / Talk2M · Secomea · Siemens SINEMA RC · IXON
The questions that decide it on a plant floor
If the internet drops, what still works?
With a cloud-brokered product the rendezvous is unreachable, so remote sessions stop. That is usually acceptable. What matters more is whether your segmentation and access policy also depend on that service, because if they do, an outage at a vendor becomes a security event at your plant. Local enforcement keeps applying either way.
What can the engineer reach once they are in?
A tunnel puts them on a network segment. From there, reachability is whatever the network allows, which on most plant floors is everything. A brokered session names one asset and one protocol, so the answer is bounded by policy rather than by topology.
Who will procurement ask about under NIS2?
Article 21 pushes supply-chain risk onto you. A remote-access path that runs through a vendor-operated cloud is a third party in scope, with the documentation and assurance work that follows. Keeping the broker on your own network removes the question instead of answering it.
This runs where agents cannot
Trout Access Gate secures defense manufacturers, research institutions, and critical-infrastructure operators: environments built on legacy PLCs, SCADA, and equipment that cannot take an agent. Among them are Thales, Millbrook Machine, Elna Magnetics, Irish Manufacturing Research, HUN-REN SZTAKI, and STBMA.
See customer storiesQuestions about industrial remote access
Access Gate brokers remote sessions on your own network, then segments the plant behind them, with no third-party rendezvous.
It is how an engineer, an OEM or a contractor reaches equipment inside a plant without being on site. Because PLCs, HMIs and drives cannot run agents and often cannot be patched, the access is brokered by something in front of them: a gateway box, a VPN concentrator, or a proxy. The products differ mainly in who operates the connection point and how tightly the session is scoped.
It answers connectivity, not access control. Once the tunnel is up the engineer is on a network segment and reachability is decided by topology, not policy. For a single machine at a customer site that is often fine. For a plant you own, it means a contractor working on one line can reach every other device on that segment, which is the path lateral movement takes and the thing auditors now ask about.
They share a shape: a gateway at the machine, a client for the technician, and a broker in between. The difference is who runs the broker. Talk2M (Ewon) and IXON Cloud are operated by the vendor. Secomea's GateManager can be hosted by you, and Siemens SINEMA Remote Connect is a server you run yourself. If sovereignty or NIS2 supply-chain review matters to you, that distinction is the one to start from.
Yes. Access Gate brokers sessions on the appliance itself, so there is no external rendezvous to reach and no vendor service in the path. It keeps the property that makes cloud-brokered products attractive, no inbound firewall rules to open, because it does not publish a service to the internet either.
No. Assets keep their IP address, gateway and routing. Access Gate is inserted with a routing or DNS change and represents each asset by an overlay twin, so nothing on the plant floor is reconfigured and the change can be staged and rolled back like any routing change.
Often the answer is not one of them. These are capable spot solutions for getting a technician to a machine, and on a site you do not own a cloud-brokered gateway such as Ewon or IXON may be the only thing you can deploy. The risk is deploying connectivity on its own: a gateway per machine gives you doors into the plant with no visibility of what passes through them and no access control at an OT control point. The solid architecture is both. Keep the gateway where it earns its place, put an in-path appliance behind it, and every session that arrives still meets identity, protocol policy, recording and a segmented network.
See whether Access Gate fits your plant
Thirty minutes with an engineer is usually enough to tell whether an in-path, self-hosted approach fits your sites, or whether a cloud-brokered gateway is the better call. We will tell you honestly either way.