Network Access Control (NAC)

Network Access Control (NAC) is the technological answer to a simple question: "Who and what is allowed on our network?" Without NAC, any device—whether a BYOD smartphone, an unsecured laptop, or a compromised printer—can access all network resources. NAC changes that: verify first, then grant access.

The Problem Without NAC

Scenario 1: BYOD

Employee brings personal smartphone → enters Wi-Fi password → immediate access to file servers, printers, internal web applications, and other devices on the network.

• Verification: none
• Isolation: not possible
• Identification: none (which device is this?)

Scenario 2: Guest Visitors

A supplier connects a laptop to an open network port in the conference room.

• Access to: entire internal network
• Lateral movement: possible

Scenario 3: Compromised Device

Employee laptop with 6-month-old patches and inactive antivirus.

• Device status: unknown
• Risk: uncontrolled

NAC solution for all three

• Scenario 1: BYOD VLAN with restricted Internet-only access
• Scenario 2: Guest VLAN, no access to internal resources
• Scenario 3: Quarantine VLAN until patches + antivirus are up to date

802.1X - The Standard Behind NAC

IEEE 802.1X is the foundation for wired and Wi-Fi NAC.

Three Roles

• Supplicant: End device (Windows/macOS/Linux – with 802.1X client)
• Authenticator: Switch or Wi-Fi access point
• Auth Server: RADIUS server (FreeRADIUS, Microsoft NPS, Cisco ISE)

Process

1. Device connects to switch/AP
2. Switch blocks ALL traffic (except EAPOL protocol)
3. Switch requests identity (EAP request)
4. Device responds: certificate or username/password (EAP response)
5. Switch forwards to RADIUS server
6. RADIUS checks: known device? Valid certificate?
7. If OK: Switch opens port → VLAN assignment
8. If fail: Port remains blocked OR quarantine VLAN

Authentication Methods

Method	Description	Security
EAP-TLS	Device certificate	Most secure method; requires PKI; phishing-proof, no password
PEAP-MSCHAPv2	User + password	Easier to set up; drawback: passwords can be cracked if certificate validation is missing
EAP-TTLS	Tunnel + various inner authentication methods	Flexible

Modern NAC Architecture

1. RADIUS Server / Policy Engine

• Microsoft NPS (free in Windows Server)
• Cisco ISE (Enterprise, complex but powerful)
• Aruba ClearPass
• PacketFence (Open Source)
• FreeRADIUS (open source, very flexible)

2. Endpoint Posture Assessment

Device logs in → NAC checks:

• Operating system version (Windows 11 up to date?)
• Patch status (when was the last Windows Update?)
• Is antivirus installed and up to date?
• Is the firewall active?
• Is disk encryption active (BitLocker)?
• Is the device in Active Directory?

Only if ALL checks pass: Production VLAN. If any fail: Quarantine VLAN (only patch server accessible).

3. VLAN Segmentation (Result of the NAC Policy)

VLAN	Purpose	Access
VLAN 10 (Corporate)	Domain members with valid certificate	Full access
VLAN 20 (BYOD)	Known personal devices	Internet + Cloud only
VLAN 30 (Guest)	Guests	Internet only, no internal access
VLAN 40 (Quarantine)	Non-compliant devices	Only patch server accessible
VLAN 50 (IoT)	Printers, cameras	Isolated from PCs
VLAN 99 (Blocked)	Unknown devices	No access

4. Integration with Active Directory / Entra ID

• Combine device + user authentication
• "Known device AND authorized user" = access
• Department-based VLAN: Finance → Finance VLAN

NAC for Wi-Fi: Especially important

Wi-Fi without NAC

• Anyone in the building can connect (if they know the PSK)
• PSK is never changed → all former employees still have access
• Guests can see all other Wi-Fi devices on the same subnet

Wi-Fi with 802.1X (WPA3-Enterprise)

• Each device requires its own certificate
• Certificate revoked = immediate exclusion (without changing the PSK!)
• Each client is isolated (Protected Management Frames)
• Guest SSID in a separate VLAN, via captive portal

Captive Portal for Guests

• Guest Wi-Fi: password-free OR simple
• Captive portal: "Please enter name + email"
• Confirm terms of service (legal protection)
• Time-limited access (e.g., 8 hours)
• Log: who was on the network and when (compliance!)
• No connection to internal resources allowed

Implementation Roadmap

Phase 1 (Weeks 1–4): Establish visibility

• Asset Discovery: which devices are on the network? (passive with NAC solution)
• Create inventory: known vs. unknown devices
• Design VLAN concept (Corporate/BYOD/Guest/IoT/Quarantine)
• Set up RADIUS server (Microsoft NPS or FreeRADIUS)

Phase 2 (Weeks 5–8): PKI and Certificates

• Set up internal PKI (Windows CA or HashiCorp Vault PKI)
• Roll out device certificates via Intune/SCCM/GPO
• Configure 802.1X on switches/APs (monitor mode first!)
• Test group: Put 10–20 pilot devices into 802.1X operation

Phase 3 (Weeks 9–12): Rollout and Policies

• Rollout to all managed devices
• Enable posture assessment (patch status, AV)
• Define BYOD policy: which personal devices are allowed?
• Set up guest Wi-Fi with captive portal
• Set up monitoring and alerting

> Important: Monitor mode before enforce mode! First, have NAC only log (no blocking). After 2–4 weeks: Activate enforce mode. Avoids production downtime due to configuration errors.

NAC vs. Zero Trust Network Access (ZTNA)

Feature	NAC	ZTNA (Zero Trust)
Approach	Perimeter-based (network boundary)	Application-based: Access to individual applications
Trust	Device on the network = access to VLANs	Every access is verified (Never Trust, Always Verify)
Architecture	Traditional enterprise architecture	Cloud-native, location-independent
Strengths	Internal networks, on-premises	Remote work, cloud apps
Weaknesses	Lateral movement possible after initial access	Higher implementation costs

Recommendation: Combine NAC + ZTNA

• NAC for internal network segmentation
• ZTNA for remote access instead of traditional VPN
• Result: Defense-in-depth