A corporate VPN login is unusual among enterprise access points in one specific way: there's nothing standing behind it. A compromised application still sits behind a network perimeter, an EDR agent, and whatever segmentation the internal network enforces. A compromised VPN login is the perimeter — once the username and password clear, the person on the other end may gain much of the same network access as a legitimate remote employee, potentially putting them past a critical layer of perimeter defense.
That's why remote access authentication tends to be the first thing worth checking whenever an organization asks where its actual exposure sits. CISA's Emergency Directive 25-03, issued in September 2025 after threat actors associated with the ArcaneDoor campaign exploited zero-day vulnerabilities in Cisco ASA devices, told federal agencies to submit forensic memory captures within days — a response reserved for the kind of exposure that doesn't wait for a normal patch cycle. Separately, Coalition’s Cyber Threat Index 2025 found that 58% of ransomware claims in 2024 began with the compromise of perimeter security appliances, such as VPNs and firewalls. Whichever specific number an organization trusts most, the underlying pattern is consistent across recent incident response and threat intelligence reports: remote access is where attackers go first, because it's usually the path of least resistance into everything else.
Why VPN Authentication Needs a Second Factor Now, Not Later
Password-Only Login Against Today's Threat Landscape
A password alone stopped being a reliable authentication signal once credential stuffing, password spraying, and infostealer malware became commodity tools rather than specialized attacker capabilities. Credential stuffing tools replay billions of username-password pairs harvested from unrelated breaches, and a success rate of a fraction of a percent against a large enough list still produces working VPN sessions, because VPN login portals may lack the adaptive rate limiting that consumer web applications have had for a decade. Password spraying works the same problem from the other direction — a small number of common passwords tried across a large population of usernames, staying under per-account lockout thresholds by design. None of it requires a vulnerability in the VPN software itself — these techniques work against any login form that accepts a correct password as sufficient proof of identity, regardless of vendor. Fortinet, Cisco, and Ivanti VPN appliances have each produced documented, actively exploited vulnerabilities in the past three years, but credential-based compromise runs in parallel to every one of those vulnerability timelines rather than depending on any of them.
Contractors, Field Technicians, and No-BYOD Policies
Remote access populations skew toward exactly the users an app-based MFA rollout tends to miss. Contractors and third-party vendors frequently need VPN access without being issued a company phone or enrolled in the organization's mobile device management platform, and many organizations have policies that specifically prohibit installing corporate authentication apps on personally owned devices for data-separation reasons. Field technicians in manufacturing, utilities, and logistics often work in locations with unreliable cellular coverage — basements, remote substations, rural service areas — where a push notification or SMS code simply may not arrive when it's needed most. Designing VPN authentication around the assumption that every remote user carries a smartphone with reliable connectivity leaves exactly this population as the gap that eventually gets found. Either an auditor finds it during an access review, or an attacker finds it first — by targeting the accounts still sitting on password-only fallback because MFA "couldn't be enrolled" for them.
RADIUS as the Universal Layer Across Any VPN Vendor
The Access-Request, Access-Challenge, Access-Accept Flow
RADIUS authentication runs on a simple exchange defined in RFC 2865: the VPN gateway sends an Access-Request containing the username and password to a RADIUS server, which validates the credentials — typically against Active Directory or LDAP — and replies with Access-Accept, Access-Reject, or Access-Challenge. That third response type is where a second factor slots in without touching the underlying protocol: instead of accepting immediately once the password checks out, the server issues an Access-Challenge asking for a one-time password, and only returns Access-Accept once that OTP is validated as well. A correct password on its own now clears exactly one of two required steps.
One Proxy Instead of a Separate Agent Per Vendor
MFA for VPN access built on this RADIUS proxy pattern works the same way regardless of which vendor's gateway is sending the Access-Request, because support for standard RADIUS authentication and the required challenge-response flow — not a specific vendor's proprietary API — is the main requirement on the device side. That matters for any organization running more than one VPN platform — from an acquisition, a multi-site rollout with inconsistent hardware standardization, or a planned migration between vendors. A single RADIUS proxy covers all of them from one deployment, one user directory, and one enrollment process, rather than a separate MFA agent — and a separate learning curve — for each gateway brand in the environment.
Cisco AnyConnect as a Case Study
Why ASA Specifically Draws Sustained Attention
Cisco's ASA and Firepower Threat Defense (FTD) platforms are among the most widely deployed enterprise VPN concentrators in existence, which makes them a target independent of any specific vulnerability disclosure. Brute-force and credential-stuffing campaigns against ASA login portals have been documented consistently through 2025, running in parallel to the exploitation campaigns that produce the CISA emergency directives. A device this widely deployed draws sustained attacker attention on both fronts at once, which is part of why it's a useful case study for what a RADIUS-based second factor actually changes: it addresses the credential-based path directly, regardless of whether the exploitation-based path has been fully patched at any given moment.
Adding RADIUS-Based 2FA Without Touching the AnyConnect Client
Two-factor authentication for Cisco AnyConnect integrates by pointing the ASA's existing RADIUS configuration at an MFA RADIUS proxy rather than its existing authentication server — a change made once, on the ASA's AAA server group settings, with no modification to the AnyConnect client software installed on end-user devices. Authentication requests continue routing through standard RADIUS, typically over UDP 1812, exactly as they did before the proxy was introduced; the main difference from the end user's perspective is a second prompt for a one-time password after their normal credentials are accepted.
Hardware Tokens for VPN Login: When They Beat a Phone
Where a Physical Token Solves a Problem an App Can't
For the contractor and field-technician population described earlier, a hardware OATH token sidesteps every constraint that makes smartphone-based MFA impractical: no cellular signal is required, no personal device enrollment is needed, and no company phone has to be issued and later retrieved when the contract ends. The token generates its one-time password locally, independent of network connectivity of any kind — a property that matters specifically for VPN access, since the moment someone most needs to connect remotely is sometimes the same moment local connectivity elsewhere is unreliable. It also removes a category of support tickets that app-based rollouts generate reliably: a lost or replaced phone that breaks an authenticator app's enrollment, a corporate MDM policy that wipes the app during an unrelated device reset, or a personal phone the employee simply declines to install a work authenticator on.
Token Flexibility: TOTP, HOTP, and Reassignment
Hardware tokens used with a RADIUS-based MFA deployment aren't necessarily limited to one vendor's ecosystem or one algorithm. TOTP tokens generate a new code on a fixed interval, generally 30 or 60 seconds, and cover the majority of standard login scenarios. HOTP tokens increment a counter instead, providing an alternative for deployments where time-based code generation isn't preferred. Reprogrammable TOTP tokens carry a practical advantage specific to contractor and contingent-workforce populations with routine turnover: a token issued to one contractor can be wiped and re-seeded for the next one, rather than retired and repurchased every time a contract ends, which matters more the higher the turnover rate in that population runs.
Deploying a RADIUS-Based Second Factor Step by Step
From Existing VPN Config to a Working Pilot
The path from a password-only VPN gateway to a working two-factor deployment follows a consistent sequence regardless of vendor. RADIUS authentication describes the full process. At a practical level, it starts with deploying the proxy itself and connecting it to the existing directory — domain controller address, bind account, and search base for AD or LDAP — then registering the VPN gateway as a RADIUS client with a shared secret matched on both ends. Next comes updating the gateway's authentication configuration to point at the new RADIUS proxy rather than its existing authentication server, and enrolling a pilot group of users with either an authenticator app or a hardware token, running the full authentication flow end to end before widening the rollout to the full remote-access population. These steps generally require little or no VPN downtime, with the main configuration change being the update to the gateway's authentication settings, and the underlying VPN client software — whatever brand it happens to be — continues functioning as before, while the VPN gateway continues using standard RADIUS for authentication.
Failover Matters as Much as the Initial Setup
A detail worth building in from the start rather than retrofitting later: registering both a primary and a secondary RADIUS server on the gateway, using the gateway's supported RADIUS failover behavior, so a single proxy instance going offline doesn't take remote access down with it. For a service that's frequently needed most during exactly the kind of outage that makes other access paths unreliable, that redundancy isn't optional hardening — it's part of the baseline design.
Closing the Gap Before It Gets Found
The pattern across recent VPN-related CISA advisories and incident response reports points at the same underlying weakness: a password, checked in isolation, is no longer sufficient proof that the person on the other end of a remote connection is who they claim to be. RADIUS closes that gap without requiring a rebuild — the protocol most enterprise VPN gateways already speak includes the exact message type needed to add a second factor, and a single proxy deployment extends that coverage across every vendor's gateway an organization happens to run, with hardware tokens available for the population a smartphone app can't reliably reach.
