Replacing VPNs for RDP access with per-session least privilege

At a glance

What this is: This white paper argues that VPN-based RDP access creates more governance and operational burden than a per-session brokered model with JIT access, MFA, RBAC, and session evidence.

Why it matters: It matters because IAM, PAM, and NHI teams need to control administrative access by target, time, and approval, not just by tunnel, especially when contractors and mixed infrastructure increase exposure.

👉 Read Devolutions' white paper on replacing VPNs for RDP remote access

Context

RDP is an administrative protocol, not a general-purpose remote work channel, and that matters because access scope should match the task. When organizations expose RDP through a VPN, they often solve one problem while creating another: the tunnel grants broader network access than the session actually requires, which weakens least privilege and complicates evidence collection.

The governance gap is especially visible in environments that depend on contractors, temporary access, or mixed on-premises and cloud infrastructure. In those cases, identity and access decisions need to be tied to the specific host, the specific session, and the specific approval path, rather than to a generic network connection that is hard to audit after the fact.

A brokered RDP model changes the control point from the network perimeter to the session boundary. That is a more precise fit for NHI, PAM, and administrative IAM because it keeps secrets hidden, reduces lateral movement scope, and gives auditors something closer to action-level evidence.

Key questions

Q: How should security teams govern privileged RDP access without relying on a gateway as the control boundary?

A: Treat the session as the control unit. Approval, MFA, host scoping, and logging should all happen before the connection opens, so the organisation can prove who accessed which server, for how long, and under what authorization. Connectivity should be the outcome of policy, not the policy itself.

Q: Why does VPN-based access create governance problems in regulated environments?

A: VPNs often convert a successful login into broad internal reach, which makes least privilege difficult to prove and lateral movement easier to perform. In regulated environments, that becomes an audit problem as well as a security problem because the organisation has to show exactly what each user could access and why.

Q: What breaks when RDP access is not scoped to a single session and host?

A: Standing network access increases lateral movement risk, makes approvals hard to enforce, and leaves administrators with reusable connectivity that is wider than necessary. It also weakens incident response because teams cannot easily show who accessed which server, under whose approval, and for how long.

Q: Who should be accountable for privileged identity controls?

A: IAM, PAM, security engineering, and system owners should share accountability, with clear ownership for issuance, monitoring, and revocation. Privileged access fails when responsibility is split so broadly that no team can answer who approved it, who watches it, or who removes it.

Technical breakdown

Why RDP exposure is a control problem, not just a connectivity problem

RDP becomes dangerous when the service itself is reachable from the Internet because scanners, password spray activity, and brute-force attempts quickly find exposed endpoints. A VPN hides the port, but it does not change the underlying issue that administrative access is still being granted through a broad network path rather than a constrained session path. The real control question is whether the user is authorized for a specific host and action before the session starts. Practical implication: move the authorization boundary from network reach to session approval and host scope.

Practical implication: move the authorization boundary from network reach to session approval and host scope.

How per-session brokering changes least privilege for remote admin access

A session broker sits in front of RDP and authorizes the connection before it begins, which allows policy to decide who may connect to which target, under what conditions, and for how long. This is different from tunnel-based access, where the network connection exists first and the application control happens later, if at all. JIT access, approvals, and credential injection can all be enforced at the broker layer so the user never receives standing access to a subnet. Practical implication: treat the broker as the enforcement point for time-boxed administrative access.

Practical implication: treat the broker as the enforcement point for time-boxed administrative access.

Why VPN logs are too weak for RDP governance

A VPN log usually proves only that a tunnel existed, from which IP, and at what time. That is not enough for audit or investigation when the control objective is to prove which server was touched, who approved it, whether credentials were injected, and how long the privileged session lasted. Per-session telemetry turns an opaque network event into an identity and activity record, which is what PAM and compliance teams actually need. Practical implication: require session-level logging and optional recording for all privileged RDP access.

Practical implication: require session-level logging and optional recording for all privileged RDP access.

NHI Mgmt Group analysis

Network tunnels are a poor substitute for administrative identity governance. A VPN authenticates the connection path, but it does not natively authorize the administrative act, the target host, or the duration of the session. That leaves a structural gap between tunnel access and session governance, which is why least privilege remains difficult to prove in audit or investigation. Practitioners should treat broad network reach as a weak control plane for privileged RDP.

Per-session RDP evidence is a governance requirement, not a logging enhancement. The article’s emphasis on requester, approver, target host, start and stop times, and credential-handling status reflects the level of evidence modern PAM and IAM programmes need. Without that evidence, access reviews become synthetic and incident reconstruction remains incomplete. The practitioner conclusion is straightforward: if you cannot name the host and the approval context, you do not really control the session.

Credential injection changes the NHI risk model by removing password handling from the operator. That matters because the privilege boundary is no longer the human remembering or reusing a secret, but the controlled transfer of credentials into a specific session. This reduces exposure of secrets in the operator workflow and narrows the lateral movement path available to an attacker who compromises the user endpoint. Teams should see this as a shift from credential possession to controlled credential use.

RDP governance belongs at the intersection of PAM, NHI, and zero trust. The article shows that remote admin access is not solved by a single control family because the same session involves identity proofing, privilege scoping, secret handling, and evidence capture. That is why the control problem spans identity lifecycle, privileged access, and network trust assumptions together. Practitioners should align the access model to the administrative task rather than to the transport layer.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For a broader control lens, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility, rotation, and over-privilege patterns that drive this problem.

What this signals

Session-level control is becoming the more defensible model for privileged connectivity. As organizations keep contractors and distributed admins in play, broad tunnels will look increasingly like a legacy convenience rather than a governance control. The practical shift is toward access decisions that are tied to a single host, a single window, and a single approval path, with evidence that survives audit and incident response. For teams building that control plane, the Ultimate Guide to NHIs , Key Challenges and Risks remains the clearest internal reference point.

Per-session evidence becomes a programme design requirement once RDP is part of regulated operations. If access reviews cannot answer who connected, to what, and under what approval, then the review process is not evaluating actual privilege. The broader lesson is that identity governance has to follow the action boundary, not the transport boundary, which is a useful pattern across NHI, privileged human access, and delegated administration.

For practitioners

• Replace broad VPN access with session-scoped RDP brokering Require the connection broker to authorize each host-specific session before any remote desktop traffic starts, and block subnet-level access that is not necessary for the task.
• Enforce JIT approvals for privileged remote access Tie every RDP session to a time-boxed approval path, with role checks, MFA, and change-ticket linkage before the session is admitted.
• Move secret handling out of the operator workflow Use credential injection so privileged passwords are never visible to the end user, then log whether the session involved vault-based secret delivery.
• Standardise per-session audit evidence Capture requester, approver, target host, session start and stop times, and session recording where policy requires it, then forward the records to the SIEM for investigation and compliance review.

Key takeaways

• VPNs reduce exposure only partially because they still grant network reach wider than the administrative task.
• Brokered, session-scoped RDP access gives IAM and PAM teams the evidence and least-privilege boundaries that tunnel-based access lacks.
• Credential injection and per-session logging are the controls that turn remote admin from a connectivity problem into a governable identity workflow.

Key terms

• Session-Scoped Access: Session-scoped access is permission that exists only for a defined task or time window and is expected to end when the task ends. For NHI governance, it reduces lingering authority and makes AI-driven activity easier to review, revoke, and investigate when behaviour changes.
• Credential Injection: Credential injection is the controlled replacement of one credential with another at execution time, usually before a request leaves the host or service boundary. It lets the workload operate with a harmless token or placeholder while the real secret remains protected by infrastructure.
• Least privilege for remote administration: The principle that an administrator should reach only the host and function needed for the task, for only as long as the task requires. For remote desktop access, that means host-level scope, time limits, and explicit approval rather than subnet-wide access.

What's in the full article

Devolutions' full white paper covers the operational detail this post intentionally leaves for the source:

• Step-by-step deployment of Devolutions Gateway with Devolutions Server and Remote Desktop Manager
• Per-session workflow details for approvals, credential injection, and session recording
• The implementation sequence for replacing VPN-based RDP access with an edge-brokered model
• A practical checklist for proving time-to-connect, audit completeness, and exposed-service reduction

👉 The full Devolutions white paper covers deployment steps, per-session governance details, and implementation guidance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.