BeyondTrust Privileged Remote Access for OT: A Review

Disclosure: I hold BeyondTrust BCSE Essentials certifications in Privileged Remote Access, Endpoint Privilege Management for Windows, Entitle and Identity Security Insights (March 2026), and the CyberArk Certified Pre-Sales Engineer (PAM) certification (November 2025). No vendor paid for or reviewed this.

BeyondTrust Privileged Remote Access (PRA) is a strong fit for secure remote access in OT. It lets vendors and engineers reach the specific systems they need, with credentials injected from a vault, every session recorded, and approvals built in, without handing anyone a VPN tunnel into the plant network. If your current OT remote access model is “VPN plus a shared login,” PRA is one of the most direct ways to retire it.

This review looks at PRA through one lens: getting third-party vendors and your own engineers into operational technology and critical infrastructure safely. That’s where I spend most of my advisory time, and it’s the use case where the product makes the most sense.

How this review was put together

This review is built from three sources, and it’s worth being clear about which is which:

• OT remote access work. Assessing and redesigning how vendors and engineers reach operational systems is a large part of my advisory work. The problems described below, and the criteria I judge PRA against, come from that.
• Vendor certification training. I earned the BeyondTrust BCSE Essentials certification in Privileged Remote Access in March 2026, which covers how the product is built, deployed and positioned.
• Public documentation. Product details beyond that come from BeyondTrust’s published documentation and security advisories.

The yardstick is the same as every review on this site: deployment effort, day-two operations, coverage, integrations, reporting and audit, and total cost. More on that in how I review tools.

Why OT remote access is still VPNs and shared accounts

Before judging any tool, it’s worth being honest about why the status quo exists. Nobody designed OT remote access to be risky. It got that way one reasonable decision at a time.

OT environments depend on outside expertise. The integrator who built the control system, the OEM that supports the turbine, the vendor that maintains the historian: they all need to connect, sometimes on a schedule and sometimes at 2 a.m. when something trips. The fastest way to make that work was a VPN account into the OT network and a login on the engineering workstation or HMI.

Shared accounts followed for practical reasons. Many OT devices and applications have limited support for individual accounts, central directories or MFA. Some have a single admin login baked in. Changing passwords on a running system can feel riskier than leaving them alone, and a password that breaks a vendor’s 2 a.m. fix is a password someone will put back on a sticky note.

So the typical result looks like this:

• VPN accounts that grant network access, not system access. Once connected, a vendor can often reach far more than the one asset they came to fix.
• Shared or generic credentials. When five vendor technicians use the same login, your logs tell you the account connected, not which person did what.
• Always-on access. VPN accounts get created for a project and never removed. Vendor staff turn over; their credentials don’t.
• Little or no session visibility. If something changes on a controller, reconstructing who did it and why is guesswork.

Each of those is a real risk on its own. Together they give an attacker exactly what they want: a trusted path from the internet into the network that runs physical processes, with credentials that are easy to steal and hard to attribute. In IT a compromised remote session is a breach. In OT it can be a safety event. I covered the broader picture in What Is OT Security?, and the Purdue model through an identity lens post explains why identity controls get thin below Level 3.

What this usually looks like: A first assessment tends to turn up more vendor VPN accounts than anyone on site can name owners for, a handful of shared logins on engineering workstations that several vendors know, and at least one remote access path, like a cellular modem or a vendor-installed remote desktop tool, that nobody in IT knew existed.

What BeyondTrust Privileged Remote Access does

PRA, which grew out of the Bomgar product line, is a privileged access gateway for remote sessions. Instead of putting users on the network, it brokers a connection to a specific endpoint and keeps the session inside a controlled, recorded channel. The capabilities that matter most for OT:

Granular per-endpoint access without a VPN

Users are granted access to individual systems, not subnets. A vendor who supports one historian sees that historian in their console and nothing else. BeyondTrust’s Jump technology reaches endpoints through agents or a Jumpoint inside your network, so you can broker access to systems behind segmentation without exposing them or extending a VPN to the user’s laptop. Supported protocols include RDP, SSH and web-based access, with the option to tunnel other protocols to specific hosts.

For OT, that change from network access to endpoint access is the main event. It turns “the vendor is on our network” into “the vendor has a recorded session on one machine.”

Credential injection from a vault

PRA can inject credentials into the session from a vault, including BeyondTrust’s built-in vault and Password Safe, so the user connects without ever seeing the password. That breaks the shared-password habit without forcing every OT asset to support individual accounts on day one. The account might still be shared at the device level, but the person using it is individually authenticated, authorized and recorded. You also get the option to rotate the underlying credential without having to tell anyone the new one. If you’re already running BeyondTrust Password Safe, the integration is the natural path.

Session recording and monitoring

Sessions are recorded and can be watched live. An operator or security analyst can monitor a vendor session as it happens and terminate it if something looks wrong. After the fact, recordings give you an attributable record of who did what on which system. For OT, where a change to a controller may not show up in IT logs at all, that record is often the only one you’ll have.

Approval workflows and time-bound access

Access can require approval and be limited to a schedule or time window. That maps well to how OT already works: maintenance windows, change tickets, and the operator who needs to know before anyone touches a live system. A vendor requests access, someone at the site approves it, and the access expires when the window does. That’s just-in-time access in a form operations teams recognize.

Built for vendors and external users

PRA is designed for people who aren’t on your domain. Vendors authenticate to PRA, not to your Active Directory, and you can manage them as external users with their own groups and policies. That keeps third parties out of your directory and gives you one place to see, and revoke, every outside party with access.

Where it tends to go wrong: Vendor adoption usually stalls on logistics, not security. If the first time a vendor sees the new portal is during an outage, they’ll push for the old VPN back, and someone will give it to them. Onboard vendors before you need them, do a test session with each one, and set a firm date when the VPN accounts are switched off.

Deployment options

PRA is available as SaaS or self-hosted. Many OT operators prefer self-hosted for control and to keep the access path inside their own boundary, while SaaS removes the infrastructure and patching burden. Either way, the architecture question that matters is where the gateway and the in-network components sit relative to your OT zones. Plan it with your OT network team, not just the IAM team, and map it to the zones and conduits you already have, or wish you had.

How it fits with OT compliance

PRA isn’t a compliance product, but it maps cleanly to the controls regulators and frameworks keep asking about. NERC CIP-005 requires electric utilities to route Interactive Remote Access through an Intermediate System with MFA and encryption, and to be able to detect and disable vendor remote access sessions. IEC 62443 frames the same idea as controlled conduits between zones, with individually identified and authenticated users. A brokered, recorded, approval-gated remote access gateway is a common building block for both. Your auditors and your architecture still decide whether a given design meets the requirement.

What I’d look for: Before you buy, sketch where each PRA component would sit in your zone and conduit diagram, and which one you’d call the Intermediate System or conduit control. If you can’t draw it cleanly, the auditor won’t be able to follow it either.

Where it falls short

No remote access tool is risk-free, and an honest review should say so.

The gateway is a target. Anything that brokers privileged access into critical systems is a high-value target, and BeyondTrust has had serious vulnerabilities in its remote access products, including one disclosed in December 2024 affecting Remote Support and PRA. That’s not unique to BeyondTrust, but it means patch cadence, hardening and monitoring of the gateway itself are part of the deal. If you self-host, that’s your job.

It needs a foundation. Credential injection is only as good as your vault, and per-endpoint access is only as good as your asset inventory. Many OT sites don’t know every asset and every account yet, and PRA won’t discover that for you the way a dedicated OT asset tool will.

It’s one layer. PRA replaces a risky access path. It doesn’t replace network segmentation, OT monitoring or a program for how vendors are onboarded and offboarded.

How it compares

The obvious comparison for OT is the VPN-plus-jump-host pattern. A VPN gives network access, the jump host is often shared, and session recording is an afterthought. PRA replaces all three with per-endpoint, recorded, credential-injected sessions, which is a real step up in both security and auditability.

Against other PAM platforms, PRA’s advantage is that it’s built around remote access first. CyberArk can broker and record privileged sessions with more depth, as I covered in my CyberArk PAM review, but it’s a heavier platform built around privileged accounts. For the specific job of getting vendors and engineers into OT safely, PRA is the more direct tool. There are also OT-specific secure remote access products worth evaluating alongside it.

The verdict

BeyondTrust Privileged Remote Access does the job OT remote access most needs done: it replaces network-level VPN access and shared credentials with individually authenticated, approved, recorded sessions to specific systems. It’s practical for vendors to use, it fits the way operations teams already manage change, and it gives security and compliance teams the attribution they’ve been missing.

Treat the gateway as critical infrastructure in its own right, put a vault and an asset inventory behind it, and it’s one of the highest-value changes you can make to an OT security program.