Why do VPNs create audit and compliance problems for internal apps?

VPNs often log that a user connected, but not which application they used or what they did inside it. That makes it hard to attribute actions to a named identity, prove least privilege, or satisfy audit requirements that depend on session-level evidence rather than simple network connection logs.

Why This Matters for Security Teams

VPNs were designed to extend network reach, not to prove application-level accountability. That is why they often create a compliance gap: a log entry may show a tunnel came up, but not which internal app was accessed, what data was touched, or whether the session matched least-privilege expectations. For auditors, that is weak evidence. For incident response, it makes containment and attribution slower.

This problem becomes more severe when internal apps sit behind a broad trust boundary. A VPN can make every connected endpoint look equally “inside,” even though the business risk varies widely by app, data set, and role. NHI Management Group’s Top 10 NHI Issues highlights how poor identity visibility and overbroad access are recurring failure points, and the same pattern applies to remote access paths that do not preserve session context. In practice, many security teams discover the evidence gap only after an audit request, a privileged access review, or an incident has already forced them to reconstruct the session after the fact.

Standards frameworks also push in the same direction: NIST Cybersecurity Framework 2.0 and ISO/IEC 27001:2022 Information Security Management both depend on demonstrable control and traceability, not just network connectivity.

How It Works in Practice

The core issue is that VPNs typically authenticate the user at the network edge, then hand off broad network reach without preserving enough context about each application request. That works for simple perimeter access, but it breaks down for audit trails because the security team cannot reliably answer three questions from VPN logs alone: which internal app was used, which identity or role acted, and what action occurred inside the app.

Practical compliance teams usually need evidence that can be tied to a named identity and a specific business action. That means correlating VPN telemetry with application logs, IAM events, privileged access records, and, ideally, per-request policy decisions. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because the same governance logic applies to service accounts and machine access: identity evidence has to survive the journey from entry point to application action. NIST guidance on logging and accountability in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that auditability depends on event capture, correlation, and retention.

• Map each internal app to a named owner, role, and data classification.
• Require application logs that record user, action, object, and timestamp.
• Correlate VPN, IAM, and app telemetry into a shared SIEM or audit trail.
• Prefer per-app access controls over “full tunnel” network reach where possible.
• Use conditional access and session controls so evidence is preserved at request time.

For high-risk systems, best practice is evolving toward identity-aware access that proves who did what inside the app, rather than assuming the VPN connection itself is sufficient evidence. These controls tend to break down in legacy environments where internal apps lack structured logging, shared identities are still used, or remote access is terminated before application-layer telemetry can be captured.

Common Variations and Edge Cases

Tighter access logging often increases operational overhead, so organisations have to balance audit depth against latency, system complexity, and user friction. That tradeoff is especially visible in environments with older internal applications, thick-client tools, or segmented networks where application telemetry is incomplete.

There is no universal standard for this yet, but current guidance suggests the strongest model is a layered one: VPN or remote access can remain a transport control, while the compliance evidence comes from application logs, privileged session recording, and identity correlation. Where that is not possible, teams should document the gap explicitly and treat the VPN as a compensating control, not as proof of least privilege.

The same issue appears in outsourced access and break-glass scenarios. A contractor may connect through a VPN for convenience, but auditors still expect proof of what they accessed and why. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows how poor visibility and excessive privilege drive exposure, and SonicWall VPN Mass Breach via Stolen Credentials is a reminder that remote access logs alone do not establish trustworthy identity assurance.

For many organisations, the right question is not whether VPNs are “bad,” but whether they can produce enough session-level evidence for the app, the data, and the control objective. In mixed legacy environments, that answer is often no.

Related resources from NHI Mgmt Group

• Why do separate IAM and PAM systems create audit problems?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?