Who is accountable when legacy VPN infrastructure remains in place after exposure risks are known?

Why This Matters for Security Teams

When legacy VPN access stays in place after the exposure risks are already known, accountability shifts from a narrow infrastructure decision to a governance decision. The question is not just whether the tunnel still works, but who accepted the residual risk, who owns the access path, and who is responsible for proving that stronger controls were considered. That matters because VPNs often become a default path for privileged movement, not a temporary fallback.

NHIMG research shows how quickly identity-related exposure compounds in practice: the 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge both point to how access paths become harder to govern once they are embedded across teams and workflows. NIST’s Cybersecurity Framework 2.0 reinforces that this is a leadership and risk-management issue, not only an engineering issue.

In practice, many security teams discover that a VPN was still trusted as a “temporary” control only after it has already become a long-lived exception with no clear owner.

How It Works in Practice

Accountability for an exposed legacy VPN usually sits across three groups: identity governance, remote access architecture, and infrastructure risk ownership. In mature programmes, those groups should be aligned under a formal risk decision process so that continuing the VPN is an explicit acceptance, not an inherited default. Current guidance suggests treating the VPN as a high-risk access broker, especially where privileged users, contractors, or service identities can reach sensitive systems through it.

A practical review should answer four questions: who approved the exception, what compensating controls are in place, how often the risk is re-evaluated, and what exit plan exists. NIST’s Security and Privacy Controls support this kind of control-by-control review, while NHIMG’s Top 10 NHI Issues and SonicWall VPN Mass Breach via Stolen Credentials show why remote access paths become attractive once credentials or access tokens are exposed.

• Assign a named risk owner for the VPN exception, not just a technical operator.
• Document whether the VPN is serving interactive users, administrative access, or non-human workloads.
• Require time-bounded reviews and evidence of compensating controls such as MFA, device posture checks, segmentation, and logging.
• Track migration to stronger patterns, such as zero trust access or per-application controls, rather than indefinite extension.

This guidance breaks down in environments with deeply embedded third-party dependencies, where application redesign or partner re-onboarding makes rapid VPN removal operationally unrealistic.

Common Variations and Edge Cases

Tighter access control often increases operational friction, requiring organisations to balance exposure reduction against support burden, vendor constraints, and migration complexity. That tradeoff is real in regulated environments, industrial networks, and merger integration scenarios where the VPN may be the only workable bridge while a replacement path is built.

There is no universal standard for this yet, but best practice is evolving toward risk acceptance with explicit sunset criteria. If the VPN remains in place because it is needed for a narrow set of users or systems, then the accountable party should be the one empowered to accept that exception and fund its replacement. If the path is being used by privileged administrators, the control should be reviewed like high-risk identity infrastructure, because the exposure is often not the tunnel itself but the credentials and standing access behind it.

In highly automated environments, legacy VPNs also create blind spots for non-human identities, service accounts, and machine-to-machine access. Once those pathways mix human and machine access, ownership becomes harder to trace and incident response slows. When that happens, the organisation usually needs a formal decision record, a remediation timeline, and a control owner who can be challenged in audit.

Related resources from NHI Mgmt Group

• Who is accountable when legacy software keeps running after support ends?
• Who is accountable when weak authentication remains in place after a regulatory update?
• Who is accountable when access remains in place after it should have been removed?
• Who is accountable when privileged access remains in place after a role change or merger?