Organisations should add adaptive multi-factor authentication at the VPN boundary, not rely on passwords alone. MFA raises identity assurance by requiring a second proof of possession or inherence before access is granted. A good implementation also steps up verification only when risk rises, such as unusual location or device context, so security improves without creating unnecessary friction.
Why VPN login is no longer the real trust boundary
A VPN no longer deserves automatic trust just because the connection terminated inside the corporate network. If an attacker can steal a valid username and password, they can often get the same level of access as the legitimate user unless the VPN also verifies context and adds a stronger second factor. That is why the right control point is the VPN boundary itself.
Stolen credentials are especially dangerous because they bypass many perimeter assumptions. Once the login succeeds, the attacker can enumerate internal services, pivot to higher-value systems, and blend in with normal remote access unless the session is bound to stronger identity assurance. SonicWall SSL VPN account compromises 2025 is a useful reminder that valid logins can be enough to create widespread exposure.
Modern VPN security therefore needs to treat the password as only one signal. Adaptive multi-factor authentication raises the cost of account theft by requiring an additional proof, and it should be able to step up when the login looks unusual rather than forcing the same friction on every session.
What adaptive MFA changes at the VPN boundary
Adaptive MFA is not just a second prompt. It is a policy decision that asks whether the login attempt matches the user’s usual device, location, network, and behaviour before granting access. If the context is ordinary, the user experience can stay light. If the context looks suspicious, the VPN can require stronger verification or block the session entirely.
That matters because attackers who buy or phish credentials usually rely on valid authentication, not malware. A contextual challenge can interrupt that abuse even when the password has already been exposed. The goal is to make stolen credentials insufficient on their own, while still keeping access workable for legitimate users.
Done well, this also reduces the temptation to overtrust a device that has not been checked recently. Pairing adaptive MFA with device posture signals, conditional access, and short-lived sessions makes the VPN behave more like a controlled access service and less like a blanket network tunnel. Remote Access Identity Guide covers the broader design choices around VPN MFA, ZTNA, device posture, third-party access, and dormant remote access accounts.
What to harden when credentials may already be stolen
If you assume some credentials will eventually leak, the practical question becomes what an attacker can do after the first successful login. That is where session lifetime, reauthentication rules, and downstream privilege boundaries matter most. A VPN that authenticates once and then grants broad, persistent reach is much easier to abuse than one that continuously reassesses trust.
It is also important to review whether the VPN account is more privileged than the user actually needs. Remote access should not be a hidden path into every internal segment, especially for third-party, support, or administrative access. Broad reach turns a single stolen password into a high-blast-radius incident.
Where the environment still depends on passwords, organisations should keep an eye on reuse, long-lived credentials, and dormant accounts. Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful for the underlying credential-lifecycle lesson: long-lived secrets are easier to steal, replay, and reuse than short-lived ones.
Risk and Threat Considerations
When VPN access is protected only by a password, the main risk is account takeover with little friction. An attacker who buys, phishes, or infosteals a credential may be able to log in from anywhere, reuse the session for persistence, and move laterally before defenders notice.
Failure mechanism: The VPN accepts the stolen credential as sufficient proof, then grants network access without a meaningful second check on user context, device state, or session trust.
Impact: The compromise can look like normal remote work, which delays detection and expands the blast radius to internal applications, admin tools, and sensitive data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | VPN user access depends on strong remote user authentication. |
| IA-5 — Authenticator Management | Stolen passwords and long-lived credentials are the core exposure here. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Remote access often includes contractors and third parties using VPN access. | |
| Recommendation — Require strong user authentication for VPN logins and step up verification on risk signals. Manage credential lifecycle tightly and rotate or revoke exposed authenticators quickly. Apply strong authentication controls to external VPN users and separate their access paths. | ||
| NIST Zero Trust (SP 800-207) | 5.1 — Never trust, always verify | Adaptive MFA and contextual checks are central Zero Trust responses to stolen credentials. |
| Recommendation — Treat every VPN session as untrusted until identity and context are revalidated. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Remote access scope and account governance determine how far a stolen login can reach. |
| Recommendation — Restrict VPN access to the minimum required services and remove dormant accounts promptly. | ||
Practitioner Guidance
What to verify: Confirm that the VPN enforces MFA at the authentication boundary, not just for some downstream application. Test that high-risk logins, unfamiliar devices, and unusual geographies trigger step-up verification or denial.
Decision rule: If a stolen password alone can still open a remote session, treat that as a design gap, not a user-awareness issue. Tighten authentication policy first, then reduce session longevity and access scope so one compromised login does not become broad network reach.
Practitioner takeaway: The secure design target is not “stronger passwords”, it is stolen-credential resistance at the point where access is granted.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org