Privileged Remote Access (PRA) Fundamentals: — Vendor Access Without the VPN

① The vendor-access problem: a VPN grants a network, the vendor needs an app

Sneha runs the quarterly access review at Infosys for a banking client. The spreadsheet has a row that should scare you: vendor_dbsupport, a shared credential used by an outside database vendor, attached to a VPN profile created in 2021. Three engineers at the vendor have changed jobs since. Nobody at the client knows which humans can still log in, and the VPN logs only show an IP address from a hotel in Pune. The contract says the vendor maintains one billing application. The VPN's route table says they can reach the entire 10.20.0.0/16.

That mismatch is the whole problem in one line: a VPN grants a NETWORK; the vendor only needs an APP. The classic patch-up is a jump server in the middle — but the jump server itself becomes a shared, credential-rich pivot box, and the access is still network-shaped: once you are on it, you hop wherever its routes and firewall rules allow. Add a flat network and one stolen vendor password becomes a master key.

The textbook case is the 2013 Target breach. Attackers phished a small HVAC (air-conditioning) vendor, stole its credentials for Target's vendor portal, and then — because the vendor's access was network-shaped and the internal network was poorly segmented — walked from a billing/portal foothold all the way to the point-of-sale estate. Roughly 40 million payment cards were skimmed. Note what the pattern needed: no zero-day on the POS, just vendor creds + a network-level grant + a flat network. The US Senate's "Kill Chain" analysis of the incident became required reading for every access architect.

The 2024 sequel made the same point from the other side: in December 2024, attackers (attributed to the Chinese state group Silk Typhoon) stole a BeyondTrust Remote Support SaaS API key and used it to reset application passwords, reaching 17 SaaS customers including the US Treasury. The same window produced CVE-2024-12356 (CVSS 9.8, unauthenticated command injection in RS/PRA, patched in 24.3.1). Two lessons for this series: third-party access tooling is itself Tier-0 attack surface, and machine credentials (API keys) need rotation, scoping and monitoring just like human ones. We will keep returning to both.

② What PRA is: the Bomgar-lineage appliance that dials out on 443

Privileged Remote Access (PRA) is BeyondTrust's product for exactly this job: brokering vendors, remote admins and operational-technology engineers to specific systems — without a VPN, without inbound firewall holes, with every session recorded. Its lineage matters in interviews: PRA (and its sibling Remote Support) descend from Bomgar, which merged with BeyondTrust in 2018 and kept the BeyondTrust name. Old-timers still call the appliance "the Bomgar box", and the appliance still fetches updates from btupdate.com and opens support tunnels to gwsupport.bomgar.com.

Deployment comes in two shapes. On-prem: a B-Series appliance, physical or virtual, with the docs recommending placement in the DMZ — it needs a dedicated IP, a DNS record and a CA-signed certificate. Cloud: PRA Cloud, the SaaS form, where BeyondTrust hosts and patches the site for you. Remember from the December 2024 incident timeline: cloud instances were auto-patched on 16 Dec, while on-prem teams had to apply the fix themselves through the /appliance interface. Whichever shape you run, the client-side story is identical.

The docs state it in one line worth memorising: the connection from each client is an outbound connection from the computer to the B Series Appliance, and "the only required ports are 80 and 443". The user runs an access console (desktop app, or the browser-based Privileged Web Access Console with near feature-parity) and dials the appliance on TCP 443. On the target side, either a per-endpoint Jump Client agent or a one-per-LAN Jumpoint (renamed Gateway in newer Pathfinder docs) has already dialled out to the same appliance. The appliance authenticates both sides, applies policy, then splices the two outbound legs into one session. RDP 3389 or SSH 22 only ever flow on the short internal leg from the Jumpoint to the target — never across the internet. Lesson 11 dissects Jump technology in depth; today you only need the dial-out idea.

openssl s_client -connect pra.icici-lab.in:443 -brief

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = pra.icici-lab.in
Verification: OK

Four anchors before we compare products

Tap each card — these four keep every later lesson honest.

③ PRA vs Remote Support vs VPN vs Password Safe — the architect's decision

BeyondTrust sells two remote-access products off the same appliance lineage, and your company already owns a VPN and (if you followed lessons 1–9) Password Safe. Mixing them up is the most common early-career mistake — and a frequent interview filter. Remote Support (RS) is for the helpdesk: representatives fixing end users' devices, with chat, a public support portal, and typically concurrent (shared-pool) rep licensing. PRA is for privileged humans reaching infrastructure: vendors and admins jumping to servers, switches and web consoles, with Vault credential injection and named-user licensing (a per-asset SKU also exists). Same DNA, different humans, different licence math.

Then there is Password Safe's session proxy — the one that confuses everyone, because it ALSO gives recorded RDP/SSH without exposing passwords. The difference is the centre of gravity. Password Safe is vault-first: an internal admin requests a credential, an approval workflow releases it, and the session rides the PS proxy on ports 4422 (SSH) / 4489 (RDP), with rotation on check-in. PRA is access-first: built for third parties and remote engineers who must cross the network boundary, with vendor onboarding, per-app Jump Items and the dial-out appliance. PRA even carries its own built-in Vault (up to 100,000 accounts) so injection works without Password Safe — and the two integrate (via the Endpoint Credential Manager, or directly since PRA 25.3) when you want the full platform.

Here is what the Password Safe lane looks like in practice — an internal Infosys admin reaching a switch through the PS proxy, never learning the rotated password. Notice the port and the stacked identity in the connection string:

ssh -p 4422 sneha.r+netadmin@icici.in+coresw01@ps.icici-lab.in

sneha.r+netadmin@icici.in+coresw01@ps.icici-lab.in's password:
*** This session is being recorded ***
Last login: Tue Jun 09 21:14:08 2026 from 10.20.4.15
netadmin@coresw01:~$

And the VPN? It keeps its honest jobs: site-to-site links between offices, and broad network access for managed employee laptops where the device itself is trusted and instrumented. The decision rule an architect actually uses: end-user device being fixed → Remote Support. Third party or remote human touching infrastructure → PRA. Internal admin needing checkout + approval on a vaulted credential → Password Safe. A whole network for a trusted site or fleet → VPN. When a scenario fits two lanes, ask who owns the identity lifecycle — if the human is not your employee, PRA's sponsored, expiring vendor accounts win.

④ Identity & onboarding: SAML, MFA, sponsored vendors, named-user licences

PRA only delivers "one identity → one app" if the identities are real. The lanes you will actually use: local users (created under /login → Users & Security → Users, on the appliance itself), and external providers configured under Users & Security → Security Providers — LDAP/Active Directory (the appliance queries your DC over 389/LDAPS 636 — exactly the DMZ→internal sideband ports from the matrix), Kerberos, and SAML for modern SSO against Entra ID or Okta. Production guidance: SSO via SAML for humans, groups mapped to PRA group policies, and one or two local break-glass admin accounts — vaulted, MFA-protected — so an IdP outage cannot lock you out of /login.

MFA stacks in layers. The cleanest: enforce it at the IdP (Entra/Okta) so every SAML login is already MFA-verified — like an Aadhaar-OTP step before the gate. Local accounts get TOTP on the appliance. And independently of login, a Jump Policy can demand a 2FA challenge at session start — a second checkpoint right before the most sensitive doors, even for an already-logged-in user. The browser console adds FIDO2 passwordless support (fully on Windows; roaming keys like YubiKey on macOS/Linux desktop consoles).

For third parties, PRA has a dedicated lane: /login → Users & Security → Vendors. You create a vendor group per supplier, attach the group policy that scopes what its members reach, and appoint sponsors — internal employees who approve each vendor user and own the relationship. Vendor accounts expire automatically (fixed end date or after inactivity), which quietly solves Sneha's audit finding from section ①: the engineer who left the vendor last year stops existing in your system without anyone remembering to act. It is the society visitor register, upgraded: entry only when a flat owner (sponsor) confirms, pass valid for today, every entry timestamped. For one-off emergencies there is also Access Invite — a time-boxed invitation instead of a standing account.

Onboarding is GUI work, but everything has an API equivalent — the PRA Configuration API authenticates with OAuth client credentials and lets you script audits, like listing exactly which endpoints exist for a vendor's Jump Group before an access review:

curl -s -X POST "https://pra.icici-lab.in/oauth2/token" \
  -u "$CLIENT_ID:$CLIENT_SECRET" -d "grant_type=client_credentials"

curl -s "https://pra.icici-lab.in/api/config/v1/jump-item" \
  -H "Authorization: Bearer $TOKEN" | head -c 400

{"access_token":"eyJhbGciOiJSUzI1NiIs...","token_type":"Bearer","expires_in":3600}
[
  {"id": 7, "name": "BILLING-APP-01", "hostname": "10.20.8.21",
   "jump_group_id": 3, "jumpoint_id": 2}
]

Finally, the licence shape — because procurement questions reach L2 engineers faster than you expect. PRA is sold per named user (a 2023 US GSA price list shows the "Privileged Remote Access Per Named User License" perpetual SKU at roughly USD 3,235 list), and a per-asset SKU (PRAA-LIC) also exists. Contrast with Remote Support's concurrent rep pool, and Password Safe's asset-based model with unlimited users. A named-user licence is a gym card with your photo on it: only Rahul can use Rahul's — so 30 vendor engineers means 30 named accounts, not one shared login. That cost is the point: it buys attribution. Career note: BeyondTrust University's PRA Administration course leads to the product cert (40 questions, 75% to pass, two attempts) — the docs portal and Beekeepers community are free, so you can build paper-skills before an employer funds the exam.