One RADIUS Layer, Every Login: Adding MFA to VPN, Wi-Fi and Network Devices at Once
Ask five network engineers how MFA is deployed across their environment and you’ll typically get five different answers for five different services — one product bolted onto the VPN concentrator, a different mechanism for Wi-Fi, a third for switch admin access, and Microsoft NPS sitting somewhere in the middle doing its own thing. Each integration was solved once, under deadline pressure, by whoever owned that particular ticket, and none of them talk to each other.
That fragmentation is technical debt with a security cost attached. Every separate MFA product is a separate vendor relationship, a separate directory sync (or worse, a manual user list), and a separate thing that can silently stop enforcing while everyone assumes it still is. A network engineer auditing “where does MFA actually run” across an environment built this way often can’t answer completely without checking four or five different admin consoles.
RADIUS solves this because most of what needs MFA already speaks RADIUS. VPN concentrators, 802.1X wireless authentication, switch and router admin logins, RDP gateways, NPS deployments — nearly all of them were built around the same client/server protocol, defined in RFC 2865, specifically to centralize authentication, authorization, and accounting across exactly this kind of heterogeneous device population. The protocol already does the centralizing. What it was never built to do is verify that the password it’s checking actually belongs to the person typing it, and that gap isn’t theoretical: the Verizon 2026 Data Breach Investigations Report puts the human element — social engineering, credential misuse, and simple error — behind 62% of the breaches it analyzed, with stolen or reused credentials a recurring thread across that category regardless of which specific network service the attacker ultimately reached.
The RADIUS Proxy Pattern, and Why It’s Generic by Design
RADIUS authentication runs on a simple request-response exchange. The network device — RADIUS calls it the NAS, or Network Access Server, regardless of whether it’s a VPN gateway, a wireless controller, or a switch — sends an Access-Request packet containing the username and password to a RADIUS server. The server checks the credentials, typically against Active Directory or LDAP, and replies with one of three outcomes: Access-Accept, Access-Reject, or Access-Challenge, the last of which asks for additional information before a final decision.
That third message type is the entire mechanism MFA rides on. Inserting a second factor into RADIUS authentication doesn’t require rewriting the protocol or replacing the NAS devices — it means putting a proxy between the device and the directory it already trusts. The NAS keeps sending Access-Requests exactly as before, to the same UDP 1812 authentication port; it just points at a different IP address. That proxy validates the password against AD or LDAP first, and if the password is correct, it doesn’t send Access-Accept immediately — it sends Access-Challenge, prompting for a one-time password. Only after the OTP checks out does Access-Accept go back to the NAS. A password on its own — correctly guessed, phished, or bought from a credential marketplace — clears exactly one of the two required steps.
The network topology this produces is a straight line, not a mesh: NAS device → RADIUS proxy → AD/LDAP, with OTP verification happening inside the proxy itself rather than requiring the NAS or the directory to know anything about one-time passwords. Each NAS device is registered on the proxy with its own IP address and shared secret — the same secret configured on the device side — which authenticates the device-to-proxy conversation, distinct from the username and password authenticating the end user. A mismatched shared secret is the single most common reason a RADIUS MFA pilot fails silently on day one: the NAS sends its Access-Request, gets no usable response, and falls back to whatever its local failure policy dictates — denying access outright on some devices, silently reverting to local authentication with no MFA enforced at all on others. Confirming the secret matches on both ends before touching production authentication policy is worth the extra five minutes.
The reason this pattern generalizes so cleanly across VPN, Wi-Fi, and network device admin access is that all three were already using RADIUS as a shared authentication backbone, specifically because RFC 2865 was designed for heterogeneous access scenarios. A proxy that speaks standard RADIUS doesn’t need Cisco-specific code, Fortinet-specific code, or Aruba-specific code — any device with compatible RADIUS authentication support can potentially work, including ones that were never explicitly tested against a given vendor’s product documentation.
Where One Layer Covers Multiple Access Scenarios
VPN Remote Access
VPN remote access is the deployment most engineers picture first, and it’s also the one with the sharpest recent example of what happens without it. In June 2026, government agencies and security researchers issued warnings about what researchers named the FortiBleed campaign — a large-scale credential compromise campaign affecting internet-accessible FortiGate devices. Fortinet’s own guidance attributed the activity partly to credential reuse from earlier incidents and partly to brute-force against devices with weak password hygiene and no MFA. Remediation guidance for the campaign named MFA across administrator and VPN accounts as one of the primary hardening steps.
802.1X and Wi-Fi Authentication
802.1X and Wi-Fi authentication run through the same RADIUS backbone in most enterprise wireless deployments, though the exact flow depends on the authentication method and wireless infrastructure in use — a wireless controller or access point acts as the NAS, forwarding the client’s authentication exchange to a RADIUS server. Guest Wi-Fi captive portals, such as deployments built on the Ubiquiti UniFi Guest Portal, can authenticate against RADIUS as well, with users completing a one-time password step delivered through SMS, chatbot, or email rather than a full 802.1X supplicant exchange.
NPS Proxy Scenarios
NPS proxy scenarios come up in Windows-heavy environments where Microsoft’s Network Policy Server already sits in the authentication path for VPN or Wi-Fi. NPS can potentially be used as a RADIUS proxy with a RADIUS-based MFA layer such as Protectimus, allowing authentication requests to be forwarded for MFA processing. This configuration should be validated for the specific deployment.
Network Equipment Admin Access
Network equipment admin access — the RADIUS-based AAA login used for switch, router, and firewall management interfaces — is arguably the highest-value target of the four, because a compromised admin session on a Cisco Catalyst switch or a firewall’s management plane doesn’t just grant network access, it grants control over the network itself. Documented integrations exist for Cisco Catalyst switch AAA login specifically, alongside the more commonly discussed VPN and Wi-Fi scenarios.
RDP Gateways
RDP gateways fed by a RADIUS-based authentication policy inherit the same pattern, extending the challenge/response or inline OTP flow to remote desktop session brokers without requiring a separate MFA agent on each terminal server.
The throughline across all five scenarios is that none of them required a purpose-built integration. They required one RADIUS-based MFA layer, with compatible access systems pointed at it.
Deploying a Single MFA Layer Through RADIUS
Getting from “several disconnected MFA tools” to “one RADIUS layer” is a five-step process that doesn’t touch the NAS devices’ underlying configuration beyond redirecting where they send authentication requests. RADIUS authentication with MFA describes the full deployment path; at a practical level, it breaks down as follows.
First, deploy the RADIUS proxy itself — either inside the network and connected to the cloud MFA service, or as part of a fully on-premises MFA server deployment on standard Windows Server or Linux hosts for organizations with data residency requirements or air-gapped segments. Second, point the proxy at the existing directory: domain controller address, bind account, and search base for AD or LDAP, tested before moving further. Third, register each NAS device as a RADIUS client on the proxy — IP address and shared secret per device, matching what gets configured on the device side next. Fourth, on each VPN gateway, wireless controller, or switch, change the configured RADIUS server IP to the proxy and set the matching secret, using UDP port 1812. Fifth, enroll a pilot group, assign an authenticator app or hardware token, and run the full authentication flow end to end before widening the rollout.
None of these five steps requires downtime on the NAS devices beyond the brief window needed to update a RADIUS server IP address, and none of them requires the underlying directory schema to change.
The Same Server, One Scenario at a Time: VPN Remote Access
It’s worth walking through one scenario end to end to see how little changes on the device side. MFA for VPN access through this same RADIUS proxy pattern doesn’t touch the VPN client software at all — Cisco AnyConnect, FortiClient, and GlobalProtect all continue connecting as before, while their respective VPN gateways send standard RADIUS requests to whatever server address is configured, unaware that a proxy now sits in front of the directory.
Two technical details determine whether the rollout goes smoothly on day one. The first is Access-Challenge support: most current VPN clients handle it natively, displaying a secondary OTP field right after the password is accepted, with no client-side reconfiguration needed. Older or more limited clients that don’t support RADIUS Access-Challenge need inline mode instead — password and OTP entered together in a single field, separated by a configurable delimiter such as a comma, parsed into its two components by the proxy before each is validated separately. The second is failover: primary and secondary RADIUS server instances, both registered on the NAS device using standard RADIUS failover behavior — the device can retry against the secondary if the primary doesn’t respond within its configured timeout — is how high availability gets built into this architecture without a single point of failure at the authentication layer.
What Runs on the Infrastructure Side: The RADIUS Server Component
The piece that actually sits in the network, doing the proxying, is a single deployable component rather than a suite of per-service integrations. The Protectimus RADIUS server component is what network devices talk to directly — it accepts the incoming RADIUS Access-Request from whichever NAS sent it, validates the password against AD or LDAP, issues an Access-Challenge for the OTP when challenge-response is used, and returns the final Access-Accept or Access-Reject once the required factors are validated.
Because that component speaks standard RFC 2865 RADIUS rather than a proprietary variant, any RADIUS client sending standard Access-Requests is a candidate — no certified per-vendor compatibility testing required — which is precisely why the same deployment covers VPN gateways, wireless controllers, and switch admin logins without three separate integration projects. System requirements are correspondingly light: Windows, Linux, or Docker for the proxy itself, standard RADIUS ports (UDP 1812 for authentication, UDP 1813 if accounting is used), and LDAP or LDAPS access to the directory doing primary credential validation.
One Layer Instead of a Zoo of Integrations
The alternative to this architecture isn’t a hypothetical — it’s the default state most networks drift into without a deliberate decision to avoid it. A VPN vendor’s proprietary MFA agent here, a wireless controller’s built-in one-time-password feature there, a separate product for switch admin login because nobody got around to including it in the original VPN project. Each piece works in isolation, none of them share a directory sync or a failure alert, and a lapsed license or misconfigured integration on any one of them can silently drop back to password-only authentication without anyone noticing until an incident review turns it up.
Consolidating onto a single RADIUS proxy doesn’t just simplify the architecture diagram. It means one place to check when auditing MFA coverage, one directory sync to maintain, one failover configuration to test, and one vendor relationship instead of four or five running in parallel, each with its own renewal date and support contract. For a network team already stretched across firewall management, wireless troubleshooting, and everything else RADIUS quietly touches, that consolidation is the difference between being able to answer “is MFA actually enforced everywhere it should be” with confidence, and having to check five consoles to find out.
The FortiBleed campaign is one data point, not an outlier — remediation guidance for it named MFA across administrator and VPN accounts as a primary hardening step for the same reason network security advisories keep returning to that recommendation across vendors and years: a RADIUS-authenticated device without a second factor is one leaked or guessed password away from a fully authenticated session, whether that device is a VPN concentrator, a wireless controller, or a switch’s management interface. Consolidating the fix into one RADIUS layer is what keeps that answer consistent across every device that layer covers, rather than depending on which team happened to configure which service first.