Remote access to building and industrial systems is usually solved with a shared VPN account, a jump box, and a great deal of trust. The vendor gets in, does the work, and the record of what happened is whatever they choose to tell you. When something breaks two days later, nobody can reconstruct who did what.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
Designed Capabilities
- Identity and device verification — who, and from what machine.
- Ticket- and approval-linked access — access exists because a job authorised it.
- Site and application-level authorization — this site, this system, nothing else.
- Time-window and session policies — access expires on its own.
- Session recording and command logging — a reconstructable record of the work.
- Controlled file transfer — what came in and what left.
- Bastion and protocol proxying — no direct route to the control network.
- Customer asset and audit integration — access tied to the asset register.
Built for OT Realities
Operational networks cannot simply adopt corporate remote-access tooling — the systems are fragile, the vendors are numerous, and the access is occasional but highly privileged. Time-bound, ticket-linked, recorded access fits how this work genuinely happens, and complements the passive assessment side of our OT and network forensics practice.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Related services
- OT and ICS Security Assessment — Remote access is a finding in most control networks: OT and ICS security assessment.
This Is a Design, Not a Product Yet
This gateway is a concept we are building. It is not available to buy, license, or pilot today, no pilot program is open, and no release date is published. What follows is the reasoning behind the design, which is worth reading either way, because the same decisions apply to the remote access arrangements you have right now.
What Zero Trust Means for a Service Technician
Stripped of marketing, it means no standing access. A technician does not hold a credential that works on Tuesday because it worked last month. Access comes into existence because a work order exists, is scoped to the systems that work order names, carries an expiry, and leaves a record behind. Two properties do most of the work: access that ends without anyone remembering to remove it, and authorization bound to a specific site and system instead of a whole network segment. An account that outlives the reason it was created keeps working long after anyone has a reason to look at it, which is why expiry does more here than password policy does.
Session Recording Raises Questions to Settle Early
Recording a vendor’s work is defensible, but permission for it is not automatic. Notice obligations, consent, employee representation requirements in some jurisdictions, retention periods, who may review a recording, and what happens when one becomes evidence in a commercial dispute all need answers before the first session. Those answers belong to your counsel and your contracts team, and vendor agreements often predate the question entirely.
The design has to make those answers enforceable rather than aspirational, which is the part a product can fairly be judged on: a banner shown at session start, a retention period settable per site instead of rare full-stack Niagaraly, playback restricted to a named group with each view itself logged, and an export path for the one case where a recording is needed as evidence. A gateway that cannot express the policy your contracts team writes will have that policy broken within a month of go-live.
Break-Glass Is a Design Requirement
Any control placed between a technician and a plant becomes part of that plant’s availability story. If the gateway is unreachable at two in the morning during a heating failure, somebody will look for a way around it, and an undocumented workaround is worse than a documented one. Emergency paths deserve deliberate design: a separate credential route, heavily alerted, short-lived, and reviewed the next business day. What an outage actually costs varies enormously by facility and by the process being served, so the availability requirement is a conversation with operations before it is an engineering decision.
Why Operational Networks Make This Harder
Control systems are frequently old, rarely patched, and intolerant of scanning and agents. Vendors arrive with their own laptops and their own tooling. BACnet and Modbus were specified without authentication of their own; secure variants exist in BACnet/SC and in the Modbus/TCP security specification, but most equipment already installed does not speak them, so anything meaningful still has to happen at the access layer and the network boundary. Change windows are narrow, and a single integrator may hold access to many sites belonging to different owners. These are the conditions our OT and ICS security assessment work examines, and remote access is one of the first things that assessment looks at.
The Threshold Where This Starts to Matter
What changes the calculation is multiplicity: several vendors, several sites, any shared account, or an inability to say who connected last month and what they touched while they were in. Past that point the access list stops being something one person can hold in their head, and the review that was supposed to happen quarterly stops happening. Below it, what many sites already have is reasonable. One vendor, one site, individually named accounts with multifactor, an access list somebody actually reviews on a schedule, and logs that get read: a gateway would add process to that without taking much risk out of it.