Study guide
13.3 Manage Network Access Controls
ISC2 Systems Security Certified Practitioner SSCP
Track your progress as you read
Finished sections get a check mark.
1 Introduction and Exam Overview
1.1 Current Exam Facts 1.2 Computerized Adaptive Testing, Scoring, and Retakes 1.3 Eligibility, Associate Pathway, Endorsement, and Maintenance
2 Ethics and Security Concepts
2.1 Comply with Codes of Ethics 2.2 Understand Security Concepts 2.3 Identify and Implement Security Controls
3 Functional Controls, Assets, and Change Management
3.1 Document and Maintain Functional Security Controls 3.2 Support and Implement the Asset Management Lifecycle 3.3 Support and Implement the Change Management Lifecycle
4 Security Awareness and Physical Security Operations
4.1 Support and Implement Security Awareness and Training 4.2 Collaborate with Physical Security Operations
5 Authentication Methods and Trust Architectures
5.1 Implement and Maintain Authentication Methods 5.2 Federated Access with OAuth2, SAML, and OpenID Connect 5.3 Understand and Support Internetwork Trust Architectures
6 Identity Lifecycle and Access Control Models
6.1 Support and Implement the Identity Management Lifecycle 6.2 Mandatory, Discretionary, and Role-Based Access Control 6.3 Rule-Based, Attribute-Based, and Privileged Access Management
7 Risk Management, Visibility, and Legal Concerns
7.1 Risk Management Concepts and Treatment 7.2 Risk Visibility, Reporting, and Threat Intelligence 7.3 Legal and Regulatory Concerns
8 Assessments, Monitoring, and Analysis
8.1 Security Assessments and Vulnerability Management 8.2 Operate and Monitor Security Platforms 8.3 Analyze Monitoring Results
9 Incident Response and Forensic Investigations
9.1 Incident Response: Preparation, Detection, Analysis, and Escalation 9.2 Containment, Eradication, Recovery, and Lessons Learned 9.3 Understand and Support Forensic Investigations
10 Business Continuity and Disaster Recovery
10.1 Business Continuity and Emergency Response 10.2 Disaster Recovery and Restoration Metrics 10.3 Backup, Redundancy, Testing, and Drills
11 Cryptography Foundations
11.1 Reasons and Requirements for Cryptography 11.2 Hashing, Salting, Symmetric, Asymmetric, and ECC 11.3 Digital Signatures, HMAC, Algorithm Strength, and Cryptanalysis
12 Secure Protocols and Public Key Infrastructure
12.1 Understand and Implement Secure Protocols 12.2 Understand Public Key Infrastructure
13 Networking Fundamentals, Attacks, and Access Controls
13.1 Understand and Apply Fundamental Concepts of Networking 13.2 Understand Network Attacks and Countermeasures 13.3 Manage Network Access Controls
14 Network Security Operations, Wireless, and IoT
14.1 Manage Network Security 14.2 Operate and Configure Network-Based Security Appliances and Services 14.3 Secure Wireless Communications 14.4 Secure and Monitor Internet of Things
15 Malware, Malicious Activity, and Endpoint Security
15.1 Identify and Analyze Malicious Code 15.2 Malicious Activity, Social Engineering, and Behavior Analytics 15.3 Implement and Operate Endpoint Device Security
16 Mobile, Cloud, and Virtual Environments
16.1 Administer and Manage Mobile Devices 16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility 16.3 Cloud Legal, Regulatory, and Third-Party Requirements 16.4 Operate and Maintain Secure Virtual Environments
13.3 Manage Network Access Controls
Key Takeaways Explain This Topic AI
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.
Last updated: August 2026
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 terminal on 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.