What is RADIUS? What is RADSEC? — MFA Protocol Guide

RADIUS (Remote Authentication Dial-In User Service) is the standard protocol for authenticating users who connect to VPNs, firewalls, and other network infrastructure. RADSEC extends RADIUS by wrapping it in TLS encryption, eliminating the security limitations of the original protocol. Mideye Server is a RADIUS server that speaks both protocols — adding multi-factor authentication to every RADIUS-capable device in your network.

What is RADIUS?

RADIUS is a client-server protocol defined in RFC 2865. Despite its age — the original specification dates to 1997 — RADIUS remains the dominant authentication protocol for network access because virtually every VPN concentrator, firewall, wireless controller, and network switch supports it.

In a RADIUS setup, three roles exist:

The user — a person trying to connect to a network resource.
The RADIUS client (NAS) — the VPN, firewall, or access point that receives the user’s credentials and forwards them.
The RADIUS server — the system that validates credentials and decides whether to allow or deny access.

When your VPN receives a login attempt, it doesn’t validate the credentials itself. Instead, it packages the username and password into a RADIUS Access-Request packet and sends it to the RADIUS server. The server checks the credentials — typically against LDAP, Active Directory, or a local database — and responds.

RADIUS packet types

Every RADIUS authentication involves a conversation between the client (your VPN/firewall) and the server (Mideye Server). Four packet types make up this conversation:

Packet type	Direction	Purpose
Access-Request	Client → Server	”Here are the user’s credentials — should I let them in?”
Access-Accept	Server → Client	”Credentials valid — grant access.”
Access-Reject	Server → Client	”Credentials invalid — deny access.”
Access-Challenge	Server → Client	”I need more information — ask the user for a second factor.”

The Access-Challenge packet is the key to multi-factor authentication over RADIUS. When Mideye Server receives an Access-Request with a valid password, it doesn’t immediately accept the login. Instead, it sends an Access-Challenge asking the user for an OTP (one-time password). The VPN prompts the user, and a second Access-Request carries the OTP back for validation.

This challenge-response mechanism is how RADIUS supports MFA without any protocol extensions — it’s built into the standard.

Why RADIUS is still the standard

RADIUS has lasted nearly three decades for practical reasons:

Universal support. Every major VPN, firewall, and network device speaks RADIUS. Cisco, Fortinet, Palo Alto, Check Point, Juniper, Microsoft — they all support it.
Simplicity. The protocol is straightforward: request, challenge, accept, or reject. No complex handshakes or session management.
Vendor neutrality. RADIUS is an open standard. You’re not locked into any vendor’s authentication ecosystem.
Extensibility. Vendor-Specific Attributes (VSAs) let manufacturers add custom data to RADIUS packets without breaking the standard.
Separation of concerns. Authentication logic lives on the RADIUS server, not on every VPN and firewall. Change your MFA policy once — every device follows it.

What is RADSEC?

RADSEC (RADIUS over TLS), defined in RFC 6614, solves the biggest weakness of traditional RADIUS: security.

Standard RADIUS packets travel over UDP and are protected only by a shared secret — a static password known to both the RADIUS client and server. The shared secret is used to hash the user’s password in transit, but the rest of the packet (including the username and RADIUS attributes) is sent in cleartext. If an attacker captures RADIUS traffic on your network, they can read usernames, session parameters, and potentially recover passwords through offline attacks against the shared secret.

RADSEC wraps the entire RADIUS conversation in a TLS tunnel — the same encryption technology that protects HTTPS web traffic. This provides:

Encryption. All RADIUS data is encrypted in transit, including usernames, attributes, and hashed passwords.
Certificate-based authentication. Instead of relying on a shared secret, both the RADIUS client and server authenticate each other using TLS certificates. This is stronger than a static password and easier to rotate.
Integrity protection. TLS guarantees that packets haven’t been tampered with in transit.
TCP reliability. RADSEC uses TCP instead of UDP, eliminating lost-packet issues that can cause authentication timeouts on unreliable networks.

When do you need RADSEC?

Traditional RADIUS over UDP is fine when the RADIUS client (VPN/firewall) and server are on the same trusted network — for example, in the same data center or connected by a dedicated link.

RADSEC becomes important when:

RADIUS traffic crosses untrusted networks. If your VPN is in a branch office and the RADIUS server is in headquarters, the traffic may traverse networks you don’t fully control.
Your compliance requirements mandate encryption. Frameworks like NIS2 and ISO 27001 expect authentication traffic to be protected. RADSEC provides the encryption they require.
You want certificate-based mutual authentication. TLS certificates are stronger than RADIUS shared secrets and integrate with your existing PKI infrastructure.
You’re consolidating RADIUS across cloud and on-premises. RADSEC’s use of TCP/TLS makes it easier to traverse firewalls and load balancers than UDP-based RADIUS.

How RADSEC works in Mideye Server

Mideye Server includes a built-in RADSEC listener powered by Netty, a high-performance asynchronous networking framework. When RADSEC is enabled:

The RADIUS client (VPN/firewall) establishes a TLS connection to Mideye Server on the RADSEC port (default: 2083).
Both sides authenticate using TLS certificates — mutual TLS (mTLS).
RADIUS packets flow inside the encrypted TLS tunnel, using the standard RADIUS packet format.
Mideye Server processes the packets exactly like traditional RADIUS — the same authentication types, the same policies, the same logs.

From the user’s perspective, nothing changes. From a security perspective, everything is encrypted.

RADSEC can run alongside traditional RADIUS — you don’t have to choose one or the other. Devices that support RADSEC connect over TLS; devices that don’t continue using UDP with shared secrets.

How Mideye Server uses RADIUS

Mideye Server is a full RADIUS authentication server that adds multi-factor authentication to the standard RADIUS flow. It supports:

PAP (Password Authentication Protocol) — The most common protocol for MFA over RADIUS. The user’s password is sent to the server (protected by the shared secret or TLS), allowing the server to validate it and initiate a second-factor challenge.
MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol v2) — Used by Microsoft environments (NPS, Windows VPN). Provides mutual authentication between client and server.
Challenge-response — For authentication types that require a second step (SMS OTP, Plus, Token, On-prem TOTP), Mideye Server uses the Access-Challenge mechanism to prompt the user for a one-time code.
Single-step authentication — For Touch (push notifications) and Concatenated tokens, the user doesn’t need to enter a second code. The server handles the second factor transparently.

RADIUS clients and shared secrets

Every device that sends RADIUS requests to Mideye Server must be registered as a RADIUS client with:

An IP address or subnet
A RADIUS shared secret (for UDP) or a TLS certificate (for RADSEC)
Optional: authentication type override, attribute assignments, and Mideye Shield policies

Shared secrets can be managed and rotated through the Mideye Server admin interface. For RADSEC, certificate management is built in — including support for PEM and PKCS formats.

Vendor-Specific Attributes (VSAs)

RADIUS supports extending packets with custom attributes defined by each vendor. Mideye Server lets you define VSA dictionaries so that RADIUS responses include the attributes your VPN or firewall expects — such as VLAN assignments, access group names, or session parameters.

RADIUS, RADSEC, and compliance

Using RADIUS with MFA directly supports compliance requirements across multiple frameworks:

Framework	RADIUS/RADSEC relevance
NIS2	MFA for network access; encrypted authentication traffic via RADSEC
ISO 27001	Access control (A.9); cryptographic controls (A.10) for auth traffic
NIST SP 800-63	AAL2 requires MFA; RADSEC supports encrypted transport requirements
PCI DSS	MFA for remote access to cardholder data environments
GDPR	Appropriate technical measures to protect access to personal data

For a detailed compliance mapping, see Compliance & Regulatory Frameworks.

Next steps

Authentication Flows — See RADIUS in action with step-by-step sequences
Authentication Types — All 11 MFA methods available over RADIUS
System Architecture — How Mideye Server fits into your network
Data Residency — Where RADIUS data stays and what leaves your network