AAA — the three functions RADIUS provides
RADIUS is described as an AAA protocol. Before diving into the mechanics, it helps to understand what each A stands for — these are tested individually on both Network+ and Security+:
How RADIUS works
RADIUS introduces a three-party model: the supplicant (the user or device trying to connect), the NAS/authenticator (the network device — VPN gateway, wireless AP, switch), and the RADIUS server (the central authority that makes the access decision).
Supplicant NAS / Authenticator RADIUS Server (User / Device) (VPN gateway / AP / Switch) (Central auth) │ │ │ │──── Connect request ──▶│ │ │ │──── Access-Request ───▶│ │ │ (credentials, │ │ │ NAS IP, port) │ │ │ │ Checks credentials │ │ │ against directory │ │◀─── Access-Accept ─────│ │ │ (+ VLAN, policies) │ │◀─── Network access ────│ │ │ │ │ │ │──── Accounting-Start ──▶│ (session begins) │ │ │ │──── Disconnect ────────▶│ │ │ │──── Accounting-Stop ───▶│ (session logged)
The key insight is that the NAS never makes the access decision itself — it just proxies the credentials to the RADIUS server. The RADIUS server checks those credentials against a backend directory (Active Directory via LDAP, a local user database, or another source) and returns Access-Accept or Access-Reject. The NAS enforces whatever the RADIUS server decides.
UDP 1812 — RADIUS authentication and authorisation (Access-Request, Access-Accept, Access-Reject).
UDP 1813 — RADIUS accounting (session start, stop, and interim updates).
Older implementations used UDP 1645 and 1646 respectively — the exam may reference these legacy ports. Know both pairs. RADIUS uses UDP (not TCP) because it handles its own retransmission logic.
RADIUS vs TACACS+
RADIUS and TACACS+ are both AAA protocols but serve different primary use cases. This comparison is one of the most commonly tested distinctions on Network+ and Security+:
| Feature | RADIUS | TACACS+ |
|---|---|---|
| Developed by | Open standard (RFC 2865) | Cisco proprietary |
| Transport | UDP 1812 / 1813 | TCP 49 |
| Encryption | Password only — rest of packet unencrypted | Full packet encryption — entire body encrypted |
| AAA separation | Authentication and authorisation combined | Authentication, authorisation, and accounting fully separated |
| Primary use | Network access — VPN, Wi-Fi, 802.1X | Device administration — router/switch command authorisation |
| Multiprotocol | Originally for dial-up, now broadly used | Excellent support for multiple protocols and shell access |
| Vendor support | Universal — all vendors support RADIUS | Primarily Cisco environments |
RADIUS = network access control (who can connect to the network — VPN users, Wi-Fi clients). UDP. Encrypts password only.
TACACS+ = device administration (which commands can an admin run on a router or switch). TCP 49. Fully encrypted. Cisco environments.
Scenario: "An administrator wants to control which commands a network engineer can run on Cisco routers." → TACACS+. "A company needs to authenticate remote VPN users against Active Directory." → RADIUS.
802.1X — RADIUS for wired and wireless access control
802.1X is the IEEE standard for port-based network access control. It uses RADIUS as its backend authentication server. When a device plugs into a switch port or connects to a Wi-Fi network, 802.1X holds them in an unauthenticated state — a kind of quarantine — until RADIUS verifies their identity.
Without 802.1X, anyone who physically plugs into a switch port gets network access. With 802.1X, every device must authenticate before any traffic is allowed — unauthenticated devices are placed in a quarantine VLAN or blocked entirely.
This is the standard defence against rogue device attacks — an attacker plugging a laptop into an empty switch port and accessing the internal network. 802.1X prevents this at the port level.
The exam may describe 802.1X as "port-based NAC (Network Access Control)" — this is the same thing.
EAP methods — what the exam tests
| EAP Method | How it authenticates | Security level |
|---|---|---|
| EAP-TLS | Mutual certificate authentication — both client and server present certificates. Requires PKI infrastructure. | Strongest — mutual auth, no password |
| PEAP | Creates a TLS tunnel using the server's certificate, then authenticates the client with a password inside the tunnel. No client certificate needed. | Strong — password protected by TLS tunnel |
| EAP-TTLS | Similar to PEAP — TLS tunnel, then various authentication methods inside. More flexible than PEAP. | Strong — TLS-protected inner auth |
| EAP-MD5 | Password hashed with MD5. No server authentication — vulnerable to MITM attacks. | Weak — MD5 is broken, no server auth |
If the exam asks which EAP method provides the highest security, the answer is EAP-TLS — it uses certificates on both sides (mutual authentication), eliminates passwords entirely, and provides the strongest protection against MITM attacks.
The tradeoff is infrastructure cost — you need a PKI to issue client certificates. PEAP is the practical middle ground: strong security without requiring client certificates.
RADIUS in enterprise deployments
In production environments, RADIUS doesn't work in isolation. It connects to backend systems to check credentials and retrieve authorisation policies:
User connects to Wi-Fi / VPN / switch port │ ▼ Authenticator (AP / VPN gateway / switch) │ EAP over RADIUS (UDP 1812) ▼ RADIUS Server (e.g. Microsoft NPS, FreeRADIUS, Cisco ISE) │ ├──▶ Active Directory / LDAP (verify credentials) │ ├──▶ Certificate Authority (validate client certs for EAP-TLS) │ └──▶ Policy engine (assign VLAN, ACL, time restrictions) │ └─▶ Access-Accept (+ VLAN tag, ACL) → user gets network access Access-Reject → user blocked
Common RADIUS server implementations include Microsoft NPS (Network Policy Server — built into Windows Server), FreeRADIUS (open source, widely used on Linux), and Cisco ISE (Identity Services Engine — enterprise NAC platform).
Exam scenarios
Studying for Network+ or Security+?
The study guides, practice exams, and free resources worth your time.