Secure Unattended Access: Modern Alternatives to Legacy Jump Clients

A jump client sits on a server in your data center right now, connected and waiting, with no incident open and no technician working. That standing connection is the reach your unattended support depends on, and it never closes between sessions.

The decision you are making when you review that setup is not which unattended access tool carries more features. You are choosing which unattended access architecture your security team has to defend around the clock.

What a Jump Client Is and Why IT Teams Run One

A jump client is a software agent you pre-install on a device so a technician can reach it with no user present. BeyondTrust, formerly Bomgar, uses the term for these agents, and the client stays persistently connected to the vendor platform between every session.

Teams run jump clients because a large share of support work happens on devices with nobody in front of them. You reach the endpoints that cannot approve a session on their own:

• servers and infrastructure that need maintenance outside business hours
• kiosks and point-of-service terminals sitting unattended in the field
• digital signage and meeting-room machines that run without a keyboard

For support where the employee is present to approve the session, the model has already moved to session-only access, which just-in-time access covers in full. The rest of this post is about the unattended jobs that session-only model does not touch.

Why Legacy Unattended Access Runs Outside Your Platform's Control

The problem with a jump client is not only the agent on the device, it is where the whole system lives. Your legacy unattended tool runs its own console, its own credential store, and its own audit trail, all outside ServiceNow.

That separation weakens your security posture, because a standalone unattended tool adds attack surfaces your platform never sees:

• credentials managed in a system that bypasses your ServiceNow and Tanium security protocols
• audit records scattered across separate platforms, or missing where they should exist
• known vulnerabilities carried in from legacy tooling

Every one of those problems traces to the same root, which is unattended access provisioned as a separate product rather than a governed part of your platform.

A recent breach shows the blast radius of that architecture in practice. In December 2024, attackers compromised a key to BeyondTrust's Remote Support service and used it to reach United States Treasury workstations and unclassified documents, which pushed the department to take the tool offline. The incident hit a support tool rather than an unattended agent, and the principle behind it applies squarely to both. Concentrating always-on remote reach in a tool outside your governance turns that one tool into the target, and the reach it holds becomes the blast radius.

Why Adding Controls to a Standing Agent Does Not Remove the Risk

Most vendors answer the security question by stacking controls on top of the persistent agent. They tell you to require multi-factor authentication, encrypt the session, and log every action for later review.

Those controls harden the door, and you should still apply them, but they do not close the opening itself. The access path exists for as long as the agent stays installed, whether or not a ticket is ever raised. That standing path is a property of the architecture, not a setting your team forgot to switch off. You cannot configure your way out of a design that holds a connection open by default, which is the point zero trust network access for remote support makes in full.

What a Consolidated, Platform-Governed Unattended Model Looks Like

A modern unattended model does the opposite of a standalone tool, and brings unattended access inside the platform you already govern. Access runs natively in ServiceNow and Tanium rather than in a separate console bolted on beside them.

The consolidated model comes down to three properties that keep unattended access under your control:

• one security framework governs every unattended session, using the role-based permissions your team already maintains
• audit trails for unattended work live inside ServiceNow and Tanium, not in a vendor portal you reconcile later
• unattended reach is scoped through device grouping, rather than a blanket agent installed across the entire fleet

Governing attended and unattended access under one framework removes the separate console, the external authentication, and the extra vendor a standalone tool forces on you.

How to Deliver Unattended Access Inside ServiceNow and Tanium

ScreenMeet delivers unattended access through Beam, a paid add-on to ScreenMeet Support built for devices with no user present. You use Beam to reach the same infrastructure a jump client covers, from servers to kiosks to remote employee machines.

The difference from a jump client is how that access is governed inside your platform:

• each device registers to a Beam Group through a unique group key, and the group controls who can reach it
• unattended sessions run inside ServiceNow and Tanium, so they inherit your platform permissions and write their audit trail to the record
• session data captured in the platform can feed automation and knowledge base entries that improve self-service over time

Beam does install a client on each unattended device, so the honest difference here is not the absence of software. The difference is that your unattended access stays scoped to groups and governed inside the platform, instead of running from an always-on console your security team cannot see.

Questions to Ask Before You Replace Your Jump Client Setup

Take these questions into any vendor conversation about unattended access, and the answers separate a governed model from a standalone one:

• Where is unattended access governed: inside ServiceNow and Tanium, or in a separate console with its own credential store?
• Is unattended reach scoped to defined device groups, or granted across the whole fleet at once?
• Does unattended session activity land in your ServiceNow or Tanium record, or in a portal you reconcile during an audit?

A vendor whose answers keep unattended access inside your platform is describing a governed model, not a standalone agent with controls added on top. That is the model that replaces the jump client without recreating the standing risk you set out to remove.

Legacy jump clients concentrate standing access in a tool your platform never sees, and a consolidated model closes that gap. See how ScreenMeet runs unattended access natively inside ServiceNow and Tanium, and bring the questions above to your next security review.

Frequently Asked Questions

1. What Is a Jump Client in Remote Support?

A jump client is a software agent pre-installed on a device so a technician can reach it with no user present. BeyondTrust, formerly Bomgar, uses the term for the persistent agents that keep unattended endpoints reachable between support sessions.

2. Are Jump Clients a Security Risk?

A jump client keeps an access path open on the device for as long as the agent stays installed, whether or not a ticket is open. That standing reach expands your attack surface and sits outside your platform governance, which is why InfoSec teams now treat it as an architectural risk rather than a configuration detail.

3. How Do You Handle Unattended Remote Access for Servers and Kiosks Securely?

You scope unattended access to defined device groups and govern it inside ServiceNow and Tanium, rather than installing a blanket agent across the entire fleet. Access then inherits your platform permissions, and the audit trail writes back to the record your team already reviews.

4. What Is the Alternative to BeyondTrust Jump Clients for ServiceNow Teams?

ScreenMeet Beam delivers unattended access embedded in ServiceNow and Tanium, scoped through device groups and governed by your platform permissions. Beam installs a client for genuinely unattended devices, but keeps that access inside the platform instead of a separate console outside your control.

‍