How should security teams govern remote access without recreating broad VPN trust?

Why This Matters for Security Teams

Remote access breaks down when teams confuse connectivity with trust. A VPN can make a device “inside” the network while still leaving every application, API, and privileged path broadly reachable. That creates the same failure pattern seen in NHI misuse: too much standing access, too little visibility, and lateral movement that is difficult to detect. The safer model is to treat each request as an access decision, not a membership grant, consistent with the direction of the NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs.

That shift matters because remote access is now part of identity governance, not just network operations. If the control plane only checks source IP or tunnel membership, it cannot answer whether the user, device, or workload should reach a specific system at that moment. Current guidance suggests that secure remote access should combine strong authentication, device posture, and explicit resource-level authorisation, then log every decision for IAM and PAM review. In practice, many security teams discover the weaknesses in broad VPN trust only after a contractor, stolen session, or compromised endpoint has already moved through multiple internal systems.

How It Works in Practice

The practical answer is to replace “on the network” with “authorised to this resource, right now.” Teams typically do this with a zero trust access layer that evaluates identity, device state, user context, and application sensitivity before granting a session. The OWASP Non-Human Identity Top 10 is useful here because the same principle applies to service access: broad credentials and broad reach create hidden risk.

For human remote access, the mechanics usually include:

• Strong authentication, ideally phishing-resistant for privileged or high-risk access.
• Device trust checks such as managed status, patch level, and endpoint health.
• Per-application or per-system authorisation instead of subnet-level admission.
• Short-lived session grants with automatic expiry and re-checks on risk change.
• Central logging that records who accessed what, from which device, and under which policy.

For privileged access, PAM should issue just-enough access only when needed, and revoke it at session end. For service-to-service or agentic workflows, the same logic increasingly depends on workload identity and short-lived credentials rather than long-lived shared secrets. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces that lifecycle controls, rotation, and offboarding are essential when access is no longer tied to a static perimeter.

These controls tend to break down in legacy environments where a VPN is still used as the only practical path to flat internal networks, because application-level segmentation and per-resource policy enforcement are not available.

Common Variations and Edge Cases

Tighter remote access control often increases operational overhead, requiring organisations to balance user experience against the reduction in lateral movement. That tradeoff is real, especially for hybrid work, third-party support, and incident-response access. Best practice is evolving, but there is no universal standard for this yet, so policy design should reflect risk rather than chase a single access pattern.

High-risk users such as administrators, developers with production access, and vendors should get stronger checks and shorter sessions than standard employees. Break-glass access should remain available, but it must be time-bound, heavily logged, and reviewed after use. For environments with sensitive regulated data, the Top 10 NHI Issues is a useful reminder that excessive privilege and weak rotation are often the real failure points, not the remote access tunnel itself.

Teams should also watch for exceptions that recreate VPN trust in disguise, such as “temporary” full-network access, shared admin jump hosts, or broad vendor tunnels that bypass application policy. The most durable model is one where remote access is a brokered, auditable decision tied to identity, device posture, and the exact resource requested.

Related resources from NHI Mgmt Group

• How should security teams govern DNS migrations without losing control of delegated access?
• How should security teams govern cloud migrations without losing access control context?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?