How to Modernize Secure Remote Access in OT: 5 Limitations of Jump Servers

Why Jump Servers No Longer Meet OT Remote Access Needs

For years, jump servers have been the default answer for enabling remote access to operational technology (OT) environments and cyber-physical systems (CPS). They offered a simple promise: funnel all remote connections through a controlled point to reduce risk.

And for a time, that worked.

But OT environments have changed. Remote access is no longer occasional – it’s constant. Vendors, engineers, and internal teams all need fast, reliable access to critical systems, often under time pressure. At the same time, cyber threats have become more targeted, more sophisticated, and far more disruptive to physical operations.

Against this backdrop, many industrial organizations are starting to notice an uncomfortable truth: jump servers may create a sense of control, but in practice they introduce blind spots, over-permissioned access, and operational friction.

What is a Jump Server?

A jump server (also called a jump host or bastion host) is a hardened intermediary system used to access restricted environments.

Instead of connecting directly to a critical system, a user first connects to the jump server. From there, they initiate a second connection to internal assets such as HMIs, PLCs, or engineering workstations.

In effect, the jump server acts as a controlled gateway between two security zones.

How Jump Servers Work in OT Environments

A jump server sits between:

• An external or less-trusted network (such as the internet or corporate IT)

• A protected internal network (such as an OT environment)

To access internal systems, users typically:

1. Authenticate to the jump server

2. Launch a remote session (RDP, SSH, VNC, etc.)

3. Connect from the jump server to the target system

All accessible systems must be reachable from the jump server itself, making it a central access point for remote operations. 

Remote OT Access: Jump Servers vs. VPNs

Jump servers are frequently used alongside VPNs, but they serve different roles:

• A VPN creates a tunnel into the network, making the user’s device behave as if it is inside the environment

• A jump server provides controlled access within that environment to internal systems

In many OT environments, a VPN provides initial network access and then a jump server provides the last mile to critical assets. This layered approach can improve segmentation, but it still relies on network-level access rather than granular, identity-based control.

Where the Jump Server Model Breaks Down in OT

Jump servers are intended to improve security by:

• Limiting direct exposure of critical systems

• Centralizing access through a single controlled point

• Providing a monitored entry layer into sensitive environments

By reducing the number of exposed entry points, jump servers shrink the attack surface. Instead of attackers scanning and targeting multiple systems, they now have a single gateway to go through. But that one gateway becomes a high-value target.

If a jump server is compromised – whether through stolen credentials, misconfiguration, or an unpatched vulnerability – it can provide a direct path to numerous critical systems behind it. In other words, you’ve reduced the number of doors, but have made one door significantly more important to protect.

Equally notable, the jump server model focuses on where access happens – not how access is controlled. And once a user connects, the boundaries aren’t always as tight as they seem.

A connected user might:

• See multiple systems sitting behind the jump server, even if they only need one

• Move between machines without additional verification

• Run commands or make changes without real-time oversight

So while the entry point is controlled, what happens next often isn’t.

In other words, jump servers answer one question well: “How do we get users in safely?”

But they leave a more important one only partially addressed: “What are they allowed to do once they’re inside?”

And in OT environments – where a single command can impact physical processes – that gap can have serious real-world consequences.

Top 5 Challenges with Jump Servers in OT Environments

1. Jump Servers Cannot Enforce Least Privilege Access

The principle of least privilege is straightforward: users and devices should only have access to the specific resources they need to perform their tasks. In OT environments, this isn’t just a best practice – it’s a critical safeguard against malware propagation, system misuse, and unintended operational impact.

Unfortunately, jump servers make the principle of least privilege difficult to enforce.

Because a jump server acts as a central access point, users who connect to it typically gain visibility into all systems reachable from that server. In effect, access is determined by what’s available behind the jump server – not by identity or actual need.

This creates a tradeoff: teams can load multiple assets onto a single jump server, which simplifies operations but increases risk by expanding user access beyond what’s necessary. Or they can restrict each jump server to a single asset, which improves security but quickly becomes difficult to scale and manage.

Most organizations end up somewhere in between, balancing security and practicality but rarely achieving true least privilege access.

How Cyolo Helps: Application-Level Access Restricts Potential Harm

The Cyolo PRO (Privileged Remote Operations) access solution is designed to connect identities to applications – not users to networks. Following identity verification, access is granted at the application level, in full accordance with the principle of least privilege.

Cyolo PRO also enables granular access policies far beyond what jump servers can support. This means greater control over access and a significantly reduced blast radius if credentials are compromised.

2. Jump Servers Provide Limited Visibility and Control Over Remote Connections

Most jump servers do a decent job protecting the front door. They can confirm who authenticated and when. But once the session starts, visibility drops off.

Did the user run a risky command?
Did they move files they shouldn’t have?
Did they access systems outside their intended scope?

In many cases, it’s simply impossible to know.

Once connected, most jump server implementations provide little if any visibility into user activity. Security teams often cannot see which systems were accessed, what commands were executed, or whether risky actions – such as file transfers or configuration changes – took place.

It’s similar to badge access in a facility: you know who entered the building, but not which rooms they accessed or what they did once inside.

Another major limitation is the inability to intervene. Jump servers offer no consistent way to:

• Enforce just-in-time (JIT) access

• Restrict specific actions during a session

• Terminate a session in real time if unusual or suspicious behavior is detected

The result is a potentially dangerous gap between access control and activity control.

How Cyolo Helps: Granular Controls Across the Entire Session Lifecycle

With Cyolo PRO, access isn’t just granted – it’s continuously controlled. Sessions can be actively monitored, recorded, and even stopped mid-stream if something looks off.

Key connectivity and supervisory controls include:

• Continuous authorization (not just point-in-time authentication)

• Just-in-time (JIT) access

• Supervised access and session recording with Session Intelligence

• Granular activity controls (e.g., block file transfers)

• Real-time session termination

• Logging and auditing for compliance

These capabilities ensure that remote access is not just secure at the point of entry but throughout the entire session lifecycle.

3. Jump Servers Pose a High Operational Burden

Jump servers are not a “set it and forget it” type tool. In practice, they require continuous management.

Admins must maintain the systems themselves – loading required assets, applying patches, and keeping configurations up to date. In IT settings, these tasks can often be automated. But in OT environments, where change is more sensitive and resources are constrained, they are frequently handled manually (if at all).

Over time, this creates drift. Patches are delayed. Configurations become inconsistent. And the jump server – originally introduced to reduce risk – can itself become another point of exposure.

How Cyolo Helps: Remove the Conflict Between Security and Operational Agility

It’s often assumed that stronger security requires more operational overhead.

Cyolo PRO challenges this assumption. As an agentless solution that is simple to deploy, configure, and manage, Cyolo PRO improves both security and operational agility – without adding complexity, disruption, or risk.

Learn more about how Cyolo PRO makes life easier for IT and security teams.

4. Jump Servers Face Serious Scalability Challenges in Distributed OT Settings

As OT environments grow, remote access requirements expand across users, systems, and sites. But with jump servers, scaling securely is not straightforward.

To enforce tighter access control, organizations must increase segmentation – which generally means deploying more jump servers. Each additional system introduces overhead: more configuration, more patching, more monitoring.

To reduce this burden, teams may consolidate access across fewer systems – but this broadens access and weakens security. The result is a structural tension between security and scalability.

Ultimately, most organizations are forced to choose between managing a growing number of systems and accepting wider access than they would prefer. For already overworked teams seeking to protect the most critical assets in their organization, both options are far from ideal.

How Cyolo Helps: Security That Scales with the Business

Cyolo eliminates this tradeoff.

Instead of scaling infrastructure, organizations using Cyolo PRO can scale policy. Identity-based access controls can be applied consistently across users, assets, and sites – enabling remote access without increasing operational complexity or adding security risk.

5. Shared Accounts on Jump Servers Reduce Accountability and Traceability

OT systems were typically not designed with modern identity management in mind. As a result, shared accounts remain common – especially for third-party access.

Even with a jump server in place, the underlying issue remains.

When multiple users connect using shared credentials, it becomes difficult to determine:

• Who accessed the system

• What actions were taken

• When those actions occurred

This lack of traceability slows incident response and complicates investigations – particularly in environments where downtime has immediate financial or safety implications.

Shared accounts also introduce persistent risk. Former employees or contractors may retain access long after it should have been revoked.

How Cyolo Helps: Identity-Based Access Ensures Accountability

With Cyolo PRO, every session is tied to a verified identity – even when using shared accounts.

This ensures full traceability, stronger accountability, and faster, more complete incident response. At the same time, built-in credential vaulting allows passwords to be securely injected without being exposed to users, further reducing the risk associated with shared accounts.

A Summary: Jump Servers vs. Cyolo PRO for Remote OT Access

Modernizing OT Remote Access: From Network Access to Identity-Based Control

Jump servers were designed for an era when controlling access to the network was enough to ensure security. But OT environments, and the threats targeting them, have evolved.

Modern industrial organizations need more than a controlled entry point. They need to control who can access what – and what they can do once they’re inside. This means moving beyond network-based access toward identity-based, application-level access that enforces the principle of least privilege, provides full visibility, and enables real-time control.

This new approach also requires rethinking a long-standing assumption: that better security requires more complexity. The reality is the opposite. Modern OT secure remote access should be simpler to manage, easier to scale, and stronger by design – without requiring infrastructure changes or exposing sensitive data.

Because in OT, secure access isn’t just about keeping threats out. It’s about maintaining visibility and control every step of the way.