Subscribe to the Non-Human & AI Identity Journal

Why do firewalls and VPNs no longer provide enough protection on their own?

Firewalls and VPNs only describe the path a device takes, not whether the device is secure enough to trust. In remote and hybrid work, users connect from home networks, public Wi-Fi, and personal devices, so perimeter location is a weak proxy for safety. Access decisions need to evaluate the endpoint itself, because the endpoint now carries the real risk.

Why This Matters for Security Teams

Firewalls and VPNs were designed to reduce risk at the network edge, but they do not tell a security team whether the connecting endpoint is healthy, whether the user session is behaving normally, or whether a stolen credential is being replayed from somewhere else. In a hybrid environment, that gap matters more than perimeter control. Current guidance from NIST Cybersecurity Framework 2.0 and NHIMG research both point to identity and exposure as the real decision points, not location alone.

The practical problem is that attackers increasingly work inside trusted channels. A VPN can authenticate a tunnel while still allowing access from a compromised laptop, a phished session, or a machine that is quietly running malware. That is why organisations looking at incidents like the JetBrains GitHub plugin token exposure and the Schneider Electric credentials breach keep finding the same theme: access was technically “inside” the network, but not actually trustworthy. In practice, many security teams encounter credential misuse only after lateral movement or data access has already occurred, rather than through intentional endpoint trust verification.

How It Works in Practice

Modern access control increasingly treats the endpoint, identity, and session as separate signals. A firewall still filters traffic, and a VPN may still encrypt transport, but neither should be the final trust decision. Instead, organisations move toward context-aware access that checks the device posture, user risk, authentication strength, and application sensitivity before granting access. That is the direction reflected in NIST Cybersecurity Framework 2.0 and in NHIMG’s broader guidance on identity-centric control.

  • Verify device health before session start, including patch level, disk encryption, and endpoint protection status.
  • Use conditional access to limit what a session can reach, even after the VPN tunnel is established.
  • Prefer least privilege and short-lived access over broad network reachability.
  • Monitor for anomalous behaviour such as impossible travel, token reuse, or access from unmanaged devices.

For NHI-heavy environments, the same logic applies to service accounts, API keys, and automation credentials. NHIMG notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which reflects a broader shift away from perimeter trust and toward identity-aware controls. That is why teams should align firewall rules, VPN policy, and identity governance with a single access decision model rather than treating them as separate security layers. These controls tend to break down when legacy applications require blanket network access because they cannot consume per-session, context-based authorization.

Common Variations and Edge Cases

Tighter endpoint validation often increases operational overhead, requiring organisations to balance stronger trust decisions against user experience, legacy compatibility, and support burden. Best practice is evolving, and there is no universal standard for every environment yet.

Some environments still depend on VPNs for administrative access to internal systems, especially where applications are not ready for zero trust or where third-party integrations are fixed around IP allowlists. In those cases, a VPN may remain useful as a transport control, but it should not be treated as proof that the device or user is safe. This distinction matters even more for contractor access, shared workstations, and bring-your-own-device policies, where endpoint assurance is uneven.

Teams also need to distinguish between human access and machine access. For NHIs, network location is often irrelevant compared with secret handling, workload identity, and rotation discipline. NHIMG’s research on secret exposure shows how often long-lived credentials remain exploitable after a compromise, which is why network perimeters alone do not contain identity-driven attacks. The practical answer is layered control: identity first, endpoint posture second, network path last. That approach is stronger, but it also demands better inventory, policy tuning, and ongoing exception management.

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 AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-1 Access decisions must move beyond network location and validate trust context.
OWASP Non-Human Identity Top 10 NHI-01 Perimeter controls miss compromised secrets and service-account abuse.
NIST AI RMF Risk management should account for dynamic access decisions and changing endpoint trust.

Treat secrets, service accounts, and API keys as first-class identities with explicit governance.