Network Access Control (NAC): 802.1X, RADIUS and Zero Trust

Every device that connects to the corporate network is a potential entry point for attackers. An unmanaged laptop, a personal smartphone, an IoT device - all can introduce malicious code or serve as a foothold for lateral movement. Network Access Control (NAC) prevents unmanaged devices from entering the corporate network by verifying the following before granting access: Who is the device? Does it belong to us? Is it up to date? Is antivirus active?

802.1X: Port-based access control

IEEE 802.1X, the foundation of NAC:

Roles:
  Supplicant:     Device requesting access (Windows, Linux, iPhone)
  Authenticator:  Network device (switch port, Wi-Fi access point)
  Auth server:    RADIUS server (verifies identity)

NAC process (802.1X):

  Device connects to switch port:
  ┌──────────┐  EAPOL start   ┌──────────┐  RADIUS   ┌──────────┐
  │  Client  │ ─────────────> │  Switch  │ ─────────> │   ISE    │
  │(Supplicant)│ <── EAP Req ── │(Authenticator)│ <── Policy ── │(Policy)  │
  │          │ ── EAP Resp ─> │          │           │  Server  │
  │          │ <── Success ── │          │           │          │
  └──────────┘                └──────────┘           └──────────┘

  Process:
  1. Device connects to switch port
  2. Switch: Port locked (only 802.1X traffic allowed)
  3. Switch sends EAP Request/Identity to device
  4. Device sends EAP Response/Identity (username or certificate)
  5. Switch forwards to RADIUS (RADIUS Access Request)
  6. RADIUS verifies identity:
     → Success: RADIUS Access Accept → Switch opens port → VLAN assigned
     → Error: RADIUS Access Reject → Switch keeps port blocked

  Result:
  → Auth OK + Posture OK: Normal VLAN (productive)
  → Auth OK + Posture Fail: Quarantine VLAN (update server only)
  → Auth Fail: No access or Guest VLAN
  → Unknown device: MAB (MAC Authentication Bypass) → Guest VLAN

EAP methods (important!):

  EAP-TLS:
  → Mutual certificate authentication (client + server)
  → Strongest method! (no password attacks possible)
  → Prerequisite: PKI (CA + client certificates)
  → Use: Corporate devices (Intune/Jamf deployed certs)

  PEAP-MSCHAPv2:
  → Server certificate + username/password (AD credentials)
  → Easier to deploy than EAP-TLS
  → Weaker: Password attacks possible (if server certificate is not validated!)
  → IMPORTANT: Supplicant must validate server certificate!
             (Otherwise: Man-in-the-middle attack possible!)

  PEAP-EAP-TLS:
  → PEAP tunnel + EAP-TLS inside → very strong, very complex

  EAP-TTLS:
  → Similar to PEAP, more identity protection

RADIUS Server Configuration

FreeRADIUS (Open Source):

# Installation on Ubuntu:
apt install freeradius freeradius-utils

# /etc/freeradius/3.0/clients.conf - Register switches/APs:
client switch-floor1 {
    ipaddr          = 192.168.1.10
    secret          = "StrongRADIUSSecret123!"
    nastype         = cisco
    shortname       = sw-floor1
}

client wlan-ap-01 {
    ipaddr          = 192.168.1.20
    secret          = "AnotherSecureSecret!"
    nastype         = cisco_aironet
}

# /etc/freeradius/3.0/mods-available/ldap - AD integration:
ldap {
    server          = "ldap://dc01.company.local"
    identity        = "CN=radius-svc,OU=ServiceAccounts,DC=company,DC=local"
    password        = "ServiceAccountPassword"
    base_dn         = "DC=company,DC=local"
    user {
        base_dn     = "${..base_dn}"
        filter      = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"
    }
    group {
        base_dn     = "${..base_dn}"
        filter      = "(objectClass=groupOfNames)"
        membership_attribute = "memberOf"
    }
}

# VLAN assignment based on AD group:
if (LDAP-Group == "CN=Corp-Network,OU=Groups,DC=company,DC=local") {
    reply:Tunnel-Type := VLAN
    reply:Tunnel-Medium-Type := IEEE-802
    reply:Tunnel-Private-Group-Id := "10"    # VLAN 10 = Corporate
}
elsif (LDAP-Group == "CN=Guest-Network,OU=Groups,DC=company,DC=local") {
    reply:Tunnel-Private-Group-Id := "99"    # VLAN 99 = Guest
}
else {
    reply:Tunnel-Private-Group-Id := "998"   # VLAN 998 = Quarantine
}

Microsoft NPS (Network Policy Server):
# Integrated into Windows Server (not a separate product):
# Server Manager → Add Roles → Network Policy and Access Services → NPS

# NPS policy for 802.1X:
# Connection Request Policy:
#   → Type: 802.1X (Wired/Wireless)
#   → Auth-Method: PEAP-MSCHAPv2 or EAP-TLS

# Network Policy:
#   → Condition: Windows Groups = "CORP\Domain Computers"
#   → Permission: Grant Access
#   → Settings: VLAN attributes (Tunnel Type, Tunnel Medium Type, VLAN ID)

Supplicant Configuration

Windows 802.1X Configuration via GPO:

# Group Policy: Computer → Windows Settings → Security Settings →
#               Wired Network (IEEE 802.3) Policies

# Linux wpa_supplicant (EAP-TLS):
# /etc/wpa_supplicant/wpa_supplicant.conf:
ctrl_interface=/run/wpa_supplicant
network={
    ssid="CORP-WLAN"
    scan_ssid=1
    key_mgmt=WPA-EAP
    eap=TLS
    identity="host/laptop01.company.local"
    ca_cert="/etc/ssl/certs/company-ca.crt"
    client_cert="/etc/ssl/certs/laptop01.crt"
    private_key="/etc/ssl/private/laptop01.key"
}

# Intune: EAP-TLS Wi-Fi Profile (iOS/Android/Windows):
# Device Configuration → Profiles → Wi-Fi → Enterprise
# EAP Type: TLS
# Certificate server names: radius.company.local
# Root certificate: Company Internal CA
# Client certificate: SCEP/PKCS cert from Intune

MAC Address Bypass for Legacy Devices

MAC Authentication Bypass (MAB) for IoT/Printers:

The Problem:
  → Printers, IP phones, IoT sensors: do not support 802.1X
  → Still need to access the network (but in a controlled manner!)

MAB Solution:
  → Switch sends device’s MAC address as a RADIUS request
  → RADIUS compares MAC with whitelist
  → If match: Access Accept + VLAN assignment

  # RADIUS MAB Policy (FreeRADIUS):
  # MAC Whitelist (format: XX-XX-XX-XX-XX-XX in lowercase):
  aa-bb-cc-dd-ee-ff Cleartext-Password := "aa-bb-cc-dd-ee-ff"
      Tunnel-Type = VLAN,
      Tunnel-Medium-Type = IEEE-802,
      Tunnel-Private-Group-Id = "20"   # VLAN 20 = Printer VLAN

Security limitations of MAB:
  Warning: MAC addresses are easy to spoof!
  Warning: An attacker can use any MAC address (MAC spoofing)
  → Use MAB only for low-trust devices + dedicated security VLAN
  → Perform posture assessment additionally (if possible)

Posture Assessment - Checking Device Status

What NAC can check on the device:

Posture checks (examples, Cisco ISE):

1. Operating system compliance:
   □ Windows version: min. Windows 10 22H2?
   □ macOS version: min. 14.x (Sonoma)?
   → Older versions → Quarantine → Update page

2. Patch level:
   □ Windows Update: all critical patches installed?
   □ Check WSUS/SCCM status or WMI directly
   → Not up to date: Quarantine + Update server accessible

3. Antivirus/EDR:
   □ Which AV solution? Version? Definitions up to date?
   □ Defender enabled? Real-time protection on?
   □ Compliant EDR product installed?
   → No AV/EDR: Quarantine

4. Disk Encryption:
   □ BitLocker (Windows): active? Escrowed?
   □ FileVault (macOS): active?
   → Not encrypted: Quarantine

5. Firewall:
   □ Windows Firewall enabled?
   □ All profiles (Domain/Private/Public)?

6. Domain Membership:
   □ Device in AD domain? → Managed Device
   □ AAD Join (Entra ID)? → Cloud-Managed
   → Not in domain: BYOD treatment

7. Software Inventory:
   □ Unauthorized software installed? (Torrent, remote tools?)
   → Non-compliant software: Warning or quarantine

Agent-based vs. Agentless:

Agent-based:
  → NAC agent installed on device
  → Deep scanning possible (all checks listed above)
  → Issue: Agent management, updates, BYOD does not accept an agent

Agentless:
  → No software on device
  → Checks: MAB (MAC address), DHCP fingerprint, mDNS
  → Weaker checks (device type detected, not patch level)
  → For printers, cameras, IoT devices (no agent possible!)
  → For BYOD: limited control

Posture Workflow:
  1. Device connects → 802.1X authentication successful
  2. NAC detects client agent (or agent checks itself)
  3. Agent checks posture requirements
  4. Result:
     → Compliant: Full Access VLAN
     → Non-Compliant: Quarantine VLAN
     → Unknown: Limited access (for initial registration)

VLAN-based segmentation

NAC VLANs and zone model:

VLAN structure (typical):
  VLAN 10 - Corporate:         Managed, compliant Windows/macOS, domain-joined
  VLAN 20 - BYOD/Mobile:       Personal device, MDM enrollment, restricted
  VLAN 30 - Guest:              No corporate access, Internet only
  VLAN 40 - Quarantine:        Non-compliant, remediation server only
  VLAN 50 - IoT:               Printers, cameras, sensors, isolated
  VLAN 60 - VoIP:              IP phones, QoS prioritized
  VLAN 70 - Server:            Production servers, restricted access
  VLAN 98 - Management:        Network admins, network devices
  VLAN 998 - Quarantine:       Non-compliant, remediation

VLAN assignment via NAC:
  802.1X Authentication + Posture OK → Corporate VLAN 10
  MDM Enrollment + BYOD Policy → BYOD VLAN 20
  No Authentication / Unknown Device → Guest VLAN 30
  Posture Fail (AV missing) → Quarantine VLAN 40
  MAC of known printer (MAB) → IoT VLAN 50

Quarantine VLAN Design:
  → Allowed: DHCP, DNS, HTTP/HTTPS (internal remediation servers only)
  → Blocked: all other hosts on the network!
  → Remediation page: explains problem + solution
  → After remediation: Posture reassessment + correct VLAN

Guest networks:
  → Completely isolated from internal resources
  → Internet access: restricted (no P2P, bandwidth limit)
  → Captive portal: Terms of Service acceptance, time limit
  → Wi-Fi SSID: "Guest" (separate from corporate SSID)
  → No VPN tunnels into the corporate network from the guest VLAN!

BYOD Integration and Mobile

BYOD (Bring Your Own Device) with NAC:

Challenges:
  → Personal devices do not support a full NAC agent
  → GDPR: Employers cannot inspect personal data on personal devices
  → Compliance: How to ensure compliance without full control?

BYOD-NAC Strategies:

Strategy 1 - MDM Enrollment (Hybrid):
  → Device must be enrolled in MDM (Intune, Jamf)
  → MDM profile: device encryption, PIN requirement, VPN profile
  → NAC checks MDM enrollment status via API
  → MDM compliance → BYOD VLAN (restricted, but productive)
  → No MDM → Guest VLAN or no access

  Privacy Compromise (MDM on Personal Devices):
  → Apple: User Enrollment (MAM only, no device wipe!)
  → Android: Work Profile (separates personal/work)
  → Employer sees ONLY the Work Profile, not personal apps/data

Strategy 2 - Certificate-Based BYOD:
  → User receives client certificate after registration
  → Certificate on personal device (keystore)
  → 802.1X with EAP-TLS: Certificate for authentication
  → No posture check (no full compliance)
  → BYOD VLAN: limited resources

Strategy 3 - ZTNA instead of LAN access:
  → Personal device: NO network access!
  → Application access only via ZTNA (Zero Trust Network Access)
  → Secure Enclave/Sandbox app: only company apps in an isolated environment
  → No access to internal network → no lateral movement risk
  → Recommended: Cloudflare Access, Zscaler Private Access, Microsoft Entra ID

BYOD Policy (Legal Requirements):
  □ Written consent: Device may be managed
  □ Clear scope: Which data/apps on the personal device
  □ Remote wipe policy: Only work container, not the entire device
  □ Separation: Personal vs. work (Work Profile)
  □ Privacy policy: What data is collected via the device?

Comparison of NAC Solutions

Leading NAC Products:

Cisco Identity Services Engine (ISE):
  Strengths:
    → Market leader, deep Cisco integration
    → Comprehensive posture assessment
    → pxGrid integration: context sharing with other security solutions
    → TrustSec (SGT): software-defined segmentation
    → Profiling: automatic device detection (over 7,000 profiles!)
  Weaknesses:
    → High licensing costs ($$$)
    → Complex implementation (typically 6-12 months!)
    → High hardware requirements
  Recommendation: For Cisco-centric enterprises, starting at ~$50/device/year

Aruba ClearPass (HPE):
  Strengths:
    → Vendor-agnostic (works with Cisco, Juniper, Aruba)
    → Strong BYOD workflows
    → OnGuard Agent for deep posture assessment
    → Good API for automation
  Weaknesses:
    → Complex, requires expertise
    → Aruba switches for best integration
  Recommendation: Best BYOD workflow, vendor-agnostic

Microsoft Network Policy Server (NPS):
  Strengths:
    → Free (in Windows Server)
    → Native AD integration
    → Good for pure Microsoft environments
  Weaknesses:
    → Limited posture capabilities (domain check only)
    → No modern zero-trust features
    → Legacy architecture
  Recommendation: As a starter/supplement, not as a primary NAC

Portnox Cloud:
  Strengths:
    → Cloud-native NAC (no on-premises server!)
    → Easier to implement than Cisco ISE
    → BYOD-friendly
    → Azure AD / Entra ID integration
  Weaknesses:
    → Less powerful than ISE in complex scenarios
    → Relatively new platform

Forescout Platform:
  Strengths:
    → Agentless: detects all devices without an agent
    → IoT/OT specialist: detects industrial devices
    → No 802.1X requirement (works with legacy switches)
  Recommendation: For OT/IoT environments + legacy networks

Selection criteria:
  □ Network vendor: Cisco → ISE; Aruba → ClearPass; Mixed → Forescout/Portnox
  □ Budget: Small → Microsoft NPS + Portnox; Large → ISE/ClearPass
  □ IoT proportion: High → Forescout (agentless)
  □ Cloud-first: → Portnox or ZTNA instead of classic NAC
  □ BYOD focus: → Aruba ClearPass (best BYOD workflow)

NAC as a Zero-Trust component

NAC in a Zero-Trust Context:

Zero-Trust Principle: "Never trust, always verify"
NAC Contribution:
  → Device must identify itself (802.1X / certificate)
  → Device must demonstrate compliance (posture)
  → Access is context-dependent (VLAN/segment per device/role)
  → Continuous verification (posture regularly re-evaluated)

NAC + Conditional Access (Microsoft):
  → Intune: marks devices as compliant/non-compliant
  → Azure AD Conditional Access:
    → Device must be "Intune compliant" for O365 access
    → Can be combined with NAC: non-compliant → Quarantine + no O365

Implementation Recommendation:
  Start:      Wi-Fi first (simpler, fewer devices)
  Phase 2:    Wired LAN (more complex)
  Phase 3:    IoT devices + MAB
  Phase 4:    Posture Assessment
  → Never do everything at once: roll out in phases!

Implementation Roadmap

NAC Rollout Phases (typically 12-18 months):

Phase 1 (Months 1-3): Inventory and Design
  □ Map all network segments
  □ Identify all device categories (PC, mobile, printer, IoT)
  □ Design VLAN concept
  □ Policy requirements (HR, Legal for BYOD policy)
  □ Select NAC product + PoC

Phase 2 (Months 4-6): Pilot
  □ Configure 802.1X on pilot switches (not production!)
  □ 50-100 pilot users: corporate Windows devices
  □ Test authentication + basic posture
  □ Define help desk processes (NAC issues → how to resolve?)
  □ Exception process: who gets exceptions?

Phase 3 (Months 7-9): BYOD + Mobile
  □ MDM enrollment workflow
  □ BYOD VLAN + policies
  □ Certificate distribution for EAP-TLS
  □ Guest Wi-Fi + captive portal

Phase 4 (Months 10-12): IoT and Legacy
  □ MAB for printers, cameras, phones
  □ Profiling: automatic device detection
  □ IoT VLAN + microsegmentation
  □ Legacy devices: exceptions or replacement

Phase 5 (Months 13-18): Full rollout + monitoring
  □ All switches/Wi-Fi networks migrated
  □ Monitoring: NAC dashboard + SIEM integration
  □ Regular policy reviews (quarterly)
  □ Incident playbooks: NAC failure, false positives

Key Performance Indicators (KPIs):
  → % of devices under NAC control (Target: >95%)
  → Unmanaged devices detected (Target: <5%)
  → Quarantine events/week (Trend: decreasing!)
  → Mean Time to Remediate (Quarantine → Compliance)
  → NAC Availability: >99.9%