Topic starter
24/06/2026 11:35 pm
TL;DR: Remote access is easier to govern when policy, vaulting, and audit follow the application boundary rather than the network, according to Delinea. That shift narrows what each session can reach and gives IAM and PAM teams a cleaner way to review privileged access.
Editorial analysis by NHI Mgmt Group, based on content published by Delinea: “Open the application, not the network”.
Key questions
Q: Why do VPN-based remote access models still create privilege risk?
A: VPNs often turn identity decisions into network decisions, which makes it easier for users to reach more than they need.
Q: What are the signs that remote access controls are not working as intended?
A: Warning signs include vulnerable endpoints, misconfigured remote access systems, users reaching sensitive data they do not need, and audit findings that show policies are not being followed.
Q: How should security teams reduce VPN risk without disrupting remote work?
A: Start by moving the highest-risk populations off the broad tunnel first, especially contractors, third parties, and privileged sessions.
Practitioner guidance
- Map remote access by task boundary Inventory where users still receive network-level access when they only need a server, app console, or web portal.
- Eliminate user-held remote credentials Move SSH, RDP, and portal credentials into a vaulted launch flow so users do not handle reusable secrets directly.
- Group remote resources into governed collections Organise remote applications and private web applications into collections by role or team, then apply rights at the collection level.
Bottom line: Remote access becomes harder to govern when the network is treated as the access boundary instead of the application or session.
Glossary terms: Application-scoped policy, Remote Access Trust Boundary, Vaulted credential injection, Privileged Session
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 8:33 am
Remote access sprawl is an access governance problem before it is a connectivity problem: VPNs, jump hosts, and client sprawl usually persist because organisations optimise for reach, not for boundary precision. That leaves auditors reconstructing session intent after the fact instead of governing it at launch. The better control question is where access should start and what should remain invisible until the user proves need.
A question worth separating out:
Q: What should teams do when privileged access has to be granted to third parties or contractors?
A: Use temporary, role-scoped access with clear approval, time limits, and full session logging. Third parties should receive only the privileges needed for the task, and those privileges should be revoked as soon as the work ends. This reduces standing exposure, supports auditability, and prevents lingering access from becoming a later breach path.
👉 Read our full editorial: Remote access governance shifts from network tunnels to app-scoped access