Notifications
Clear all
Topic starter
21/08/2026 4:45 pm
TL;DR: Directly exposed RDP remains easy to discover and abuse, so Devolutions argues that VPNs are a poor fit for protocol-specific admin access because they add broad network reach, client friction, and weak audit context. The operational issue is not connectivity alone but whether access is scoped, approved, and recorded at the session level.
NHIMG editorial — based on content published by Devolutions: Replacing VPNs with Devolutions Gateway for RDP remote access
Questions worth separating out
A: Treat the session as the control unit.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Devolutions' white paper on replacing VPNs for RDP remote access →
RDP over VPN: is per-session least privilege the better model?
Explore further
21/08/2026 5:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Replacing VPNs for RDP access with per-session least privilege
