Part 4 · Assets & Jump Technology
Vault: Credential Injection & Rotation
Module 15 got a rep to the target over an outbound-only tunnel. This module closes Part 4 by asking the next obvious question: what happens to the actual password? BeyondTrust Vault stores privileged credentials, injects them straight into the session, and rotates them afterward — the rep drives the endpoint without ever seeing, typing, or copying the plaintext.
The problem Vault exists to solve
Every asset from Module 14 eventually needs a username and password (or an SSH key, or a token) to actually authenticate against the target. The naive way to handle that is to just tell reps the password — email it, put it in a spreadsheet, paste it into a ticket. That approach fails the moment you care about two things auditors always ask about: who knows this credential right now, and can we prove nobody misused it. BeyondTrust Vault is PRA's built-in answer: a credential store on the appliance that holds privileged account secrets and hands them to a session directly, without ever surfacing the plaintext to the person driving the keyboard.
Vault accounts come in several flavors — generic username/password accounts, SSH accounts (including SSH Certificate Authority accounts that mint a fresh certificate and private key per use), and discovered accounts pulled in from AWS Secrets Manager or BeyondTrust Password Safe. Shared accounts can be used by any user granted access to them; personal accounts are scoped to a single owner, who can create up to 50 of their own.
Credential injection: the rep never touches the password
Injection is the mechanism that makes "the rep never sees the password" actually true. When a session on an RDP, Shell, or Website asset is configured to use a Vault (or Endpoint Credential Manager) account, the rep picks the credential by name from a list in the access console — never by value. The appliance retrieves the secret from Vault and delivers it directly into the login prompt of the target: a Windows logon box, an SSH auth exchange, or an auto-detected username/password field on a web login page. The credential name shows up in the session queue so the rep can tell at a glance which account is in use, but the characters of the password itself never render on screen, never land in the clipboard, and are never something the rep could read off and reuse elsewhere.
This works across every major asset type covered in Module 14: RDP sessions can inject Windows credentials (including through the BeyondTrust Remote Desktop Agent for RemoteApp/SecureApp launches); Shell sessions can inject SSH credentials, including a SUDO variant where a Linux endpoint is preconfigured with functional accounts in /etc/sudoers so the rep runs specific commands as root without ever holding root's own password; and Website assets can inject into HTML login forms, with auto-detection of the username/password fields (or admin-specified HTML id/name/CSS selectors when auto-detection isn't reliable) — including multi-step logins and CAPTCHA-gated pages.
The rep's channel and the credential's channel are architecturally separate. The rep sends session control input (mouse, keyboard, commands); the appliance independently pulls the secret from Vault and writes it into the target's authentication prompt. Because the plaintext password is never routed through anything the rep's screen renders, a compromised rep workstation, a careless screen-share, or a shoulder-surfing incident can't leak the credential — there's nothing on that side of the boundary to leak.
Encryption: at rest and in transit
Vault credentials are encrypted at rest using AES-256-GCM, in addition to whatever full-disk encryption is enabled on the B Series Appliance itself — a compromise of the underlying disk still doesn't hand over readable secrets. In transit, passwords and private SSH keys used for injection are further protected with an ephemeral public/private key pair generated for that specific use, layered on top of the TLS that already encrypts every Secure Remote Access component's communication. Passwords a Gateway uses to authenticate against Active Directory are never sent in plaintext to Active Directory either. The Vault encryption key itself — needed to decrypt any stored credential — lives in one of the appliance's configured credential stores, and admins can back it up separately from Management > Software > Backup Vault Encryption Key.
Checkout: when a human actually needs the value
Injection covers "use this credential in a session." Sometimes a rep legitimately needs the raw value — logging into a system outside of a PRA-brokered session, for instance. That's what account roles are for. Every user granted access to a Vault account gets one of two roles:
| Role | What it allows |
|---|---|
| Inject | Default. The user can use the account in Secure Remote Access sessions via injection, but cannot see or retrieve the raw credential value. |
| Inject and Checkout | Everything Inject allows, plus the ability to check the account out (e.g., via Support for Admins) and view the actual credential — displayed in a dialog the user can copy from. Has no effect on generic SSH accounts, which don't expose a raw value to check out the same way. |
Checked-out credentials can be locked against simultaneous use: if an account's policy denies simultaneous checkout, a second user sees it grayed out with a lock icon and a note about who currently holds it. That locking behavior applies to domain, local generic, AWS Secrets, and Password Safe accounts — it does not apply to personal or SSH vault accounts. SSH Certificate Authority accounts follow their own rule entirely: a fresh certificate and private key pair is generated for every single checkout or injection, valid for five minutes, so there's nothing persistent to lock or check back in.
Rotation: closing the loop after use
Injection and checkout answer "how does the rep use the credential without seeing it." Rotation answers "how do we make sure that credential is worthless to anyone who somehow did see it." Vault supports rotation on two triggers, both configured through account policies (with global defaults on the Vault Options page, inherited by account group, then by individual account):
- Scheduled rotation — a maximum password age (in days) after which Vault automatically rotates the credential, regardless of whether it was ever checked out.
- Automatic rotation after check-in — when enabled, the password is rotated the moment a checked-out credential is checked back in, so the value the rep just used becomes immediately invalid for reuse.
Generated replacement passwords have a configurable length — 20 to 256 characters for domain and local accounts (password length settings don't apply to SSH or personal accounts) — and for Entra ID Domain Services accounts, rotation happens through the MS Graph API rather than the Windows API used for on-premises domain accounts. Settings resolve in a strict order: the account's own policy wins first, then its account group's policy, then the global default policy — exactly the same inheritance pattern Module 12 covered for Asset Policies, just applied to credentials instead of connections.
Treating Vault as just "a place where passwords are stored" instead of an injection-and-rotation system is the classic mistake. Simply parking a domain admin password as a shared generic account, without ever granting Inject and Checkout deliberately or turning on rotation-after-check-in, means anyone with access can retrieve and reuse the plaintext indefinitely — you've built a shared password manager, not a privileged access control. The security value of Vault comes from the combination: default to Inject so most users never see the value at all, reserve Inject and Checkout for the narrow cases that genuinely need it, and enable rotation so any credential that was exposed has a short shelf life.
Where this leaves you
Vault closes the credential half of the story that Jump Technology opened in Module 15: the transport gets the rep to the endpoint, and injection gets the endpoint its login without the rep ever holding the password, with rotation making sure a credential's exposure window is measured in a single use rather than forever. Everything up to this point in Part 4 — Asset Roles, Asset Policies, Asset Groups, Assets themselves, Jump Technology, and now Vault — governs what a rep can reach and how they authenticate to it. Part 5 picks up where connectivity and credentials leave off: Module 17, Session Policies, governs what a rep is actually allowed to do once that authenticated session is live — screen sharing, file transfer, clipboard, recording, and the rest of the in-session permission model.