When should organisations use something other than a VPN for mobile work?

Why This Matters for Security Teams

VPNs were built to extend network reach, not to express modern access policy. For mobile work, that distinction matters because the risk is rarely just transport security, but whether the user or device should reach a specific application at all. Broad tunnelling can overexpose internal services, blur entitlement boundaries, and make revocation slower than the business can tolerate. NIST’s Cybersecurity Framework 2.0 emphasises outcome-driven governance, which is a better fit for mobile access than a blanket network path.

At NHI Management Group, the same pattern shows up in machine access as well: when credentials are too broad, too long-lived, or too difficult to track, organisations lose control before they see the failure. That is why mobile access decisions should be tied to identity, device posture, and application sensitivity, not just whether the user can reach a subnet. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a useful reminder that overbroad access is usually the problem, not connectivity itself. In practice, many security teams encounter lateral movement only after a VPN session has already provided a wide internal path.

How It Works in Practice

The usual replacement for VPN-only access is a layered model: SSO for user authentication, ZTNA for application-level reach, MDM for device trust, and PAM for privileged actions. The key shift is that access is evaluated per request, not granted once at tunnel establishment. That lets security teams decide whether a device is compliant, whether the user is entitled to the application, and whether the session should be time-bound or step-up authenticated.

For broader identity governance, NHI Management Group’s research shows why static access models fail when privileges are excessive or secrets are poorly governed. The same operational lesson applies to mobile work: credentials should be scoped to the minimum application, the minimum time, and the minimum privilege required. In mature environments, organisations use ZTNA to replace network reach with policy, then layer PAM for admin workflows, and MDM to enforce device health before the session starts. NIST’s Cybersecurity Framework 2.0 supports this shift because it focuses attention on governance outcomes rather than on a single control type.

• Use VPN only for legacy network-dependent services that cannot yet be segmented.
• Use ZTNA when the goal is application access rather than subnet access.
• Use SSO and conditional access when the user identity and device posture must be checked first.
• Use PAM when mobile users need elevated access to sensitive systems or admin consoles.
• Use MDM when unmanaged or shared devices would make a tunnel too risky.

These controls tend to break down when legacy applications hard-code network assumptions and cannot tolerate per-app policy enforcement.

Common Variations and Edge Cases

Tighter access control often increases deployment and support overhead, so organisations must balance stronger governance against user friction and application compatibility. That tradeoff is real, especially where field staff, contractors, or third-party support teams need fast access from varied devices.

Best practice is evolving for shared devices and high-risk mobile use. A kiosk, contractor tablet, or bring-your-own-device flow may need stronger session controls than a normal employee laptop. In those cases, current guidance suggests treating the device as untrusted until it is proven otherwise, then narrowing access to one application or one task. This is also where organisations should avoid assuming that a VPN plus MFA is enough. If a session can reach far more than the user needs, it remains difficult to contain misuse or theft. For mobile access programmes, the most reliable pattern is to pair device trust with entitlement precision and to revoke access quickly when posture changes. In that sense, the lesson from the broader NHI problem remains consistent: the smallest practical privilege is the safest privilege.

For environments where secrets are embedded in tools or client apps, the IOS app secrets leakage report is a reminder that endpoint trust cannot be assumed just because a connection is encrypted. The right question is not whether the user can connect, but whether the connection should expose anything beyond the exact service required.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?
• When does regex-based secret detection become too unreliable for production use?