Who is accountable when VPN-based access controls fail under the Online Safety Act?

Why This Matters for Security Teams

VPN-based access checks often fail because they answer the wrong question: whether a connection came from a network path the organisation recognises, not whether the person or workload behind it should be trusted. Under the Online Safety Act, that gap becomes an accountability issue, because regulators care about the defensibility of the access decision, not just the presence of a perimeter control. The practical problem is that VPNs can hide location, device posture, and shared access patterns that should inform a denial.

For teams handling sensitive services, this is no longer a theoretical architecture debate. The organisation must be able to show why access was approved, what evidence was considered, and whether stronger verification was available. NHIMG’s Ultimate Guide to NHIs frames the broader shift away from trust-by-network toward identity- and context-based control, which is the right lens for this problem. In practice, many security teams encounter VPN weakness only after a challenge, incident, or regulatory review has already exposed the absence of a defensible access process.

How It Works in Practice

Accountability starts with ownership of the access decision chain. The service operator needs clear policy, logging, and review evidence that shows how VPN users are evaluated before access is granted. That usually means moving beyond static allowlists and toward controls that can consider identity assurance, device trust, geolocation anomalies, session risk, and purpose of access. Current guidance suggests that network location may still be a signal, but it should not be the deciding factor on its own.

A workable pattern is to combine strong identity proofing with step-up verification and runtime policy evaluation. For example, an access gateway can check whether the request matches a known role, whether the session originates from a managed device, whether the user is presenting a valid token, and whether the request is consistent with expected behaviour. Where the request is high-risk, the system can require additional verification or deny access outright. This is aligned with the direction of OWASP Non-Human Identity Top 10 and the accountability principles in 52 NHI Breaches Analysis, which show how weak identity controls turn into operational exposure.

• Record the policy basis for each allow or deny decision.
• Use MFA or stronger verification when VPN is only one signal among several.
• Bind privileged sessions to named identities rather than shared tunnels.
• Review exceptions frequently and revoke stale access paths.

These controls tend to break down when legacy VPN concentrators are the only enforcement point because they cannot reliably evaluate identity, device state, and purpose at request time.

Common Variations and Edge Cases

Tighter access verification often increases user friction and operational overhead, requiring organisations to balance regulatory defensibility against support burden and business continuity. That tradeoff is real, especially where contractors, third parties, or emergency responders need fast access. Best practice is evolving, but there is no universal standard for this yet, so organisations should document the rationale for the control set they choose rather than assuming a VPN login is sufficient evidence of trust.

Edge cases matter. Shared corporate VPNs can make it hard to tie activity to a single accountable person. Consumer VPN use by legitimate staff can create false positives if geolocation is over-relied on. Remote work also complicates device trust, because the network path may be encrypted and stable even when the endpoint is unmanaged. For sensitive services, the right answer is usually to separate connectivity from authorisation: let the VPN provide transport, but make identity proof, policy checks, and logging decide access. PCI guidance also reinforces this direction by treating access control as a documented, testable security function rather than a purely network-centric one in PCI DSS v4.0.

Where organisations serve high-risk or regulated audiences, accountability should be assigned to the control owner, the system owner, and the executive function responsible for assurance. The most common failure is treating VPN approval as the end of the control story, when regulators usually expect that to be the beginning.

Related resources from NHI Mgmt Group

• How should security teams implement time based access controls without creating stale access?
• Why do time based access controls still need identity governance and review?
• Who should own time based access controls in an IAM programme?
• Why do role-based access controls still leave governance gaps in cloud environments?