13.3 Manage Network Access Controls
Key Takeaways
- IEEE 802.1X uses a supplicant (endpoint), an authenticator (switch or access point), and an authentication server (almost always RADIUS) with Extensible Authentication Protocol; the port stays unauthorized until EAP succeeds.
- RADIUS uses UDP 1812/1813, encrypts mainly the password, and is the usual backend for network access (802.1X, VPN, Wi-Fi). TACACS+ uses TCP 49, encrypts the full payload, and separates authentication, authorization, and accounting — the usual tool for network-device administration.
- Do not use RADIUS as a substitute for TACACS+ command authorization on switches; a successful RADIUS login still leaves the admin at privilege 15 with no per-command log.
- Remote access on the outline is thin client, virtual private network (VPN), and virtual desktop infrastructure (VDI). Thin client and VDI keep the desktop in the datacenter; the endpoint is a display.
- Split-tunnel VPN encrypts only selected prefixes. Payroll or other sensitive sessions that are not in the selector list leave the coffee-shop Wi-Fi in the clear — a 6.3 configuration failure, not a 'performance feature' you ignore.
Manage network access controls
Knowledge Area 6.3 of the ISC2 SSCP outline (effective 1 October 2025) is manage network access controls. The outline names two piles: network access controls, standards and protocols — Institute of Electrical and Electronics Engineers (IEEE) 802.1X, Remote Authentication Dial-In User Service (RADIUS), and Terminal Access Controller Access-Control System Plus (TACACS+) — and remote access operation and configuration — thin client, virtual private network (VPN), and virtual desktop infrastructure (VDI). Domain 2 already taught you authentication methods and federated access. This knowledge area is the network enforcement point: the switch port, the wireless authenticator, the VPN concentrator, and the jump path into a desktop that never left the datacenter.
IEEE 802.1X
IEEE 802.1X is port-based network access control. Three roles, always:
| Role | What it is | What it does |
|---|---|---|
| Supplicant | The endpoint (laptop, phone, sometimes a printer with 802.1X support) | Speaks Extensible Authentication Protocol (EAP) over LAN (EAPoL) |
| Authenticator | The switch port or wireless access point | Relays EAP; keeps the port unauthorized until the server says yes; then applies a VLAN, ACL, or downloadable policy |
| Authentication server | Almost always RADIUS | Validates identity (and often machine certificate or posture) and returns accept/reject plus attributes |
Until EAP succeeds, the port should not be a general forwarding seat. Exceptions you will actually operate: a guest VLAN after failure or timeout; MAC Authentication Bypass (MAB) for printers and badges that cannot speak EAP — treat MAB as a weak stand-in, not as "802.1X is done." Monitor mode (authenticate but do not enforce) is a rollout step; leaving production in monitor mode is how the contractor jack in Knowledge Area 6.2 stays open.
EAP methods are Domain 6.6 territory when they wrap Wi-Fi (EAP-TLS, PEAP, EAP-TTLS). For 6.3, remember the topology: the authenticator does not need the user password; it forwards EAP to RADIUS. A switch that is configured with a local username for 802.1X instead of RADIUS does not scale and is not the outline's model.
Scenario. A contractor plugs into a conference-room jack. 802.1X is enforced. The port stays unauthorized — no DHCP, no ARP for the gateway, no path to payroll. Without 802.1X, that jack is how ARP spoofing from 6.2 gets a seat. The SSCP answer is not "the firewall will catch it." The firewall never sees a frame that never left the VLAN.
RADIUS versus TACACS+
Both protocols do authentication, authorization, and accounting (AAA). They are not interchangeable. The outline lists both because one is how users and machines join the network and the other is how administrators join the devices.
| RADIUS | TACACS+ | |
|---|---|---|
| Transport and port | UDP 1812 (authentication), UDP 1813 (accounting); legacy 1645/1646 | TCP 49 |
| Encryption | Encrypts the password (authenticator hash); other attributes often in the clear | Encrypts the full payload |
| AAA coupling | Authentication and authorization are typically combined in Access-Accept | Authentication, authorization, and accounting are separate — you can authorize each command |
| Primary SSCP use | Network access: 802.1X, Wi-Fi, VPN concentrators, some NAC posture | Device administration: routers, switches, firewalls — privilege levels and command sets |
| Failure mode you will see | Shared secret mismatch, UDP loss, attributes ignored so the guest VLAN is not applied | TCP session down so admins fall back to a local emergency account; missing command authorization so everyone is privilege 15 |
Scenario — TACACS+ for switch admin. You are hardening the campus core. Operators currently SSH to switches with a shared local admin account. That fails accountability (Domain 1) and least privilege. Stand up TACACS+ against the identity store: each engineer authenticates as themselves, authorization permits show for the help desk and configure only for network engineering, and accounting logs every command. RADIUS can authenticate the SSH login, but typical RADIUS-to-switch integrations do not give you IOS/NX-OS per-command authorization. If the stem asks who may run clear ip route * at 02:00, the protocol is TACACS+.
Do not invent a third protocol as "the modern replacement" on this exam. Diameter exists in mobile cores; the SSCP outline's pair is RADIUS and TACACS+. Kerberos is an authentication protocol for domains, not the 802.1X authenticator backend. LDAP is a directory; RADIUS and TACACS+ query a directory, they are not the directory.
Remote access: thin client, VPN, and VDI
The outline's remote-access examples are three different architectures. The exam asks which traffic actually stays under your control.
| Pattern | Where the OS and data live | What the remote device is | Typical protocol |
|---|---|---|---|
| VPN | On the endpoint, plus whatever the tunnel reaches | A full laptop on an untrusted network | IPsec (UDP 500/4500, ESP) or a TLS VPN on 443 |
| Thin client | In the datacenter (terminal server / virtual apps) | A display and input device with a locked-down OS | Display protocol (RDP, Independent Computing Architecture, PCoIP) |
| Virtual desktop infrastructure (VDI) | A desktop VM in the datacenter | A window onto that VM (can be a thin client, a browser, or a fat laptop running only the VDI client) | Same display family; the disk you care about is the VM's |
Thin client and VDI shrink the endpoint's data. A stolen thin client in a taxi does not contain the payroll database; a stolen laptop with a cached Outlook OST might. That is why clinics and call centers still buy thin clients. VDI is the same idea with a per-user desktop VM: patch the gold image, keep personally identifiable information (PII) off the laptop, and still enforce 802.1X or VPN to reach the broker if the user is off-site.
VPN extends the network to a device you do not physically control. Full-tunnel VPN sends all of the laptop's traffic through the concentrator — simpler policy, heavier concentrator, the coffee shop cannot see payroll HTTPS. Split-tunnel VPN installs a selector list: only named prefixes (or named applications, on modern clients) go through the tunnel; everything else uses the local internet.
Split-tunnel VPN risk
Split-tunnel is a performance and SaaS-breakout choice that becomes a confidentiality failure when the selector list is wrong.
Scenario — split-tunnel VPN. A payroll clerk works from a cafe. The client split-tunnels: 10.0.0.0/8 goes through IPsec to headquarters; the default route stays on cafe Wi-Fi. Payroll moved last quarter to https://payroll.saas-example.com, which is not in 10.0.0.0/8. The clerk still "has the VPN connected" — the icon is green — and the payroll session never enters IPsec. A cafe on-path attacker (6.2) sees the HTTPS handshake to the SaaS name; if the clerk ignores a certificate warning, the attacker sees the rest. The SSCP configuration fix is one of: put the payroll prefixes/domains in the encrypted selector; switch the profile to full-tunnel; or stop putting payroll on the laptop at all and use VDI or a thin client so the session stays in the datacenter and the cafe only sees a display protocol you already wrap in TLS or IPsec.
SD-WAN local breakout (6.1) is the same decision with a branch box instead of a laptop: application-aware split. The risk sentence is identical — if payroll is classified as "general web," it leaves the encrypted overlay.
Other remote-access operations you will be asked to name:
- Always-on VPN with a machine certificate so the laptop is tunneled before the user logs on — useful for management, dangerous if the tunnel is split and you assumed it was full.
- Jump hosts / bastions in front of RDP (port 3389) and SSH (port 22) so those ports are not on the internet. Knowledge Area 6.1 already told you 3389 on the public internet is a finding; 6.3 is how remote staff still work: VPN or VDI then RDP to the jump host, not RDP to the jump host from the cafe.
- Posture / NAC on the VPN (same family as 802.1X): no disk encryption, no agent, no patch level → quarantine profile, not full campus routes.
How 6.3 sits next to 6.1 and 6.2
| You already know from | 6.3 uses it to |
|---|---|
| Ports 1812 and 49, UDP versus TCP (6.1) | Tell RADIUS from TACACS+ in a scanner report or a firewall rule |
| Data-link enforcement, star topology, the access switch as choke point (6.1) | Place 802.1X on the authenticator, not on a core ACL that never sees the jack |
| ARP spoofing and on-path MITM (6.2) | Treat an open jack as the root cause; 802.1X is the countermeasure that is also a 6.3 configuration |
| CDN / firewall / IDPS (6.2) | Those are not substitutes for 802.1X on the access port or for TACACS+ on the switch CLI |
Exam traps in 6.3:
- Using RADIUS on UDP 1812 as "the" AAA for
configure terminalon a switch. - Claiming TACACS+ uses UDP or encrypts only the password.
- Treating thin client and split-tunnel VPN as equivalent because both are "remote access."
- Leaving 802.1X in monitor mode and calling NAC done.
- Exposing RDP/3389 or SSH/22 to the internet instead of VPN or VDI in front of a jump host.
When you sit the item, ask: is this a port joining the LAN (802.1X + RADIUS), an engineer joining a device (TACACS+), or a human joining from an untrusted network (VPN / thin client / VDI)? Then ask what traffic is actually inside the tunnel.
Section takeaways
Enforce 802.1X with a RADIUS backend so unauthorized endpoints never get a forwarding seat. Use TACACS+ over TCP 49, with full-payload encryption and separate authorization, for switch and firewall administration. Keep remote desktops in the datacenter with thin clients or VDI when the endpoint is hostile; if you use a VPN, know whether the tunnel is full or split, and do not let payroll ride the cafe default route.
A contractor plugs a laptop into a conference-room jack. The security administrator wants the port to stay unauthorized until the laptop proves an identity. Which standard and roles implement that network access control?
Network engineering wants AAA so each switch administrator authenticates as themselves and only some operators may run configuration commands, with every command logged. Which protocol matches that requirement on the SSCP outline?
A payroll clerk works from a cafe on a laptop whose virtual private network icon is green. The client is split-tunnel: only 10.0.0.0/8 is encrypted. Payroll is now a software-as-a-service site on the public internet. What is the Knowledge Area 6.3 risk, and what remote-access design actually contains it?