RADIUS Authentication in 2026: Why Every VPN and Wi-Fi Network Needs MFA

RADIUS turned 30 this year. The protocol that quietly runs authentication for most corporate VPNs, Wi-Fi networks, and dial-up infrastructure was standardized in 1994 — back when "remote access" meant a modem and a phone line, and the threat model looked nothing like today.

Three decades later, the protocol itself hasn't fundamentally changed. Your Cisco firewall still sends an Access-Request packet to a RADIUS server. The server still replies with "Accept" or "Reject". The format is still UDP. What has changed beyond recognition is the threat environment in which the protocol operates, and that mismatch is what makes RADIUS-only authentication a liability in 2026.

This article is about that gap: why RADIUS without a second factor is a structural problem, not a configuration problem, and what it actually looks like to close it without rebuilding your network from scratch.

How RADIUS Authentication Works (and Where It Falls Short)

To understand why RADIUS needs MFA, you first need to understand what RADIUS actually does — and, more importantly, what it doesn't.

RADIUS, defined in RFC 2865, operates on a straightforward client/server model. When a user tries to connect to a VPN or authenticate to a corporate Wi-Fi network, the network device, called the NAS (Network Access Server), packages their credentials into an Access-Request packet and sends it to the RADIUS server over UDP port 1812.

The server has three possible replies:

1. Access-Accept: Credentials validated; the user is granted access.
2. Access-Reject: Credentials are invalid; the connection is denied.
3. Access-Challenge: Additional information is required before access can be approved.

That third response type is actually how MFA gets bolted onto RADIUS. The server asks for something beyond the password, the client provides it, and the server makes a final decision. The mechanism exists in the protocol. The problem is that most RADIUS deployments never use it. They're set up as a two-state system: password good, let them in.

So what's actually protecting access? A shared secret between the NAS and the RADIUS server (to authenticate that the request is coming from a legitimate device), and the user's password. That's it. No second factor. No behavioral check. No device fingerprint. Just a string of characters the user types, transmitted to a server that checks it against a directory.

In 1994, that was probably fine. In 2026, it's a known attack surface that threat actors have commoditized.

The Rise of VPN Credential Attacks

The practical consequence of password-only RADIUS is evident in incident data.

Fortinet disclosed in 2024 that threat actors had published a list of credentials for approximately 87,000 FortiGate SSL VPN devices — credentials obtained not through a software vulnerability, but through straightforward credential attacks against exposed RADIUS-authenticated endpoints. Cisco has issued multiple security advisories about credential-stuffing campaigns targeting AnyConnect VPN authentication. Pulse Secure (now Ivanti) VPN endpoints have appeared in CISA threat advisories as targets for exactly this kind of attack.

The CISA advisory on VPN security is consistent in its recommendations: require MFA for all remote access, full stop. Not as a defense-in-depth measure on top of stronger primary authentication — as the primary additional control because password-only authentication is considered an insufficient baseline for any internet-facing service.

The attack pattern is consistent across all these incidents. Attackers don't need to exploit RADIUS itself. They don't need to break TLS or intercept UDP packets. They get a credential list from a phishing campaign, a data breach, or a dark web purchase, point an automated tool at the VPN gateway, and wait. Some percentage of users will have reused passwords, used predictable patterns, or had their exact credentials in a breach dump. That percentage is enough.

What makes VPN endpoints particularly attractive is the access they provide. Successful VPN authentication puts an attacker inside the network perimeter with lateral movement options that an internet-facing web app breach doesn't offer. One working credential can be worth days of subsequent access.

How MFA Integrates with RADIUS: Proxy vs Extension Approach

There are two architecturally distinct ways to add MFA to RADIUS authentication, and they behave very differently in practice.

The extension approach involves adding MFA logic directly to an existing RADIUS server — the most common example being the Azure MFA extension for Microsoft NPS. The existing RADIUS server can trigger a second-factor check. This works, but it ties the MFA capability to the specific server software and typically creates a cloud dependency: the extension calls out to a cloud service to initiate the second factor, which means every authentication event requires internet connectivity and introduces a cloud provider into the authentication chain.

The proxy approach inserts a dedicated MFA layer between the network device and the existing RADIUS infrastructure. The NAS sends its Access-Request to the proxy instead of directly to the original RADIUS server. The proxy validates the password upstream against Active Directory or LDAP and, if correct, issues an Access-Challenge for the second factor. Only after both factors are validated does the proxy return an Access-Accept to the NAS.

The difference matters operationally. With the proxy approach, your existing NPS or FreeRADIUS configuration stays unchanged. The NAS device points to a new IP. If you need to roll back, you point the NAS back to the original IP, and the proxy is entirely out of the picture. There's no modification to production infrastructure, no new software installed on your RADIUS server, and no dependency on external cloud services if you deploy the proxy on-premises.

For environments where the RADIUS infrastructure is already complex, a proxy-based deployment may require fewer changes to existing RADIUS server configurations because it accepts requests from the NAS and forwards them to the existing RADIUS server. When adding MFA to RADIUS authentication infrastructure, this approach allows MFA to be introduced into the authentication flow without restructuring the existing RADIUS infrastructure.

Use Cases: VPN, Wi-Fi 802.1X, and NPS

The same RADIUS proxy infrastructure covers meaningfully different access scenarios, and each has its own practical considerations.

VPN is the highest-stakes scenario and the most common deployment target. The UX question that comes up immediately: how does a VPN client handle a second-factor prompt when there's no browser involved? Most modern clients — Cisco AnyConnect, Fortinet SSL VPN, Palo Alto GlobalProtect — support RADIUS Access-Challenge natively. After entering their password, the user sees a secondary prompt in the VPN client requesting an OTP. For older clients or configurations where challenge/response creates problems, there's a fallback: password concatenation, where the user types their TOTP code appended to their password in a single field. Less elegant, but it works with any RADIUS client that doesn't support challenge/response.

Wi-Fi 802.1X is a different environment. Authentication happens at the OS supplicant level — before a user session even exists — which rules out any second factor that requires an active UI interaction, like push notifications. TOTP via an authenticator app or hardware token is the practical choice here: the user enters a code, the supplicant passes it through EAP-TTLS or PEAP, and the RADIUS proxy validates it. Hardware tokens are particularly useful in environments where smartphone use is restricted (manufacturing floors, secure facilities).

Microsoft NPS scenarios deserve a specific note. NPS is embedded deeply in many Windows environments. It handles VPN authentication, Wi-Fi 802.1X, and sometimes wired 802.1X, often tied to complex network policy configurations that have been in place for years. A RADIUS proxy sits upstream of NPS rather than modifying it. In this architecture, the proxy receives RADIUS requests from the VPN gateway, validates the second factor, and forwards the password check to NPS, which continues applying its existing connection authorization policies. NPS never sees the MFA layer; it simply processes the forwarded RADIUS request.

Choosing the Right RADIUS MFA Solution

When evaluating options, the criteria that tend to matter most in production environments fall into a few categories.

On-Premises vs. Cloud Deployment

For organizations with data residency requirements, air-gapped segments, or internal policies that prohibit authentication traffic leaving the perimeter, on-premises deployment may be preferred. The proxy runs inside the network, so authentication credentials do not traverse the public internet. Cloud deployment can reduce infrastructure management because there is no server to maintain. The appropriate choice depends on an organization's compliance, operational, and security requirements.

Active Directory Integration

The RADIUS proxy needs to validate passwords against something. Direct AD/LDAP integration, where the proxy binds to a domain controller and validates credentials directly, can reduce the need for separate user synchronization compared with deployments that rely on a cloud directory. For environments with multiple domains or complex trust relationships, support for multi-domain authentication may also be an important consideration.

High Availability

Authentication is infrastructure. If the RADIUS proxy goes down, VPN users can't connect, Wi-Fi 802.1X clients can't authenticate, and anyone working remotely is locked out. Primary/secondary failover, where the NAS automatically retries against a secondary RADIUS server if the primary doesn't respond within the timeout period, is the standard approach. Evaluate whether the secondary instance shares enrollment data with the primary — if it doesn't, a failover could force users to re-enroll their tokens.

Hardware Token Support

Software authenticator apps cover most users, but every environment has edge cases: manufacturing workers without smartphones, executives who refuse to use personal devices for work authentication, air-gapped segments where apps can't receive time sync. Full OATH-compliant hardware token support for both TOTP and HOTP supports these deployment scenarios without requiring a separate authentication infrastructure.

Platform Coverage

For environments where RADIUS MFA is one piece of a larger access security project, it's worth considering whether the same MFA platform can cover Active Directory logons, Windows Logon, and RDP alongside RADIUS. A single enrollment, a single admin console, and a single token working across VPN, desktop logon, and remote desktop sessions can reduce the number of separate enrollment and administration processes. MFA for Active Directory and LDAP environments through the same platform means allowing the same enrolled authentication factor to be used across supported services.