RADIUS Authentication with MFA: Secure Every Network Access Point
RADIUS — the protocol that quietly handles authentication for most corporate VPNs, Wi-Fi networks, and network infrastructure — was built for a different era. It does its job reliably: a network device sends credentials to a RADIUS server, the server checks them against a directory, and access is granted or denied. What it doesn’t do is verify that the person entering those credentials is actually who they claim to be. A stolen password is as good as a real one.
Adding MFA to RADIUS closes that gap. Instead of replacing your existing infrastructure, a RADIUS proxy sits between your network devices and your directory — enforcing a second factor on every authentication request before issuing an Access-Accept.
Table of Contents
- What Is RADIUS Authentication and Why It Needs MFA
- How Protectimus Adds MFA to RADIUS Authentication
- Supported MFA Methods for RADIUS
- Supported RADIUS Clients & Network Equipment
- RADIUS MFA for VPN
- RADIUS MFA for Wireless Network Access
- Deployment Options
- System Requirements & Integration
- Step-by-Step: How to Set Up RADIUS MFA in 5 Steps
- Compliance: How RADIUS MFA Satisfies Regulatory Requirements
- Frequently Asked Questions
- Start Securing Your Network Access Today
Quick Answer
RADIUS (Remote Authentication Dial-In User Service) is the backbone of network access control in most enterprise environments — handling authentication for VPNs, corporate Wi-Fi, network access devices, NPS, and VDI gateways. The protocol itself, defined in RFC 2865, was designed decades before modern credential-based attacks became the norm. Adding MFA on top of RADIUS today means inserting a second verification step between the network device and your directory — without replacing your existing infrastructure. Protectimus works as a RADIUS proxy: your Cisco firewall, Fortinet gateway, or Palo Alto firewall keeps talking RADIUS exactly as before, while a second factor is enforced at the proxy layer before a RADIUS Access-Accept is issued.
Key facts
Credentials are the #1 attack vector
Credential-based attacks — including phishing, credential stuffing, and password spraying — consistently rank among the top initial access vectors for network breaches, with VPN endpoints being a primary target.
AAL2 mandates MFA
NIST SP 800-63B Authenticator Assurance Level 2 (AAL2) explicitly requires multi-factor authentication for any network access to sensitive systems.
VPN infrastructure is under attack
CISA’s advisory on VPN security notes that attackers routinely target remote access infrastructure specifically because it often lacks a second authentication factor.
Key Takeaways
No infrastructure changes required
Protectimus operates as a RADIUS proxy; your existing VPN gateways, wireless controllers, and network switches keep their configuration.
Fast deployment
Many organizations can implement RADIUS MFA within a single business day, depending on infrastructure complexity and integration requirements.
Vendor-agnostic
Tested and documented integrations with Cisco ASA/FTD, Juniper, Fortinet FortiGate, Palo Alto GlobalProtect, SonicWall, Check Point, F5, and many other platforms.
Full AD/LDAP sync
User provisioning, group policies, and directory lookups all pull from your existing Active Directory or LDAP.
On-premises or cloud
Deployment options are available, allowing organizations to choose the architecture that best fits their security and operational requirements.
Designed for VPN
and other RADIUS-based remote access scenarios.
What Is RADIUS Authentication and Why It Needs MFA
RADIUS is a client/server protocol that centralizes authentication, authorization, and accounting (AAA) for network access. When a user connects to a VPN, authenticates to corporate Wi-Fi, or logs into a switch over a management interface, the network device (called the NAS — Network Access Server) sends an Access-Request packet to the RADIUS server. That server validates the credentials and replies with one of three messages: Access-Accept (let them in), Access-Reject (deny), or Access-Challenge (request additional information, such as an OTP).
It’s a tidy, battle-tested protocol. But its original design assumed that a valid username/password combination was sufficient proof of identity. In 2026, that assumption is untenable.
Why passwords alone don’t protect RADIUS-authenticated services
Credential stuffing is the attack that keeps network security teams up at night. Attackers buy or scrape lists of leaked username/password pairs — billions of them are freely traded on criminal forums — and automate login attempts against VPN endpoints. Most VPN gateways don’t have lockout policies tight enough to stop low-and-slow attacks. Even a 0.5% success rate against a 50,000-credential list hands attackers 250 valid VPN sessions.
Password spraying is the quieter variant: instead of hammering one account, attackers try one common password (like Autumn2024!) across thousands of accounts. It bypasses most account lockout thresholds and is nearly invisible in logs.
Beyond spray-and-pray, targeted attackers use phishing to harvest domain credentials, then pivot directly to VPN or Wi-Fi access — completely bypassing perimeter defenses.
RADIUS itself has no mechanism to enforce a second factor. It passes credentials to a backend directory, gets Accept/Reject back, and that’s the end of the conversation. One common way to add MFA to RADIUS is to deploy a RADIUS proxy that intercepts the Access-Request, validates the password upstream, and then enforces an OTP challenge before issuing an Access-Accept.
How Protectimus Adds MFA to RADIUS Authentication
Authentication flow
VPN / Wi-Fi Client
Cisco ASA / FortiGate / UniFi / etc.
Validate password via AD / LDAP
Returns Access-Challenge (OTP)
Validate OTP
Returns Access-Accept
User session established
Step 1 — Credential check. Protectimus forwards the user’s password to Active Directory or LDAP for primary authentication. If the password fails, the request is rejected immediately. No MFA prompt is issued for failed passwords — this prevents enumeration attacks.
Step 2 — MFA challenge. After a successful password check, Protectimus sends an Access-Challenge back to the network device with a prompt for the second factor. The user enters their TOTP code from the MFA app, hardware OTP token, or chatbot/SMS/email OTP.
Step 3 — Accept or reject. If the second factor validates, an Access-Accept is issued. If not, Access-Reject. The network device enforces the result.
One important technical note: the Access-Challenge flow requires the NAS device to support RADIUS challenge/response. Most modern VPN clients (Cisco AnyConnect, Fortinet SSL VPN, Palo Alto GlobalProtect) handle this natively. For devices that do not support RADIUS Access-Challenge, Protectimus supports Inline Mode. In this mode, users enter their password and OTP in a single field using a configurable separator (for example, password,otp). This approach allows MFA enforcement even on legacy systems that only support a single authentication exchange.
Supported MFA Methods for RADIUS
Different network access scenarios call for different second-factor methods. A VPN tunnel client has no browser UI. A corporate Wi-Fi 802.1X supplicant has even less. The table below maps methods to scenarios.
| Method | How it works | Best for | Notes |
|---|---|---|---|
| Authenticator app (TOTP) | 30-second rotating code from an authenticator app | VPN and other supported RADIUS-protected services | Works with virtually any RADIUS client; no internet required after enrollment |
| Hardware tokens (TOTP) | 30-second rotating code from a physical TOTP device | Air-gapped environments, users without smartphones | Supports Protectimus Two, Slim NFC, Flex, Shark, and OATH-compatible third-party tokens |
| SMS OTP | 6-digit code sent via SMS | VPN and other supported RADIUS-protected services | Requires mobile signal; works with Inline Mode |
| Email OTP | 6-digit code sent to email | VPN and other supported RADIUS-protected services | Suitable where SMS isn’t available |
| Chatbot OTP | OTP delivered through Telegram, Viber, or Facebook Messenger | VPN and other supported RADIUS-protected services | No SMS costs or mobile carrier dependency |
For VPN specifically: TOTP (via app or hardware token) and chatbot/SMS/email OTP work in both challenge/response mode and Inline Mode.
Supported RADIUS Clients & Network Equipment
Protectimus has documented integrations and has been tested with the following network equipment. The full RADIUS MFA integration guide includes step-by-step configuration for each.
Vendor | Product / Feature | Access Type |
|---|---|---|
Cisco | VPN | |
Cisco | Administrative access | |
Juniper | VPN | |
Fortinet | VPN | |
Palo Alto | VPN | |
SonicWall | VPN | |
Check Point | VPN | |
F5 | VPN / App proxy | |
Citrix | VPN / App proxy | |
Ubiquiti | Guest Wi-Fi | |
Array Networks | VPN |
This list covers the most common deployments. Any device that sends standard RFC 2865 RADIUS requests will work, even if it isn’t listed here.
Note: Some RADIUS-based deployments are not yet included in our documented integrations. Because Protectimus operates as a standards-based RADIUS proxy, additional RADIUS architectures — including deployments based on FreeRADIUS or Microsoft NPS — may also be compatible. If you are planning one of these deployments, please contact our team to discuss your specific environment.
RADIUS MFA for VPN
VPN is by far the most common RADIUS MFA deployment, and it’s also the most security-critical one. A compromised VPN session gives an attacker the same network position as a legitimate remote employee — with access to file shares, internal web apps, databases, and lateral movement paths.
How MFA works over VPN (without a browser)
When a user connects via Cisco AnyConnect or Fortinet’s SSL VPN client, the connection is initiated at the OS or client-app level. There’s no browser, no JavaScript, no redirect URI. The VPN client sends credentials directly to the NAS, which forwards them as a RADIUS Access-Request.
With challenge/response support enabled in the VPN client, the flow works exactly as described in the architecture section: the user sees a secondary prompt («Enter your OTP») in the VPN client UI after entering their password. Most modern VPN clients render this field correctly, and users find it intuitive.
For legacy VPN clients that do not support RADIUS Access-Challenge, Protectimus provides Inline Mode. Users enter their password and OTP in a single authentication field using a configured separator. This allows organizations to deploy MFA without replacing existing VPN infrastructure.
Ensure the VPN gateway can always reach the Protectimus RADIUS server (UDP 1812/1813 if accounting is used), regardless of the VPN routing configuration.
See the full RADIUS MFA integration guide and MFA for Cisco AnyConnect VPN for vendor-specific configuration steps.
RADIUS MFA for Wireless Network Access
While VPN is the most common RADIUS MFA deployment, organizations also use RADIUS to protect wireless network access. The exact authentication flow depends on the wireless infrastructure and authentication method in use.
Protectimus supports wireless access scenarios that integrate with RADIUS-based authentication, including guest Wi-Fi deployments such as the Ubiquiti UniFi Guest Portal. In these environments, users authenticate using a one-time password delivered via SMS, chatbot, email, or a TOTP generated by an authenticator app or hardware token, depending on the deployment.
For guest Wi-Fi environments, Protectimus can be deployed either with the Protectimus Cloud Service or the Protectimus On-Premise Platform. Authentication requests are validated through the Protectimus platform before network access is granted, while administrators retain centralized logging and user management capabilities.
When planning MFA for enterprise wireless networks, verify that your wireless infrastructure and authentication flow support the required RADIUS authentication method. Authentication capabilities may vary depending on the wireless controller, access gateway, or captive portal implementation.
Deployment Options
Cloud RADIUS MFA (SaaS)
The Protectimus RADIUS Server is installed inside your network and configured to communicate with the Protectimus Cloud Service. Your network devices send RADIUS authentication requests to the local Protectimus RADIUS Server, which validates the user’s primary credentials against your Active Directory or LDAP and verifies the second factor through the Protectimus Cloud Service. No on-premises MFA platform is required, making this deployment suitable for organizations that want fast deployment and minimal infrastructure.
On-Premises RADIUS MFA Server
The Protectimus RADIUS Server and Protectimus On-Premise Platform are installed on standard Windows Server or Linux hosts inside your network. The RADIUS Server validates primary credentials against Active Directory or LDAP and verifies the second factor using the local Protectimus Platform. All authentication requests remain within your infrastructure, making this deployment suitable for organizations with data residency requirements, air-gapped environments, or internal security policies that prohibit cloud authentication services.
High Availability Setup
In both deployment modes, Protectimus supports high-availability configurations. Organizations can deploy primary and secondary Protectimus RADIUS Server instances. Network devices can be configured with both server IPs using standard RADIUS failover (the secondary server is used if the primary doesn’t respond within the configured timeout period). Most enterprise firewalls, VPN gateways, and RADIUS clients support this natively.
In Cloud deployments, redundant Protectimus RADIUS Server instances connect to the Protectimus Cloud Service. In On-Premise deployments, high availability can be extended to the Protectimus Platform itself by deploying it as a cluster behind a customer-managed load balancer. Organizations can also deploy components across separate locations to further reduce the risk of service interruption
System Requirements & Integration
Component | Requirement |
|---|---|
Deployment options | Windows, Linux, Docker |
RADIUS ports | UDP 1812 (authentication), UDP 1813 (accounting) |
IP protocol | IPv4 and IPv6 supported |
Directory integration | Active Directory and LDAP directories |
Network devices | Any RFC 2865-compliant RADIUS client |
Java | Java is required for Windows installations. If Java is not already installed, the installer can install it automatically. Refer to current Protectimus documentation for supported versions. |
Firewall rules | UDP 1812 open between RADIUS clients and the Protectimus RADIUS Server; LDAP/LDAPS (389/636) access from the Protectimus RADIUS Server to Active Directory or LDAP, if used for primary authentication. |
Step-by-Step: How to Set Up RADIUS MFA in 5 Steps
Step 1 — Deploy the Protectimus RADIUS Server. Choose Cloud or On-Premise deployment. For Cloud, create an account at service.protectimus.com, activate API access, and install the Protectimus RADIUS Server inside your network. For On-Premise, download the installer package, run it on your target Windows or Linux server, and install both the Protectimus RADIUS Server and the Protectimus On-Premise Platform.
Step 2 — Configure your AD/LDAP connection. In the Protectimus RADIUS Server configuration file, add your domain controller address, bind account, search base, and authentication provider settings. Test the connection to confirm that the Protectimus RADIUS Server can communicate with your directory service.
Step 3 — Add your network device as a RADIUS client. In the Protectimus RADIUS Server configuration, register the IP address and shared secret for each NAS device, such as your VPN gateway, firewall, or other supported network device. This is the same shared secret you’ll configure on the device side.
Step 4 — Point the network device to Protectimus. On your Cisco ASA, Fortinet, Palo Alto, or other supported device, change the RADIUS server IP to the Protectimus RADIUS Server. Set the shared secret to match what you configured in Step 3 and configure UDP port 1812 for RADIUS authentication.
Step 5 — Enroll users and test. Enroll a pilot group of users—either by sending them a self-enrollment link or by bulk-importing via an AD group. Have them scan a QR code in their authenticator app or assign hardware tokens. Test the complete authentication flow using your RADIUS-protected service: enter credentials, complete the OTP challenge, and confirm that access is granted after a valid code.
For the full technical walkthrough with vendor-specific screenshots, see the full RADIUS MFA integration guide.
Compliance: How RADIUS MFA Satisfies Regulatory Requirements
NIST SP 800-63B (AAL2)
NIST’s digital identity guidelines define three Authenticator Assurance Levels. AAL2 requires two distinct authentication factors for access to sensitive systems. RADIUS MFA with TOTP or hardware tokens meets AAL2 requirements directly — the password is the memorized secret (something you know), and the TOTP code is generated by a bound authenticator (something you have).
PCI DSS v4.0 — Requirement 8.4
PCI DSS v4.0 Requirement 8.4.2 mandates MFA for all access into the cardholder data environment — for any user, regardless of whether they’re connecting remotely or from inside the network. Requirement 8.4.3 narrows in on remote access specifically: MFA is required for all remote network access to the CDE originating from outside the organization’s network, covering employees, contractors, and third-party vendors alike. RADIUS MFA helps organizations satisfy both requirements by enforcing MFA for VPN and other RADIUS-protected access to systems within the cardholder data environment.
HIPAA — Access Controls (45 CFR § 164.312)
HIPAA’s Technical Safeguard for access control requires covered entities to implement procedures that grant access to electronic PHI only to authorized persons. RADIUS MFA directly addresses this by adding a second verification step to VPN and Wi-Fi access — the two paths most commonly used for remote access to clinical systems.
NIS2 Directive (EU) — Article 21
NIS2 requires essential and important entities to implement multi-factor authentication or continuous authentication solutions for access to network and information systems. RADIUS MFA satisfies this requirement for remote access scenarios, which are explicitly called out in ENISA’s implementation guidance.
ISO/IEC 27001:2022 — Annex A 8.5
ISO 27001’s control on secure authentication explicitly recommends MFA for high-risk access scenarios, including remote access and privileged accounts. RADIUS MFA helps organizations implement this control for VPN and other RADIUS-protected services.
FAQ
Does Protectimus support RADIUS Access-Challenge for interactive OTP entry?
Yes. Protectimus uses RADIUS Access-Challenge natively for interactive OTP prompts. When the NAS device supports challenge/response (which most modern VPN clients do), users see a secondary input field for their OTP after entering their password. For devices that don’t support challenge/response, Inline Mode is available as a fallback.
Can I use Protectimus RADIUS MFA without replacing my existing RADIUS or NPS server?
Yes, and this is the most common deployment model. Protectimus operates as a RADIUS proxy upstream of your existing authentication server. Your NAS devices point to Protectimus; Protectimus handles MFA enforcement and then forwards the validated request onward. Your existing authentication policies, routing, and accounting configuration remain unchanged.
What RADIUS authentication port does Protectimus use?
Protectimus uses the standard RADIUS authentication port: UDP 1812. Accounting (if needed) uses UDP 1813. Both are configurable.
How does MFA work over VPN when there is no browser interface?
Two modes are supported. In challenge/response mode, the VPN client displays a secondary prompt after the password is accepted — the user types their OTP in this field. In Inline Mode, the user enters their password and OTP together in a single field using a configured separator. No browser is required in either case; the entire flow happens within the client’s native authentication interface.
Does Protectimus RADIUS support high availability and failover?
Yes. You can deploy multiple Protectimus RADIUS Server instances and configure your NAS devices with primary and secondary RADIUS targets. If the primary server doesn’t respond within the RADIUS timeout, the NAS retries against the secondary automatically. In On-Premise deployments, high availability can also be extended to the Protectimus Platform by deploying it as a cluster. Network devices automatically switch to the secondary server when the primary becomes unavailable, helping maintain authentication availability.
Can I integrate Protectimus RADIUS with Active Directory?
Yes, and this is the default configuration for most enterprise deployments. Protectimus connects to your AD via LDAP or LDAPS (port 389/636) and forwards password validation to the domain controller. Group-based policies are supported — you can require MFA for some AD groups and exempt others, or assign different MFA methods by group.
Start Securing Your Network Access Today
Every VPN endpoint, corporate Wi-Fi network, and RADIUS-protected service is a potential entry point. RADIUS MFA closes the credential-only gap without requiring changes to your existing network infrastructure.
- Deploy on-premises → Protectimus On-Prem MFA Platform
- Use the cloud service → Protectimus SaaS Setup Guide
- Read the technical guide → Full RADIUS MFA Integration Guide
- Hardware tokens for RADIUS MFA → Protectimus Tokens
- MFA for Active Directory → Agentless AD MFA Guide
- MFA for Windows Logon & RDP → Winlogon Component
