An employee brought in a personal router, plugged it into a wall jack, and created an unauthorized WiFi hotspot. It ran for 3 months before anyone noticed. With 802.1X NAC, that device would have been blocked the moment it connected.
Network Access Control (NAC) ensures that only authorized devices can connect to your network. 802.1X is the protocol that makes it happen. Here's how to deploy it.
What is Network Access Control (NAC)?
NAC is a security solution that verifies devices before granting network access. It checks device identity, health, and compliance against your security policies. Non-compliant devices get quarantined or blocked.
802.1X is the IEEE standard for port-based network access control. When a device connects to a switch port or WiFi access point, it must authenticate before getting network access. Think of it as a bouncer at the door of your network.
Why NAC Matters
Without NAC, any device that plugs into a wall jack or connects to WiFi gets network access. That includes personal routers, IoT devices, malware-infected laptops, and unauthorized phones.
NAC prevents: unauthorized device access, lateral movement by attackers, BYOD security risks, and compliance violations.
How to Deploy 802.1X NAC
Step 1: Plan Your Authentication Methods
802.1X supports three device types: Supplicant (devices that can authenticate, like Windows PCs), Monitor-only (devices that can't authenticate, like printers), and Guest (devices that need temporary access).
For each type, plan the authentication method: corporate PCs use certificate-based auth, printers use MAC authentication bypass (MAB), and guests use a captive portal.
Step 2: Set Up RADIUS Server
The RADIUS server is the brain of NAC. It receives authentication requests from switches and access points, checks credentials against your directory, and returns access decisions.
We typically use Windows NPS (Network Policy Server) or FreeRADIUS. FortiGate can also act as a RADIUS server for smaller deployments.
Configure the RADIUS server with: your Active Directory connection, authentication policies (what credentials to accept), and authorization policies (what VLAN/access level to assign).
Step 3: Configure Network Devices
Enable 802.1X on your switch ports and WiFi access points. Point them to your RADIUS server.
On Cisco switches: 'dot1x system-auth-control'. On FortiGate WiFi: enable 802.1X in the SSID settings. On access points: configure the RADIUS server IP and shared secret.
Step 4: Define Access Policies
Create policies that map authentication results to network access:
Corporate devices (certificate auth) -> Full network access, assigned to corporate VLAN. BYOD devices (user credentials) -> Internet-only VLAN, no access to internal resources. IoT devices (MAB) -> IoT VLAN, limited to specific services. Guests (captive portal) -> Guest VLAN, internet-only with time limits.
Step 5: Deploy in Monitor Mode First
Before enforcing 802.1X, run it in monitor mode for 2-4 weeks. This logs what would be blocked without actually blocking anything. You'll discover devices you didn't know existed.
We found: forgotten test servers, personal devices, IoT sensors, and even a cryptocurrency miner during one audit.
Best Practices
1. Start with monitor mode. Don't enforce 802.1X until you've identified and exempted all legitimate devices.
2. Use certificates for corporate devices. They're more secure than passwords and can't be shared.
3. Create a clear BYOD policy. Users need to understand what access their personal devices will have.
4. Maintain a device registry. Keep track of all authorized devices, their owners, and their compliance status.
5. Test failover scenarios. What happens if the RADIUS server goes down? Configure a fallback policy.
Common Mistakes
Mistake 1: Enforcing too quickly. Without a monitor phase, you'll block legitimate devices and create a helpdesk nightmare.
Mistake 2: Not handling IoT devices. Many IoT devices can't do 802.1X. Plan for MAB or certificate-based auth for these.
Mistake 3: Single point of failure. Deploy redundant RADIUS servers. If the RADIUS server is down, devices can't authenticate.
Conclusion
NAC with 802.1X is the foundation of network access security. It ensures that only authorized, compliant devices connect to your network. Start in monitor mode, identify your device inventory, then enforce policies systematically.
Want to go deeper? Explore [Protect security services](/en/products/protect), [industry solutions](/en/solutions), or [get a security assessment](/en/contact).
FAQ
Q: Does 802.1X work with wireless? A: Yes. 802.1X works on both wired (switch ports) and wireless (WiFi) networks. Most enterprise WiFi deployments use 802.1X.
Q: What if a device can't do 802.1X? A: Use MAC Authentication Bypass (MAB) for devices like printers and IoT sensors. The switch verifies the MAC address instead.
Q: How does 802.1X affect user experience? A: Corporate users authenticate once at login (transparent). Guests see a captive portal. The impact is minimal once configured properly.
Q: Can 802.1X integrate with Active Directory? A: Yes. Most RADIUS servers (NPS, FreeRADIUS) connect to AD for authentication. User credentials are verified against AD directly.
Threat Landscape and Current Attack Vectors
Understanding the current threat landscape is essential for making informed security decisions. In 2025, the most common attack vectors include ransomware (up 150% from 2024), supply chain attacks (targeting software vendors and managed service providers), credential stuffing (exploiting password reuse across services), and zero-day exploits (targeting unpatched vulnerabilities).
According to the 2025 Verizon Data Breach Investigations Report, 68% of breaches involve a human element (phishing, stolen credentials, or errors). This means technology alone is not enough - you need people, processes, AND technology working together.
Implementation Roadmap
We recommend a phased approach to implementation. Phase 1 (Weeks 1-4): Assessment and design. Document current state, identify gaps, design target architecture. Phase 2 (Weeks 5-8): Deploy core components. Install and configure the primary solution in a test environment. Phase 3 (Weeks 9-12): Pilot testing. Deploy to 20-30% of users, collect feedback, refine configuration.
Phase 4 (Weeks 13-16): Full deployment. Roll out to remaining users with minimal disruption. Phase 5 (Weeks 17-20): Optimization. Fine-tune policies, optimize performance, and document procedures. This timeline works for most medium enterprises (200-500 users).
Compliance and Regulatory Considerations
If your organization is subject to regulatory requirements (PCI DSS, HIPAA, ISO 27001, GDPR), ensure your implementation addresses these requirements from the start. Retrofitting compliance is significantly more expensive than building it in. We recommend creating a compliance matrix that maps each regulatory requirement to specific technical controls.
Common compliance gaps we see: insufficient audit logging (PCI DSS requires 12 months of logs), missing encryption at rest (required by HIPAA and GDPR), inadequate access controls (required by ISO 27001), and missing incident response procedures (required by all frameworks).