The short version
Talk2M is not the problem. Depending on it might be. Ewon's Cosy and Flexy gateways dial outbound to Talk2M, HMS Networks' hosted rendezvous, and a technician joins the same meeting point through eCatcher to get a VPN into the machine. No inbound firewall rules, no public IP, a free tier, and an installed base in the hundreds of thousands. For a machine builder reaching one machine on a customer's site, it is close to the ideal answer.
Two things change when the plant is yours rather than your customer's. Your remote access now depends on a service you do not operate, and the tunnel lands your engineer on the machine's LAN with nothing deciding what else they can touch.
Why the outbound model won
It is worth being precise about what Ewon got right, because any alternative has to match it.
The hard part of industrial remote access was never encryption. It was asking someone else's IT department for a firewall rule. An outbound-initiated connection sidesteps that entirely: the Cosy calls out, the rendezvous pairs the two ends, and nobody has to open a port or justify an inbound exposure. That single design decision is why the category exists in its current shape, and why Ewon, IXON and others all converged on it.
Any product claiming to replace it must keep that property. If your alternative requires publishing a service to the internet, it has traded a real problem for a worse one.
What changes when you own the plant
The rendezvous becomes a supplier
Under NIS2, Article 21 pushes supply-chain risk onto the operator. A remote-access path that transits a vendor-operated cloud is a third party inside your scope, which means it needs documenting, assessing and re-assessing. That is not an accusation about HMS, who run Talk2M seriously and with regional data centres. It is a statement about where the paperwork lands, and increasingly it lands on procurement rather than on engineering.
The question you get asked is rarely "is Talk2M secure". It is "what happens to your ability to operate if that service is unavailable, and who decided that". Those are easier to answer when the answer is that there is no external rendezvous.
Your identity system is not invited
This is the one that surprises people, and it is worth checking against the documentation rather than taking anyone's word for it.
Talk2M users are local accounts. You create them inside the Talk2M account, assign a role (System Administrator, Administrator, Advanced User, User), and secure them with a password plus optional two-factor by SMS or email. What the documentation does not describe is any federation: no SAML, no OIDC, no LDAP, no Active Directory, no Microsoft Entra ID. Your corporate directory and your remote-access directory are two separate lists maintained by two separate people.
The consequence shows up at offboarding. When a contractor's engagement ends, HR disables their account in Entra ID and every federated system revokes access automatically. Talk2M is not one of those systems. Somebody has to remember to open eCatcher and delete the user by hand, and if nobody does, a former contractor keeps a working path into a machine on your plant floor. That gap is invisible in an access review that only looks at the directory.
HMS is addressing this in the newer Ewon Edge and Cloud line, which does advertise SSO. Worth knowing that Cosy and Flexy gateways connect exclusively to Talk2M, so for the installed base this is a hardware refresh rather than a setting.
Access Gate takes the opposite approach: users and groups synchronise from Microsoft Entra ID, sign-in uses OIDC against your existing credentials, and administrators can log in through Entra or Google Workspace SSO. Access follows the directory, so disabling the account is the revocation.
The tunnel has no opinion
Once the VPN is established, the engineer is on a network segment. From that point, what they can reach is decided by network topology, and on most plant floors topology means everything. A contractor sent to service one packaging line can, without any malice, reach the historian, the HMI on the next line, and the flat Windows box nobody has patched since 2019.
This is the distinction between connectivity and access control. Connectivity asks whether you can get there. Access control asks whether this person, on this day, may reach this specific asset over this specific protocol. A VPN answers the first and is silent on the second.
One box per machine does not scale
The per-machine model is invisible at one machine and painful at fifteen.
Every gateway is its own island. Each has a configuration, a firmware version, a certificate, a set of users and a support case when it misbehaves. A site with fifteen machines ends up with fifteen boxes, and because they were bought at different times by different people for different lines, they are rarely on the same firmware or configured the same way. Nobody has a single view of who can reach what, because there is no single place where that is decided.
Then multiply by sites. An operator with eight plants is running an estate of remote-access hardware that nobody owns centrally, with an access policy that exists only as the union of dozens of local configurations.
The alternative is one enforcement point per site rather than per machine. Access Gate is a single integrated appliance: one device to patch, one policy set covering every asset behind it, one place to answer "who can reach the packaging line". Adding a machine is a policy entry, not a purchase order, a rack slot and another thing to keep patched.
What an alternative has to do
| Requirement | Why it matters |
|---|---|
| No inbound firewall rules | The property that made Ewon win. Give it up and you have gone backwards. |
| Broker runs on your network | Removes the supply-chain question rather than answering it every year. |
| Corporate directory identities | Offboarding in Entra ID should end plant access, without a second list to maintain. |
| Session scoped to one asset and protocol | A contractor on one line cannot reach the rest of the plant. |
| Recording, not just connection logs | "Who connected" is not the same evidence as "what they did". |
| One unit per site, not per machine | Fifteen boxes is fifteen firmware versions and no single view of access. |
| Segments the plant behind it | Remote access is one entry path. Lateral movement is the real exposure. |
Trout Access Gate keeps the first property by brokering sessions on the appliance itself rather than publishing anything to the internet, and adds the rest. The engineer reaches a named asset through a proxied session with MFA, a time window and a recording. Behind the gate, the plant is divided into overlay enclaves, so the blast radius of a compromised contractor account is one machine rather than one subnet, and none of that requires re-addressing anything: assets keep their IP, gateway and VLAN.
Deploy both, not one instead of the other
Being honest about this matters more than winning the argument, so here is the recommendation: in most plants you should keep Ewon and put a control point behind it.
Ewon is a capable spot solution. For an OEM servicing machines on sites you do not own, it is often the only thing you can deploy, and it fits that job precisely. Nothing here argues for removing it.
The risk is connectivity deployed on its own. A Cosy 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. Fifteen machines is fifteen doors, and your security stack sees none of them.
The solid architecture is both. Keep the gateway where it earns its place, put Access Gate behind it, and every session that arrives still has to pass identity, protocol policy and recording, landing in a segmented plant rather than a flat one. You are not replacing a supplier, you are adding the control point the tunnel was always missing.
Related reading
- Access Gate vs Ewon and Talk2M, the full side-by-side
- Industrial remote access compared, five options including Secomea, Siemens and IXON
- NIS2 compliance for OT