Enable and configure Vault for credential injection

Privileged Remote Access A workflow for Privileged Remote Access

Audience: IT administrator

Scope of this guide

This workflow shows you how to enable and configure the built-in Vault in Privileged Remote Access (PRA) to store privileged credentials and inject them directly into sessions. Once configured, users can connect to protected systems without ever seeing or handling the password. PRA injects the credential on their behalf.

Prerequisites

  • You have administrator privileges in PRA on the BeyondTrust Pathfinder platform.
  • PRA is licensed and active on your Pathfinder site.
  • The target endpoint has a Jump Client installed as an elevated service, or is reachable through a Jumpoint.
  • You have the username and password for the privileged account you want to store in Vault.

Why is this important

Shared privileged credentials are a common attack target. When users handle passwords directly, there is a risk of exposure through screenshots, shoulder surfing, or reuse across systems. Vault eliminates that risk by storing credentials centrally and injecting them into sessions automatically. Users get access to the systems they need without ever seeing the password.

Steps summary

StepAction
1Grant Vault admin permission to the managing user
2Configure Vault global options
3Create an account policy
4Add a shared Vault account
5Create an account group and assign users
6Inject credentials during a session

Steps

Step 1: Grant Vault admin permission to the managing user

Assigns the Allowed to Administer Vault permission and a reporting level to the user who will manage Vault.

Why this step matters

Without this step, no one outside of a full PRA administrator can add, edit, or manage Vault accounts. Credential management would be locked to a small group of super-admins, creating a bottleneck or, worse, forcing teams to share admin credentials to get work done.

How to

  1. Sign in to app.beyondtrust.io. The BeyondTrust Home page displays.
  2. From the main menu, select Privileged Remote Access > Users & Security > Users. The User Account page opens.
  3. Locate the user you want to grant Vault access to, and select the Edit (pencil) icon.
  4. Select the General Permissions section to expand it.
  5. Under Administration, check Allowed to Administer Vault.
  6. Under Reporting, select a value from the Allowed to View Vault Reports dropdown. Select View All Events to allow the user to see all Vault activity.
  7. Select Save.
ℹ️

Users with administrator privileges in PRA automatically have Allowed to Administer Vault and Allowed to View Vault Reports - View All Events. For all other users, you must configure these permissions explicitly.

Step 2: Configure Vault global options

Sets the default rules for password rotation, auto-rotation on check-in, simultaneous checkout, and generated password length across all Vault accounts.

Why this step matters

These defaults form the security baseline for every account in Vault. If no policy or group overrides them, every credential falls back here. Setting strong defaults, like auto-rotation after check-in and a minimum 20-character password length, ensures that accounts you haven't explicitly configured still meet your security requirements.

How to

  1. From the main menu, select Privileged Remote Access > Vault. The Vault page opens on the Accounts tab.
  2. Select the Options tab. The Global Options page displays.
  3. Under Automatic Password Management, set Scheduled Password Rotation Rules to Allow if you want passwords to rotate automatically after the maximum password age. Set the Maximum Password Age in days.
  4. Under Account Settings, set Automatically Rotate Credentials After Check In Rules to Allow if you want passwords to rotate each time an account is checked back in.
  5. Set Allow Simultaneous Checkout Rules to Deny if you want to prevent multiple users from checking out the same credential at the same time.
  6. Under Password Length, set the minimum and maximum character counts for generated passwords. The minimum is 20 characters.
  7. Select Save.

Step 3: Create an account policy

Defines a named, reusable set of rotation and checkout rules that can be applied to specific accounts or groups.

Why this step matters

Not all privileged accounts carry the same risk. A domain admin account needs tighter controls than a generic service account. Account policies let you apply the right rules to the right accounts without reconfiguring each one individually, reducing administrative overhead and preventing configuration drift.

How to

  1. In Vault, select the Account Policies tab.
  2. Select Add. The Add Account Policy page displays.
  3. In the Name field, enter a name for the policy.
  4. In the Description field, enter a brief description.
  5. Under Permissions, set your Scheduled Password Rotation Rules, Automatically Rotate Credentials After Check In Rules, and Allow Simultaneous Checkout Rules values.
    • Set each to Not Defined to inherit from the global default, or set Allow or Deny to override.
  6. Select Save.

Step 4: Add a shared Vault account

Stores a privileged credential (username, password, and target endpoint) inside Vault where it is encrypted and access-controlled.

Why this step matters

This is the core act of removing the password from human hands. Once the credential lives in Vault, no user needs to know or type it. It can be rotated automatically, audited centrally, and injected into sessions without ever being exposed in plain text.

How to

  1. In Vault, confirm you are on the Accounts tab and the Shared sub-tab is selected.
  2. Select Add. The Add Account page displays.
  3. In the Name field, enter a unique name for the account.
  4. In the Username field, enter the username for the privileged account.
  5. In the Password field, enter the password.
  6. In the Description field, enter a brief description.
  7. In the Endpoint field, associate this account with the target endpoint if applicable.
  8. In the Account Policy field, select the policy you created in Step 3, or leave it set to Inherit Policy Settings to use the global default.
  9. Select Save.

Step 5: Create an account group and assign users

Groups shared accounts together, applies a policy to them, and grants specific users either inject-only or inject-and-checkout access.

Why this step matters

This step controls who can use which credentials and in what context. Without it, stored credentials are inaccessible to session users. The role distinction, inject versus inject-and-checkout, also enforces least privilege: most users only need to inject during a session and should never be able to extract the credential outside of one.

How to

  1. In Vault, select the Account Groups tab.
  2. Select Add. The Add Account Group page displays.
  3. In the Name field, enter a name for the group.
  4. In the Description field, enter a brief description.
  5. In the Account Policy field, select a policy or leave it set to Inherit Policy Settings.
  6. Under Accounts, select Default Group from the Source Account Group list. Locate the account you created in Step 4, and select Add to move it to the Accounts in This Group list.
  7. Under Allowed Users, locate the user who will inject credentials during sessions. Select their role from the New Member Role dropdown:
    • Inject: the user can inject the credential during a session.
    • Inject and Checkout: the user can also check out the credential manually outside of a session.
  8. Select Add to add the user to the group.
  9. Under Asset Associations, select whether the account is available for all assets or only specific ones.
  10. Select Save.

Step 6: Inject credentials during a session

The user connects to an endpoint in the Access Console, selects a Vault account from a dialog, and PRA enters the credential into the Windows login screen automatically.

Why this step matters

This is where the security investment pays off. The user gets access to the system they need, the session is recorded and audited, and the password is never visible at any point in the workflow. Even if the user's workstation is compromised, there is no password to capture. PRA handled it entirely in the background.

How to

  1. Sign in to the Access Console.
  2. In the Assets list, locate the target endpoint and start a session.
  3. Select the Play button to begin screen sharing. If the endpoint is at the Windows login screen, the Inject Credentials button is highlighted.
  4. Select Inject Credentials. A credential selection dialog appears, listing the Vault accounts available to you.
  5. Select the appropriate account from the list. PRA retrieves the credential from Vault and injects it into the Windows login screen.
  6. The session proceeds and you are logged in to the endpoint. You never see the password at any point.
ℹ️

If a credential is used to start a session, its name appears in the session queue. This lets you identify which credential is in use and reuse it for subsequent sessions with the same endpoint.

Verify the results

Verify that the endpoint login screen accepts the injected credential and the session opens successfully. Confirm that the credential name appears in the session queue and that the password was not displayed to the user at any point during the process.

Next steps

  • Review session recordings to confirm credential injection activity is logged: Reports > Session Reports
  • View Vault activity reports to audit credential usage: Reports > Vault Reports
  • Set up discovery to automatically find and import accounts from Active Directory or other sources: Vault > Discovery

Related resources

©2003-2026 BeyondTrust Corporation. All Rights Reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.