BeyondTrust Hardening Guide: Securing Privileged Remote Access and API Keys

A privileged remote access appliance is an internet-facing gateway into your most sensitive systems, so its admin accounts, API keys and patch level decide whether it protects access or hands it out. The December 2024 compromise of BeyondTrust Remote Support SaaS, where a stolen infrastructure API key was used to reset local application passwords and reach US Treasury workstations, showed how much rests on these controls. This guide covers BeyondTrust Privileged Remote Access (PRA) and Remote Support (RS), on-premises appliances and cloud instances: group policies and admin permissions, authentication settings, API accounts, Vault credentials, syslog and outbound events, and patching. It is for PAM engineers, remote access owners and security teams, and uses BeyondTrust's public documentation only. Password Safe and Endpoint Privilege Management are out of scope.

Key takeaways

• Patch speed is a control. CVE-2024-12356 and CVE-2024-12686 in PRA and RS are both in the CISA Known Exploited Vulnerabilities catalogue, so automatic critical updates should be on unless you have a tested reason not to.
• API accounts are privileged identities. Each one has a client secret and per-API permissions (Command, Reporting, Backup, Configuration, SCIM and more), so give each integration its own account, the narrowest permissions and a network prefix restriction.
• Local accounts are the weak spot. BeyondTrust's own post-incident advice is to prefer SAML over local accounts, delete unused accounts and review administrator accounts.
• Restrict where the admin and API interfaces can be reached. Network restrictions on /login and /api cut the attack surface, but API accounts ignore the /login prefixes, so set their own prefixes too.
• Get the logs off the box. The appliance keeps logs for at most 90 days, so forward syslog over TLS and outbound events to your SIEM.

How identity and access work in BeyondTrust PRA and RS

Both products broker sessions from a representative or user console, through the appliance (the B Series appliance on premises, or a BeyondTrust-hosted instance), to endpoints reached through Jump Clients, Jumpoints or customer clients. Three identity paths matter:

• Users: representatives, administrators and vendors who sign in to /login (the admin web interface) and the access console. They can be local accounts or come from security providers such as SAML, LDAP or RADIUS, and their rights come from group policies.
• API accounts: OAuth client credentials used by integrations (ITSM, SIEM, backup scripts, SCIM provisioning) against /api.
• Vault credentials: the privileged endpoint credentials that PRA's Vault injects into sessions so users never see them.

The appliance itself also has an administrative interface at /appliance for networking, updates, certificates and syslog. Its accounts are separate from /login users and deserve the same protection. ATT&CK T1219 Remote Access Tools describes adversary use of remote access software; a hardened deployment makes sure the legitimate tool cannot be turned to that purpose through stolen accounts (T1078) or an unpatched public interface (T1190). See the Privileged Access Management Guide.

Admin roles and privileged access

Permissions are granted through group policies. A user can be in several policies; policies are evaluated in priority order and a permission marked Final cannot be overridden by a lower policy. Key permissions to control:

Authentication settings

Under the security settings in /login:

• Local passwords: the minimum password length defaults to 8; raise it and require complex passwords for any local account that must remain.
• Lockout: configure Account Lockout After and Account Lockout Duration (and, in PRA, Vendor Account Lockout After and Vendor Account Lockout Duration) to slow brute force (T1110).
• FIDO2: PRA supports passwordless FIDO2. Review the option Allow local users to skip 2FA when logging in with passwordless FIDO2 so it matches your MFA policy.
• Idle sessions: set Log out idle user after for the access console and Remove User from Session after Inactivity, with the idle warning enabled.
• Client surfaces: disable the Access Console CLI tool and the mobile or web console if you do not use them.

Vendor and third-party users

PRA is often how vendors reach your systems. Give vendor accounts their own group policies, the vendor lockout settings and Jump Item access limited to the systems in their contract, with session recording. See the Remote Access Identity Guide.

Integrations, API tokens and service accounts

API accounts are configured under Management > API Configuration. Each has an Enabled flag, a public client ID and a client secret that BeyondTrust generates with a cryptographically secure random generator. Disabling the account invalidates its OAuth tokens, and regenerating the secret also invalidates existing tokens.

• One account per integration: so revocation is surgical and logs attribute every call.
• Network prefixes: each API account has its own allowed network prefixes, and API accounts are not covered by the /login network restrictions. Set the prefix to the integration host's address.
• Secret storage and rotation: store the client secret in a secrets manager, regenerate it on a schedule and whenever someone with access leaves.
• Legacy XML API: disable the Enable XML API option unless an integration still needs it.

The Remote Support SaaS incident shows what one key can do. BeyondTrust's investigation found an infrastructure API key, reached through a zero-day in a third-party application in its AWS account, was used to reset local application passwords on 17 Remote Support SaaS instances; the key was revoked and instances quarantined on 5 December 2024. Read the BeyondTrust breach at the US Treasury for the timeline. The customer-side lesson: keys that can reset credentials need narrow scope, network binding and alerts on use, and local accounts reachable by a password reset should be the exception. See the API Key Management Guide.

Vault credentials

• Rotation: use Automatically Rotate Credentials after Check In Rules and Scheduled Password Rotation Rules for shared accounts; check the documented limits before rotating cluster service accounts.
• Personal Vault accounts: users can hold up to 50; review whether you want this feature and audit it.
• SSH certificates: the Vault SSH CA option issues short-lived certificates (5-hour time to live) instead of static keys.

Logging and detection

Under /appliance > Security > Appliance Administration you can send syslog to up to three servers in RFC 5424 or BSD format, with Syslog over TLS on TCP 6514 instead of the default UDP 514. The admin contact is alerted when the syslog configuration changes. The /login setting Days to keep logging information allows at most 90 days, so the SIEM is your long-term record. Outbound events can also push session and system events to HTTP endpoints (with a CA certificate for HTTPS and retries) or email.

Metrics:

• Days from a BeyondTrust security advisory to patched appliances (target: within the KEV due date or sooner; zero when automatic updates are on).
• Number of local accounts, and the share with MFA (target: only vaulted break-glass accounts).
• Percentage of API accounts with one owner, network prefixes and a secret rotated in the last 12 months.
• Percentage of privileged sessions with recordings ingested and sampled for review.
• Credential Used events with no matching change ticket.

Hardening baseline

1. Patch first: confirm the appliance version against BeyondTrust advisory BT24-10 (CVE-2024-12356 affects PRA and RS 24.3.1 and earlier; cloud instances were patched on 16 December 2024) and later advisories, and enable Apply Critical Updates Automatically in /appliance. Check current KEV entries for PRA and RS, which include CVE-2026-1731.
2. Inventory: export users, group policies, API accounts with their permissions and prefixes, Vault accounts and Jump Items.
3. Identity: move users to SAML with MFA in the identity provider, delete unused accounts, keep a minimum of vaulted local break-glass accounts, and review every account with Administrator or Set Passwords and Reset MFA.
4. Network: apply network restrictions to /login and /api (allow lists of admin networks), restrict /appliance and any unused ports, and set API account prefixes.
5. API accounts: split shared accounts, cut permissions to the minimum, disable the XML API if unused, vault and rotate secrets.
6. Least privilege: BeyondTrust recommends the Session Policy simulator to check what a user actually gets; use it to confirm System Jump Item roles and Vault Inject only.
7. Logging: syslog over TLS and outbound events to the SIEM, with the alerts above.

Testing and rollback: apply network restrictions with an allow-listed admin path verified first, change API permissions on one integration at a time, and keep a vaulted local Administrator able to sign in if SAML fails.

Decision guidance

• Cloud or on-premises: cloud instances are patched by BeyondTrust (which removes patch lag) but you depend on the provider's own key and infrastructure controls, as the 2024 incident showed. On-premises appliances give you control of network placement but put the patch burden on you.
• Automatic updates: automatic critical updates trade change control for speed. For an internet-facing remote access gateway with exploited flaws on record, speed usually wins; if you need approval, set a 72-hour emergency window.
• Small versus large teams: a small team may combine Administrator and Vault administration, in which case alert on every policy and API account change and have them reviewed by someone outside the team.

Incident readiness

Plan for the day the appliance or its provider is the problem, not just the tool you use to respond to one. Write down and test:

• Kill switch: who can disable all API accounts, block /login and /api at the network layer, and stop Jump Clients from connecting, and how long that takes.
• Credential reset order: regenerate every API client secret, reset local account passwords and MFA, then rotate Vault credentials that were injected during the suspect window, using the Vault account activity report to scope them.
• Evidence: SIEM copies of syslog and outbound events, session recordings and report exports, preserved before anything is rebuilt.
• Provider notices: a named contact who reads BeyondTrust security advisories and provider incident notices, and the authority to act on them the same day.

Common misconfigurations

• Delayed patching of an internet-facing appliance: CVE-2024-12356 allows unauthenticated command injection and is on the KEV list; appliances left on old versions stay exposed.
• Local accounts that a reset can take over: the SaaS incident worked by resetting local application passwords; SAML-only users would not have been reached that way.
• One API account for everything: full Command and Configuration API access shared across scripts, with no network prefixes.
• Backup API with Vault key access by default: backups that include the Vault encryption key become a copy of every privileged credential.
• Logs kept only on the appliance: 90 days at most, and no off-box copy if the appliance is compromised.
• Broad System Jump Item access: every representative can reach every system, which removes the point of brokering.

Framework mapping

Practitioner checklist

• Appliance on a version that fixes all KEV-listed PRA and RS flaws; Apply Critical Updates Automatically enabled or a 72-hour emergency window agreed.
• Users on SAML with MFA; unused accounts deleted; local accounts limited to vaulted break-glass.
• Administrator and Set Passwords and Reset MFA held by a small, reviewed group.
• Network restrictions on /login and /api; /appliance reachable only from admin networks.
• One API account per integration, minimum permissions, network prefixes set, secrets vaulted and rotated; XML API disabled if unused.
• Backup API Vault encryption key access granted only where justified.
• Vault Inject only for most users; rotation after check-in and scheduled rotation enabled.
• Syslog over TLS (TCP 6514) and outbound events to the SIEM, with alerts on account, policy, API and reset changes.
• Vendor accounts in their own policies, with lockout settings and session recording. See the Privileged Session Management Guide.

Standards and references

• BeyondTrust: PRA API Configuration
• BeyondTrust: PRA Security Settings
• BeyondTrust: PRA Group Policies
• BeyondTrust: Syslog
• BeyondTrust: Security Advisory BT24-10
• BeyondTrust: Remote Support SaaS Service Security Investigation
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: PAM Buyer's Guide · CyberArk Security Hardening Guide · Remote Access Policy Template · SailPoint Hardening Guide