The main weakness is that a VPN protects the connection, not the full trust decision. It does not verify whether the device is healthy, whether the user is authorised for the specific resource, or whether the session should be limited once access begins. Mobile security needs identity and device controls alongside the tunnel.
Why This Matters for Security Teams
VPNs are still useful for encrypting traffic in transit, but they do not answer the real mobile-access question: should this device, user, and session be trusted for this specific action right now? That gap matters because mobile workers move between networks, devices age unevenly, and access often expands long after the tunnel is established. NHI Management Group’s Ultimate Guide to NHIs frames this as an identity problem, not a connectivity problem.
Modern access control has to evaluate posture, identity, and resource sensitivity together. Otherwise, a valid VPN login can become a durable foothold for an unmanaged phone, a stolen credential, or a compromised app session. That is why guidance is shifting toward Zero Trust and contextual authorization rather than network perimeter trust, as reflected in the OWASP Non-Human Identity Top 10 and NIST’s zero trust guidance. In practice, many security teams encounter mobile abuse only after a device is already connected and a privileged internal path has already been opened.
How It Works in Practice
The practical weakness of VPN-only access is that the tunnel is blind to most of the trust signals that matter. A strong mobile access design starts by separating transport security from authorization. The VPN may still provide encryption, but the actual decision to grant access should be made by policy that considers user identity, device health, app context, and the sensitivity of the target resource.
That usually means layering controls instead of treating the VPN as the control:
- Use device posture checks for OS version, encryption, jailbreak or root status, and endpoint protection coverage.
- Require phishing-resistant identity for the user, especially for privileged or high-risk resources.
- Apply least privilege and segment access by application, not by full internal network membership.
- Re-evaluate the session after login, not just at the point of connection.
- Prefer short-lived credentials and scoped tokens over broad, long-lived network trust.
This is also where broader identity governance intersects with non-human and automated access. If mobile apps, scripts, or background services are involved, the correct primitive is workload identity and runtime policy, not a permanent tunnel. NHI Management Group’s 52 NHI Breaches Analysis shows how quickly weak identity assumptions turn into lateral movement when credentials or session paths are reused beyond their intended scope. For implementation patterns, NIST’s Zero Trust Architecture and related identity guidance support the move from network trust to continuous verification.
These controls tend to break down when legacy VPN concentrators are still treated as the primary gatekeeper for flat internal networks, because the access model cannot distinguish a healthy phone from a compromised one once the tunnel is up.
Common Variations and Edge Cases
Tighter mobile access control often increases user friction and support load, requiring organisations to balance stronger assurance against device diversity and remote-work speed. That tradeoff is real, especially in BYOD environments where full device management may be impractical or politically difficult. Current guidance suggests that risk-based access and selective app-level controls are usually more sustainable than forcing all mobile users through the same VPN experience.
There is no universal standard for this yet, but several patterns are emerging. Managed devices can support stronger posture checks and per-app access policies. Unmanaged devices often need browser-based access, step-up authentication, or tightly scoped sessions instead of full network reachability. High-risk use cases, such as admin work, secrets access, or production change windows, should not rely on a VPN alone because a secure tunnel does not stop misuse once the session is active.
The same issue appears in workflows that involve secrets, API keys, or automation. The State of Secrets in AppSec highlights how fragmented secrets practices weaken central control, which is exactly the kind of exposure a VPN cannot correct. Mobile access should therefore be designed around identity, device trust, and session limitation first, with the VPN treated as one transport layer rather than the trust boundary itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | VPN-only access fails when access depends on network location instead of verified identity. |
| NIST Zero Trust (SP 800-207) | Zero Trust directly addresses the weakness of perimeter-based VPN assumptions. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Scoped, short-lived credentials reduce the risk of long-lived access over mobile channels. |
Replace broad VPN trust with short-lived, least-privilege credentials and session boundaries.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- What is the difference between JIT access and Zero Trust for NHIs?
- Why does the Cyber Resilience Act matter for identity and access teams?
- How should manufacturing teams secure access across IT and OT environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
