BeyondTrust Support Session Policies


A session policy is a configurable, reusable set of rules that defines which tools and actions are available in a support session. Session policies allow administrators to customize support session permissions to fit specific support scenarios, and can be applied to users, public sites, and all Jump Items. With session policies, a support representative's effective permissions granted and restrictions applied are dynamic, based on criteria other than just that representative's user permissions.

Session policies apply permissions not only to the representative but also to Jump Items and support portals, and by extension to Support Buttons, Jumpoints, and local Jumps.


Using session policies, representatives can be given different permissions for different scenarios. The tools available to a representative and the prompts the customer sees can vary from session to session based not only on the representative account but also on whether the session is customer-initiated or Jump session, on the support portal through which the session started, and on the specific Jump Item. By strategically applying policies, you can set how permissions work in numerous scenarios.


Some end-users may be in environments that require stricter security than is required by other end-users. With session policies, you can comply with rigid security requirements without sacrificing use of your full tool set for less-restricted end-users. By assigning separate session policies for different customer support portals, you can adjust the security level based on your clients' needs.

Session Policy Use Cases

Diverse Group of Clients

In this use case, your organization supports a diverse group of clients. Among your clients are a warehouse and a bank, which have very different security requirements. The primary support goal of the warehouse is for you to resolve their issues as quickly as possible, which means that they want you to have full control of their systems with only one prompt. On the other hand, the bank's primary goal is security, which means they want you to have view-only access and to prompt for each permission.

While you could assign specific representatives to handle each client, doing so would be an inefficient use of your support staff. It is more effective to allow your entire support staff to interact with all of your clients.

With session policies, a representative can handle sessions with permissions assigned from the support portal through which the session originated. Configure session permissions for the warehouse in one policy and permissions for the bank in another. Then apply the first policy to the warehouse portal and the second policy to the bank portal. Now, any session coming through the warehouse portal has the warehouse permissions applied, and any session coming from the bank portal has the bank permissions applied.

These portal-specific permissions override representative permissions. Any undefined permissions fall through to be defined first by representative permissions and then by the global default session policy.

Desktop and Server Jump Clients

In this use case, you have a number of Jump Clients installed on two different types of machines: servers and end-user computers. Company policy requires that end-users are always prompted before representatives can gain access. However, prompting prohibits access to servers because no end-user is there to respond to the prompt.

Configure two session policies: one that requires prompting and one that never prompts. Apply the first session policy to end-user Jump Clients and the second to server Jump Clients. Now, when a representative Jumps to an end-user system, the user is prompted for permission. When the same representative Jumps to a server, no prompting occurs.

These Jump Client-specific permissions override public portal permissions and representative permissions. Any undefined permissions fall through to be defined first by public portal permissions, then by representative permissions, and finally by the global default session policy.