TL;DR
A vendor can bypass MFA and sign in with an individual account while still being able to reach industrial systems unrelated to the job. Before replacing your current setup, follow one real service request from approval through completion. The exercise can reveal outdated permissions, unnecessary network connectivity, shared credentials, or records that are difficult to retrieve when you need them.
The OEM Needs One HMI. What Else Can They Reach?
An OEM technician gets a call from a water treatment plant. An HMI is behaving unexpectedly, and the operations team needs help before the problem affects production. The technician connects through the VPN, signs in to a jump server, and opens a remote desktop session. Everything works, and the repair can begin.
But what else can that person reach?
The environment may be tightly configured, with permissions limited to the HMI. Or the same connection may provide a path to other equipment on the network segment, including systems unrelated to the repair. Both environments can require MFA and individual logins, and both can produce a record showing that the technician connected successfully. Neither fact, on its own, establishes whether the person could reach more of the plant than the job required.
For organizations that depend on multiple OEMs and contractors across different facilities, the distinction deserves a closer look.
Start With the Maintenance Job
A jump server does not become insecure simply because it is old. Many organizations use them effectively, with restricted destinations, strong authentication, and monitoring. Problems often develop gradually, as permissions accumulate, and the original reasons for granting them become harder to trace.
Consider a contractor brought in to support one engineering workstation. Six months later, they need to work at another facility, so an administrator adds the necessary permission. The following year, the same contractor helps with an upgrade at a third site. Each request makes sense at the time, but three years later, the account may still be authorized to connect to every system it was ever granted, including those associated with completed projects. The technology is working as configured; the configuration no longer reflects the work.
Rather than starting with replacement products, choose an upcoming service visit and examine how the person performing it reaches the equipment involved. Include someone who understands the network path and someone responsible for approving the work. The following questions will help you distinguish controls that need attention from limitations of the existing architecture.
1. Do You Know Who Is Connected to Each OT System?
A VPN may establish someone's access, but what happens when they open the target machine? Do they continue using an individual account, or does everyone sign in with the same local administrator credential?
Suppose an investigation turns up activity associated with vendor_admin. Your organization should be able to establish who was using that account at the time. Older industrial equipment may not support modern authentication, so auditing and preserving an individuals’ access depends on a separate access management and governance process that cannot be provided by the target asset..
Choose a completed visit and trace it from the initial login to the target asset using the records you retain. If an investigator needs to call the technician to establish who performed the work, that is a control worth examining.
2. Can They Reach Only the Equipment They Came to Service?
Return to the HMI at the water treatment plant. The OEM has permission to troubleshoot that device, but an administrator should be able to show which other destinations are available from the jump server. Rights left over from earlier projects or inherited from a group shared by several outside parties may extend well beyond the approved task.
Connectivity deserves attention alongside sign-in permissions. Someone may be prevented from logging in to a machine while still having a network path to it. Those are different controls, and a diagram of the intended architecture will not necessarily tell you how the environment behaves.
In a controlled test, attempt to reach a system outside the approved scope. The result should confirm whether the restriction is enforced.
3. Will the Permission Still Be Active Next Week?
A contractor finishes an upgrade on Tuesday, and their next visit is six months away. Can they still connect on Friday?
There may be a good reason to keep the connection available. The contractor provides emergency support under an ongoing agreement, in which case someone should own that decision. Sometimes, though, privileges remain because removing them is a separate task that nobody completed.
Operations has a practical concern here. If a pump fails at 2 a.m., nobody wants to spend an hour getting the OEM back in. Any change to approval or expiration needs to account for urgent work rather than making routine support harder to obtain.
Compare several recently closed work orders with the accounts that remain enabled. For each continuing permission, identify its current purpose and owner.
4. Does the Contractor Know the OT System’s Password?
A technician signs in with their own identity, then opens an engineering workstation using a shared password. Where did that credential come from, can the person save it, and does it change when the contract ends or the OEM assigns someone new?
Disabling the initial login does not take back a password that has already been disclosed. Some legacy equipment makes shared accounts difficult to eliminate, but the organization should still understand how those credentials are handled and what must happen when a working relationship ends.
Follow the password through a representative visit, from approval to sign-out and eventual offboarding. The important point is who can use it after the original task is complete.
5. Why Does the Contractor’s Laptop Need Network Connectivity?
Your security team may have little visibility into an OEM’s laptop. The person could be connecting from an office, a home network, or a temporary location. You may not manage that device, but you do control how it reaches your industrial environment.
Draw the full path from the laptop through the VPN and intermediary to the target equipment. Where does the remote protocol terminate? Which destinations can the endpoint communicate with? Is the interaction mediated by a gateway, or does the device receive direct connectivity to the protected network?
A technician needs to see and operate the HMI, but their laptop does not necessarily need a direct path into the plant to do that. The people responsible for the architecture should be able to explain how the connection works and show that the configuration supports their explanation.
6. Could You Reconstruct Yesterday’s Service Visit?
An unexpected configuration change is discovered in the morning after an OEM visit. You know someone connected because the login record confirms it, but can you establish what happened next?
Some environments provide detailed recordings and monitoring. Others retain connection logs but require investigators to gather information from several places. Give someone who was not involved in the work the available evidence and see whether they can identify the person, the equipment, the time, and the activity captured by your controls.
An independent reviewer should be able to reconstruct the relevant events without relying on the contractor’s recollection. If that requires manually matching records across several systems, document the process and determine whether it meets your investigative needs.
7. Will the Process Work During an Emergency?
Controls may look excellent during scheduled work, but what happens when a pump fails overnight, and the OEM needs to connect immediately? Who approves the request, how quickly can the repair begin, and can the connection be ended when the job is complete?
Run through the same scenario at a remote site with limited connectivity or an older system that cannot be modified. Operations should be involved because they know which requirements are essential, which equipment behaves differently, and where delays could affect the plant.
If legitimate maintenance becomes too difficult, the proposed process needs more work before rollout. Otherwise, people may continue using the older, easier, less secure and potentially noncompliant route.
What Do the Answers Tell You?
The exercise may confirm that your jump server is doing its job well. People are individually identified, destinations are restricted, permissions are maintained, and the necessary evidence is available. It may also uncover issues that can be corrected without replacing anything: unused privileges, an overly broad firewall rule, inconsistent credential handling, or an offboarding process without a clear owner.
Other findings may point to architectural limitations. Perhaps the intermediary has routes across an entire facility when a person needs only one machine. Perhaps each site maintains different accounts and approval procedures, or the organization cannot consistently associate an individual with activity on the target equipment.
Before changing the architecture, establish which controls need improvement and which limitations are built into the current approach.
Where Xona Fits
Xona provides secure access for critical infrastructure, connecting authorized users to the OT assets they need without giving their endpoints broad access to the OT network. For the water treatment plant, the OEM’s connection can be organized around the approved HMI rather than extending access to HMI’s network subnet.
Identity-based controls and applicable permission policies govern access. Session oversight and evidence capabilities depend on the Xona’s zero-trust remote access platform. If your assessment uncovers broad connectivity, inconsistent third-party privileges, or difficulty reviewing activity, bring those findings into a Xona evaluation and ask for a demonstration using your own workflows.
For a broader explanation of the architecture, see Xona’s jump server replacement glossary.
Explore the Xona platform
Written by Des Maris, Product Marketing Manager, Xona Systems
