How Privileged Remote Access (PRA) closes the most dangerous gap in enterprise security — unmonitored, over-privileged vendor connections — with a deep focus on Delinea PRA.
Third-party vendors represent the fastest-growing attack surface in enterprise environments — yet remain the most poorly governed category of privileged access.
VPN credentials shared across vendors or left active after contract end are harvested via phishing or dark web purchases. Attackers use legitimate credentials, making detection extremely difficult.
Attackers compromise a vendor's own infrastructure first (e.g. SolarWinds-style), then pivot into customer environments via the vendor's legitimate, trusted remote access channel.
Support teams share a single admin account across technicians. There is no accountability — when misused, forensics cannot determine which individual performed which action.
Contractor access is provisioned for a project and never deprovisioned. Accounts remain active for months or years after the vendor relationship has ended, silently awaiting exploitation.
Even when vendor access is legitimate, there is no visibility into what is being done. Remote access sessions are unrecorded, making breach investigation impossible and compliance audits a manual nightmare.
Traditional VPN grants vendors full network access — the same level as an employee — rather than scoped access to specific systems. Once inside the VPN tunnel, lateral movement is trivial. VPNs provide no session recording, no activity monitoring, no automatic timeout, and no per-session authorisation workflow.
PRA replaces VPN for vendor access with a zero-trust, agentless, application-level gateway. Vendors connect only to the specific systems they are authorised for, via a broker that controls, records, and can terminate every session in real time.
PRA is the PAM discipline of governing all third-party, vendor, and contractor access to internal systems through a controlled, monitored, and auditable broker — with no VPN required.
The vendor's device never touches your network. The PRA gateway proxies the session — injecting credentials, recording activity, enforcing policy, and providing a live killswitch.
| Capability | Traditional VPN | PAM Jump Server | Privileged Remote Access (PRA) |
|---|---|---|---|
| Network Access Scope | Full network segment | Network to jump host only | Zero — application-level only |
| Requires Agent on Endpoint | Yes (VPN client) | Often yes | No — browser-based |
| Credential Injection | No — vendor sees password | Partial — depends on platform | Yes — vendor never sees credential |
| Session Recording | None | Varies by config | Full keystrokes + screen capture |
| Live Session Termination | No | Partial | Yes — instant killswitch |
| Vendor Onboarding | Manual, IT-heavy | Manual | Self-service with approval workflow |
| Per-Session Approval | None | Sometimes | Yes — full workflow |
| Works for Third-Party Devices | Risky | Limited | Yes — by design |
Every vendor session is treated as untrusted regardless of history. Identity is verified, access is scoped to a specific resource, and every action is recorded. Trust is never implicit.
The PRA gateway injects privileged credentials into the target session on behalf of the vendor. The vendor never sees, copies, or stores the actual password — eliminating credential theft from the vendor side.
No software needs to be installed on the vendor's device. Access is delivered via a secure browser session or thin client, removing the dependency on endpoint management of uncontrolled third-party devices.
A feature-by-feature breakdown of Delinea PRA — how it addresses vendor access governance across identity verification, session control, and compliance.
Walk through a complete Delinea PRA vendor access request — from vendor login through approval, active session monitoring, and session expiry.
Practical steps for rolling out Delinea PRA in your environment — from pre-deployment checklist to governance best practices and operational workflows.
Leaving VPN active "just in case" means vendors continue using it, bypassing all PRA controls. Set a firm VPN sunset date.
Granting vendors access to entire server tiers rather than specific systems. PRA's value comes from scoped, per-resource access — configure it properly.
Vendor accounts created during onboarding but never reviewed. Without periodic access reviews, PRA becomes another source of orphaned accounts.
Eight questions covering the vendor access threat landscape, PRA concepts, and Delinea PRA capabilities. Immediate feedback on every answer.