Privileged Remote Access Buyers Guide: Vendor Access

Vendors, contractors and remote administrators still reach critical systems through shared VPN accounts, always-on remote support tools and jump hosts that nobody reviews. Privileged remote access (PRA) products broker that access instead: the user authenticates to the broker, the broker opens a recorded, time-limited session to a specific target, and credentials stay hidden. The category overlaps with PAM, zero trust network access and remote support tools, so buyers often compare unlike products. This vendor-neutral guide helps security, infrastructure and procurement teams define requirements for third-party and administrative remote access, evaluate products and run a proof of concept. For PAM as a whole, see the PAM Buyer's Guide; for the access model behind this page, see the Third-Party Access Guide.

Key takeaways

Broker, do not connect: a PRA product should give a user a session to a named target, not a network route, so a compromised vendor laptop cannot scan or move laterally.
Kill standing vendor accounts: access should be requested, approved, time-boxed and revoked automatically, because dormant remote accounts are a proven breach path.
Hide the credential: inject or broker privileged credentials so vendors never see or keep them, and rotate them after each session where the target allows.
Record and log everything: session recording, keystroke or command logs and file transfer logs are the evidence auditors and incident responders need.
The broker is a crown jewel: it holds paths to every critical system, so judge vendors on their own patching, hardening and incident record as much as on features.

What the category does

PRA combines access brokering with privileged session management for users who are outside your network or outside your organisation. Most products share a gateway or cloud broker, outbound-only connectors near the targets, an identity layer and a session layer.

Approach	What it gives	Where it falls short for privileged third-party access
Site-to-site or client VPN	Network-level access for many users	Broad network reach, weak per-session control, shared or dormant accounts, little session evidence
Jump host or bastion you build	A choke point you control	Credentials often stored on the host; recording, approval and rotation must be built and maintained
Remote support or RMM tool	Easy attended and unattended support	Often always-on agents and broad rights; misused by attackers (ATT&CK T1219 Remote Access Tools)
Zero trust network access (ZTNA)	Identity-aware application access	Strong for applications; varying session recording and credential vaulting for privileged protocols
Privileged remote access	Brokered, approved, recorded sessions to specific targets with credential injection	Cost, connector deployment, protocol coverage varies; not a full PAM programme on its own

Many PAM suites include a PRA module, and some PRA products add vaulting. Decide on the outcome you need rather than the category label. The Secure Remote Access Beyond VPN Guide compares the architectures in more depth.

Define requirements

You need PRA, rather than better VPN hygiene, when:

Third parties administer your systems: outsourced IT, managed service providers, OEM support for OT or medical devices, or software vendors who maintain on-premises products.
Remote admins use privileged protocols: RDP, SSH, database clients, web consoles or OT engineering tools from outside a trusted network.
Evidence is required: regulators, customers or auditors ask who accessed which system, when, why and what they did. NIST SP 800-53 AC-17 Remote Access, AC-17(1) Monitoring and Control, MA-4 Nonlocal Maintenance and AU-14 Session Audit describe the controls.
Dormant accounts exist: any remote account that is not tied to a current contract and an active ticket. The Colonial Pipeline ransomware attack began with a VPN account that was no longer used, had not been disabled and had no MFA.

Write down for each user population: who they are, which targets and protocols they need, how often, whether sessions are attended, which identity they will authenticate with (your IdP, their IdP, or a local account), and what evidence you must keep and for how long. A small organisation with one or two support vendors may meet its needs with a hardened jump host, MFA and strict account lifecycle; a large or regulated estate with dozens of suppliers usually needs a product.

PAM module, standalone PRA or ZTNA?

Choose a PAM suite module when you already run the suite's vault and session management for internal admins, and want one policy, one audit trail and one credential store for internal and external users.
Choose a standalone PRA product when third-party access is the urgent problem, your PAM programme is immature or on another platform, or you need vendor-friendly clientless access fast. Confirm it integrates with the vault you will keep.
Choose ZTNA plus PAM when most remote users need ordinary application access and only a minority need privileged sessions. Make sure privileged protocols still get recording and credential brokering.

Where identity fits

PRA is usually bought for people, but it creates and depends on non-human identities: connector service accounts on the target network, API keys used to automate approvals and onboarding, integration accounts into the vault and IdP, and sometimes vendor automation that connects without a person. Each needs an owner, least-privilege scope, rotation and logging. Ask whether the product can broker machine-to-machine vendor connections with the same approvals and recording, or whether those still bypass it. The NHI Authentication Guide covers the credential options.

Capability areas

Identity and onboarding: federation with your IdP and ideally with vendor IdPs, phishing-resistant MFA, sponsor assignment for every external user and automatic expiry at contract end. See the Remote Access Identity Guide.
Access requests and approvals: request against a target and reason, link to a change or incident ticket, approval by the system owner, and time windows.
Just-in-time and zero standing access: accounts or permissions created or enabled only for the session window. The JIT Access Guide explains the model.
Credential injection and rotation: privileged credentials brokered into the session without being shown, with rotation after use and integration with an existing vault.
Protocol coverage: RDP, SSH, VNC, HTTPS web consoles, database protocols, and OT or vendor-specific tools if relevant. Check clientless browser access versus native clients.
Session control: live monitoring, the ability to terminate a session, file transfer controls, clipboard controls and command filtering for SSH.
Recording and audit: video recording, searchable keystroke or command logs, tamper-evident storage, retention settings and SIEM export.
Network design: outbound-only connectors, no inbound firewall openings, and per-target access instead of network segments.
Broker security: hardening guidance, patch cadence, vulnerability disclosure, tenant isolation for cloud brokers, and how API keys and connector credentials are protected.

Evaluation criteria

Criterion	Why it matters	How to test
Network exposure	Inbound ports on a broker are an attack surface	Scan the deployed broker and connectors from outside; review required firewall rules
Session scope	Lateral movement from a compromised vendor device	From a vendor session, try to reach a second host not approved
Credential exposure	Vendors who know passwords keep access	Check whether a user can view, copy or export an injected credential
Lifecycle automation	Dormant accounts	Expire a contract in the test data and confirm access ends without manual work
Evidence quality	Audit and forensics	Search recordings for a command and export a session report
API and token security	Broker API keys are high-value NHIs	Review how API keys are scoped, stored, rotated and logged
Vendor security record	The broker reaches everything	Ask for advisories over the last three years and time to patch
User experience	Workarounds return when tools are slow	Time a vendor from request to working session

Framework mapping

Framework	Reference	What PRA supports
NIST SP 800-53 Rev 5	AC-17, AC-17(1), MA-4, AU-14	Controlled, monitored remote and maintenance sessions with session audit
NIST SP 800-46 Rev 2	Telework and remote access security	Remote access architecture and policy, including vendors and contractors
NCSC secure system administration	Principles on administration interfaces, PAM and logging	Protecting admin interfaces, controlling who, where, when, why and how, auditing admin actions
ISO/IEC 27001:2022 Annex A	5.19 to 5.22 supplier relationships; 8.2 privileged access rights; 8.15 logging	Supplier access control and evidence
MITRE ATT&CK v20	T1133 External Remote Services; T1199 Trusted Relationship; T1219 Remote Access Tools	Reducing and detecting abuse of remote paths and suppliers

Questions to ask vendors

Does any component require inbound connections from the internet into our network? If so, which ports and why?
Can a user ever see, copy or reuse a privileged credential that the product injects?
How do external users authenticate, and can we require phishing-resistant MFA for them?
How is access tied to a contract, sponsor and ticket, and what happens automatically when any of them expires?
Which protocols and clients are supported, and which require a native client or agent on the vendor's device?
How are recordings stored, protected from tampering, retained and exported?
What security advisories have affected the product in the last three years, and how quickly were they fixed and disclosed?
How are your own API keys, connector credentials and administrator accounts protected, and can we restrict API keys by scope and source address?
For a cloud broker, how is our tenant isolated, and where is session data processed?
Can the product integrate with our existing vault, IdP, SIEM and ticketing tools?

Deployment and integration

Inventory remote paths: list every VPN profile, remote support tool, jump host and vendor account, with owner, last use and contract. The CISA guide to securing remote access software covers how attackers misuse these tools and how to detect them.
Pick a first population: one high-risk supplier group with clear targets, often outsourced infrastructure support or OT vendors (see the OT Remote Access Guide).
Deploy connectors and harden the broker: follow the vendor's hardening guide, restrict administrative access to the broker, put its logs in the SIEM, and scope API keys tightly.
Integrate identity and approvals: connect your IdP, add sponsors, link approvals to your ticketing tool, and vault target credentials.
Pilot and compare: run the pilot supplier through PRA while keeping the old path available but monitored for a short, fixed window.
Cut over and remove: disable the old VPN profiles, remote tool agents and vendor accounts. Block unapproved remote access tools on endpoints and at the network edge; the Unauthorised Remote Monitoring and Management Tool Playbook covers response.
Roll back if needed: keep a documented break-glass route with its own MFA and alerting, not a permanent back door.

Track: number of standing external privileged accounts (target zero), percentage of vendor sessions with an approved ticket, percentage recorded, median time from request to session, remote access paths outside PRA discovered per quarter, and credential rotations after vendor sessions.

Red flags

Required inbound internet exposure: for the broker or connectors, without a clear design reason and hardening guidance.
Visible credentials: any workflow where a vendor can reveal a target password.
Network-level access by default: a session that grants a route to a subnet rather than a target.
Shared vendor logins: licence models that push you towards one account per supplier instead of one per person.
Opaque security history: reluctance to discuss past vulnerabilities, advisories or the vendor's own incident response.
Recording as an extra: session recording or command logging sold as a separate tier, or stored where the vendor's own staff can browse it without your approval, leaves you without evidence when you need it most.
No break-glass design: if the cloud broker is unavailable, the only fallback is the old VPN, which then quietly stays in place for good.
Unscoped API keys: administrative API keys with full rights, no expiry and no source restriction.

Proof of concept

Pick two real suppliers and three target types (Windows server via RDP, Linux via SSH, one web console).
Onboard a supplier user through federation or a sponsored account with phishing-resistant MFA.
Request, approve and open a session tied to a test ticket; confirm the credential is never visible.
From the session, try to reach an unapproved host and to copy a file out; confirm both are blocked or logged as configured.
Terminate a live session from the console and confirm it ends immediately.
Expire the sponsor or contract date and confirm access is removed automatically.
Export the recording and session log to the SIEM and have an incident responder reconstruct the session.
Run an external scan of the broker and review the API key model with your NHI team.

Buyer checklist

Every remote path and vendor account inventoried with an owner.
Requirements written per user population, target and protocol.
No inbound exposure, or a documented and hardened exception.
Credential injection with no reveal, and rotation after use.
Automatic expiry tied to contract, sponsor and ticket.
Recording, logs and SIEM export tested end to end.
Broker security record and API key model reviewed.
Old VPN profiles, tools and accounts scheduled for removal.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for privileged and third-party access programmes, including the API keys and service accounts behind them. Browse vendors in our NHI and AI products directory or contact us.

Privileged Remote Access Buyers Guide: Choosing Secure Vendor and Admin Access