Compare Trout & IXON
IXON is the most modern product in this category, with genuine SSO and dashboards Access Gate does not match. The split is not old versus new. It is machine builder versus plant operator.
The problem
IXON solved remote service beautifully: an IXrouter at the machine, an outbound connection to IXON Cloud, a browser session for the engineer, and data logging on top. If you build machines and ship them, that is close to the whole job. If you run the plant those machines sit in, it covers the way in and nothing about what happens between them.
Trout Access Gate
One appliance per site rather than one router per machine. The broker runs on your own network, so no external service is in the path. Each session is scoped to a named asset and protocol, authenticated and recorded. Behind it the plant is divided into overlay enclaves, every asset is discovered automatically, and detection forwards to your SIEM with evidence mapped to IEC 62443, NIS2 and CMMC.
IXON
An IXrouter at the machine dials out to IXON Cloud, and the engineer connects through the browser with no inbound firewall rules. IXON Cloud documents Okta SSO on a custom domain plus Google and Microsoft sign-in, enforceable two-factor per role, and built-in data logging, dashboards and alarms. On identity and on machine data it is ahead of most of this category, and Access Gate does not claim to beat it on dashboards.
| Feature | Access Gate | IXON |
|---|---|---|
| Deploys without re-cabling or re-addressing | Assets keep their IP, gateway and VLAN | IXrouter sits in front of the machine |
| On-site hardware gateway | ||
| No inbound firewall rules needed | The gate brokers locally; nothing published | Outbound-only connection to IXON Cloud |
| Single sign-on with your identity provider | Entra ID user and group sync, OIDC | Okta SSO on a custom domain, Google and Microsoft sign-in |
| Enforceable two-factor authentication | Enforceable per role | |
| Machine dashboards and data logging | Can host a historian or dashboard service locally | Built-in data logging, dashboards and alarms |
| Runs with no third-party cloud service | Nothing leaves your network | IXON Cloud is the platform, not an option |
| Per-session, per-protocol policy | This user, this asset, this protocol | VPN lands on the machine network |
| Session recording and playback | Audit trail of connections, not session content | |
| Scales to a whole site, not per machine | One appliance and one policy set for the site | One IXrouter per machine or cell |
| Network segmentation | Overlay enclaves, no VLAN redesign | Connects machines; does not segment between them |
| Automatic asset inventory of the whole network | The devices you onboard behind each router | |
| Security detection and SIEM forwarding | Snort rules, curated alert library, Splunk/Elastic/Wazuh | Alarms on machine data, not network security detection |
| Compliance evidence generation | IEC 62443, NIS2, CMMC mapping | Connection and audit logs |
Whose platform is in the path
IXON Cloud is the product, not a deployment option. It is EU-operated, so this is not a jurisdiction argument, it is a dependency one: a third party in scope under NIS2 supply-chain review, and a service your plant access relies on staying available.
One router per machine, or one appliance per site
Fifteen machines means fifteen IXrouters, each with its own configuration and firmware. One appliance per site gives one policy set and one answer to who can reach what.
Better behind it than instead of it
A connectivity gateway is a door into the plant, and every one you add is another way in that your security stack cannot see. Access Gate does not ask you to remove IXON. It sits behind it as the OT control point, so whatever arrives through the tunnel still meets identity, protocol policy, recording and a segmented network.
Access Gate vs IXON FAQ
One appliance, one policy set and one place to answer who can reach what, instead of one router per machine.
Yes, and it would be wrong to suggest otherwise. IXON Cloud documents Okta SSO on a custom domain, sign-in with Google or Microsoft accounts, and two-factor authentication that can be enforced per role. On identity it is well ahead of the older gateways in this category, and this comparison does not rest on that point.
Machine data and user experience. Built-in logging, dashboards and alarms mean a machine builder gets remote service and remote monitoring from one product with a modern interface. Access Gate can host a historian or dashboard service locally, but it is not an IIoT platform and does not pretend to be.
No. The cloud is the platform rather than an optional broker, which is the structural difference here. Access Gate brokers on the appliance itself, so there is no external rendezvous to depend on, and it keeps the property that makes IXON easy to deploy: no inbound firewall rules, because nothing is published to the internet.
No. IXON is a Dutch company operating in the EU, so jurisdiction is not the argument. The argument is dependency: under NIS2 Article 21 a vendor-operated service in your access path is a third party in scope, with the documentation and assurance work that follows, and an availability question you did not previously own.
Usually not, and that is not what we recommend. IXON is a capable spot solution for getting a technician to a machine, and on sites you do not own it may be the only thing you can deploy. The risk is not the product, it is deploying connectivity on its own: a IXrouter 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 IXON where it earns its place, put Access Gate behind it, and every session that arrives still has to pass identity, protocol policy and recording, in a plant that is segmented rather than flat.