How should organisations secure VPN access when attackers only need stolen credentials to get in?

Why VPN Access Needs Stronger Proof Than a Password

A VPN is only as trustworthy as the identity check that opens it. If an attacker already has a valid username and password, the VPN becomes an entry point rather than a barrier. The practical fix is to require a second, stronger proof at the point of access and to make that proof harder to reuse outside the approved context.

That matters because VPN credentials are often attractive precisely when remote access is needed quickly. A password alone can be phished, reused, guessed, or bought, while a second factor changes the attacker’s job from simple credential replay to defeating an additional control that is not supposed to travel with the password.

For organisations that want implementation guidance beyond the headline answer, OWASP Non-Human Identity Top 10 is useful for understanding how stolen credentials, overprivilege, and lifecycle gaps create reusable access paths, even though the access channel here is a VPN rather than an application login.

What Makes the VPN Boundary the Right Place to Add Controls

The VPN gateway is a high-value choke point because it concentrates remote access into a small number of authentication decisions. Hardening the boundary is more effective than trying to clean up every downstream system after entry, since once an attacker is inside a trusted network segment, the remaining controls must work much harder.

Adaptive MFA is especially valuable when it evaluates context, not just the static login event. Unusual geolocation, new devices, impossible travel, or a fresh network profile should raise assurance requirements, while routine access from a known device can remain smoother. That approach reduces friction for legitimate users without treating every login as equally safe.

VPN controls also work best when they are part of a broader trust model rather than a standalone toggle. NIST SP 800-207 Zero Trust Architecture is directly relevant because it frames access decisions around continuous verification and policy enforcement instead of assuming that network location alone is trustworthy.

• Require MFA before any VPN session is established, not after the tunnel is already active.
• Use device or context signals to decide when to step up verification.
• Limit the session scope so one approved login does not expose more than the user needs.

Risk and Threat Considerations

When attackers only need stolen credentials to get in, the main risk is not just account takeover, it is the collapse of the remote-access trust boundary. A VPN that accepts passwords alone turns a single compromised secret into broad internal reach, which is why remote access is a frequent path from initial compromise to lateral movement.

Failure mechanism: The password is reused, phished, brute-forced, or stolen elsewhere, then replayed against the VPN without a second proof of possession or inherence. If the VPN does not evaluate risk context, the attacker can authenticate as if the login were legitimate and begin exploring internal systems from a trusted position.

Impact: This can lead to unauthorized access, lateral movement, data theft, and persistence through additional accounts or sessions. The blast radius is especially large when VPN access grants broad internal reach, privileged administration paths, or access to high-value applications without additional segmentation.

That is why credential theft should be treated as an access-path problem, not only an authentication problem. SonicWall VPN Mass Breach via Stolen Credentials is a useful case study for the failure mode, while CISA cyber threat advisories help teams track the broader abuse patterns that follow stolen-credential access.

Practitioner Guidance

What to verify: Confirm that the VPN enforces MFA at the authentication boundary for all remote users, including administrators and third-party access. If any exception exists, verify that it is time-limited, approved, and technically constrained rather than informally accepted.

Decision rule: If the VPN login can succeed with only a password, treat that as a material exposure unless the system is isolated by a compensating control that is equally strong and consistently enforced. Where risk signals are available, make step-up verification the default for unfamiliar devices, locations, or behaviour.

What good looks like: Legitimate users can still connect quickly from normal contexts, but compromised passwords no longer behave like open doors. The best operational outcome is not “more friction everywhere”, it is “more assurance only when the session is unusual or the account is higher risk.”

Practitioner takeaway: VPN security should be measured by whether a stolen password alone can still create a trusted internal session. If the answer is yes, the access model is too weak, regardless of how well the VPN is otherwise configured.

Related resources from NHI Mgmt Group

• How should organisations verify network access when valid Active Directory credentials are stolen?
• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• What do organisations get wrong about secure remote access for vendors and support teams?