NAC Rollout Playbook: Phased 802.1X Implementation

Network access control projects rarely fail on technology; they stall in monitor mode for years because nobody defined when a site is ready to enforce, who owns the devices that cannot authenticate, and how to undo a bad change before the phones stop working. This playbook is for network, identity and endpoint teams rolling out 802.1X-based NAC across wired and wireless networks. It turns the design into a project: readiness checks, device discovery and ownership, certificates and supplicants, the RADIUS service, the policy matrix, phase exit criteria, the exception process and operational handover. It is vendor-neutral. How 802.1X, EAP, MAB and Change of Authorization work is explained in the Network Access Control (NAC) Guide; this page assumes that knowledge and focuses on doing it.

Key takeaways

Every phase needs exit criteria. Define in advance the authentication success rate and unknown-device count a site must reach before it moves from monitor to low-impact to closed mode.
Devices without supplicants are the project. Printers, phones, badge readers, building systems and medical or lab kit decide the timeline; give each class an owner and a policy before enforcement.
Fix RADIUS first. Require Message-Authenticator on all RADIUS traffic (the Blast-RADIUS fix), build redundant servers near sites, and plan for RADIUS over TLS.
Certificates before enforcement. Machine certificates, auto-enrolment and supplicant profiles with server validation must be in place and monitored before anything is blocked.
Rollback is one change per site. Template the port and SSID configuration so any site can return to monitor mode in minutes.

Readiness assessment

Before you design policy, find out what the estate can do. Every access switch, wireless controller and access point needs to support the features your design depends on, at the firmware you run.

Area	Check	If it fails
Access switches	802.1X and MAB on the same port, multi-domain or multi-auth for phone plus PC, dynamic VLAN or downloadable ACL, CoA (RFC 5176, UDP 3799), critical VLAN when RADIUS is unreachable	Firmware upgrade or hardware refresh goes into the plan as a dependency; those sites go in later waves
Wireless	WPA2 or WPA3-Enterprise, per-SSID RADIUS, CoA support	Usually fine; wireless often goes first
RADIUS clients	Ability to require and send Message-Authenticator on all packets; RADIUS over TLS support	Record as a risk; prioritise those devices for upgrade
Endpoints	Managed supplicant on each OS, machine certificate enrolment, user versus machine authentication choice	Unmanaged or legacy endpoints go into the device-class register below
PKI	Issuing CA for device certificates, revocation checking reachable before network access, auto-enrolment	Build or extend PKI first; see the Enterprise PKI Design and CA Hierarchy Guide
Inventory sources	CMDB, MDM, EDR, DHCP and switch MAC tables available to correlate	Discovery takes longer and profiling is less accurate

Device discovery and ownership

Turn on authentication in monitor mode and let RADIUS accounting and profiling build the picture. Then sort every device that cannot do 802.1X into a class with a named owner. This is the register the whole rollout is managed from.

Device class	Typical method	Policy on success	Owner
Managed laptops and desktops	EAP-TLS with machine certificate	Corporate role	Endpoint team
IP phones	802.1X with certificate where supported, otherwise MAB plus profiling	Voice VLAN, call control only	Telephony team
Printers and multifunction devices	802.1X where supported, otherwise MAB plus profiling	Print servers only	Facilities or print service owner
Building, physical security and IoT devices	MAB with an authorised device list	Their own segment, tight ACL to their controllers	Facilities or security operations
Medical, lab or production equipment	MAB, often with fixed ports	Isolated segment agreed with the clinical or engineering owner	Clinical engineering or plant engineering
Guest and personal devices	Separate SSID or captive portal	Internet only	Service desk

MAC addresses can be spoofed, so a MAB device's access should only reach what that class needs. NIST SP 800-53 IA-3 Device Identification and Authentication expects devices to be identified and authenticated before a connection is established; MAB is identification, not strong authentication, which is why the authorisation behind it must be narrow. Devices that can enrol certificates should be moved off MAB over time; see the IoT and Device Certificate Provisioning (EST, SCEP) Guide.

Certificates and supplicants

EAP-TLS where you can: certificate-based authentication avoids passwords on the wire and suits machine authentication before user logon. RFC 9190 defines EAP-TLS with TLS 1.3 and prohibits TLS 1.0 and 1.1.
Pin server validation: RFC 9190 says peers should be configured with trusted root CAs and the server name to match; without name matching, confidence that the client is talking to your RADIUS server drops. Push supplicant profiles by group policy or MDM with both set, and never let users accept a new server certificate.
Revocation: RFC 9190 requires peers to check certificate revocation status. Make sure the RADIUS server can reach CRL or OCSP responders, and decide what happens if it cannot.
Monitor expiry: an expired machine certificate becomes a lockout once you enforce. Alert on certificates expiring within 30 days (our recommendation) and on auto-enrolment failures.
Plan the RADIUS server certificate renewal: clients pinned to the server name and issuing CA keep working across a renewal; clients pinned to a specific certificate do not. Test renewal in the pilot.

Wi-Fi specifics are in the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.

Build the RADIUS service

RADIUS becomes a dependency for every port and SSID. Build it as tier-zero infrastructure before any enforcement.

Message-Authenticator everywhere: Blast-RADIUS (CVE-2024-3596) lets an attacker in the path between a RADIUS client and server forge an Access-Accept for a failed authentication when non-EAP methods are used. The researchers' recommended fix is to require the Message-Authenticator attribute on all requests and responses, first in Access-Accept and Access-Reject, upgrading servers first and then clients. RFC 3580 already requires it on packets carrying EAP.
Protect the transport: the long-term recommendation is RADIUS inside an authenticated, encrypted channel (RADIUS over TLS or DTLS). Where devices cannot do that yet, keep RADIUS on a management network; RFC 3580 and RFC 5176 both recommend IPsec for RADIUS traffic.
Secrets: unique shared secret per RADIUS client, at least 16 octets as RFC 3580 suggests, held in a vault, not in a spreadsheet. Never reuse the 802.1X secret for PAP-based device administration, as RFC 3580 warns.
CoA sources: RFC 5176 says the NAS should discard CoA and Disconnect requests from untrusted sources. Restrict UDP 3799 to your policy servers.
Resilience: at least two servers per region, placed so a WAN failure does not take a site offline, with the switch critical VLAN configured and tested.

Where identity fits

NAC is the point where device identity meets user identity. Most of the identities it handles are non-human: machine certificates, MAB entries for IoT and building devices, the RADIUS shared secrets of every switch, and the service accounts the policy server uses to query directories, MDM and EDR. Give each an owner and a lifecycle. Leaving MAB entries for devices that have been retired is the NAC version of an orphaned account. See the Machine Identity, PKI and Certificate Lifecycle Guide.

The phased playbook with exit criteria

Lab: reproduce one access switch, one AP and each device class. Test RADIUS outage (critical VLAN), certificate expiry, server certificate renewal and CoA.
Monitor mode, all sites: authentication runs but access is permitted on failure. Exit when, for a full business cycle, the share of authentications passing is high enough for the site to enforce (we suggest 98 percent of active ports) and every failing device is in the class register with an owner.
Low-impact mode, pilot site: a pre-authentication ACL allows only what devices need to authenticate and enrol (DHCP, DNS, PKI and directory). Exit when the service desk sees no unexplained lockouts for two weeks (our recommendation).
Closed mode by wave: wireless first, then wired by floor or building. Voice and critical device ports last. Each wave has a named change, a site contact on the day and the rollback below.
Authorisation by role: introduce role-based VLANs or downloadable ACLs, quarantine and CoA from EDR or MDM signals only once enforcement is stable. Changing authentication and authorisation in the same wave doubles the fault-finding.
Handover: runbooks, dashboards and the exception process move to operations; the project closes only when each site has been in closed mode for one full business cycle.

Rollback

Keep port and SSID settings in templates so a site can be returned to monitor mode with one change. Practise it in the pilot. For a single device, use a time-limited exception rather than disabling enforcement on a port.

The exception process

Request: raised by the device owner with the business reason, location and expected end date.
Grant: a MAB entry or a port exception with the narrowest ACL for the device class and an expiry date. 90 days is our recommended maximum before review.
Review: expired exceptions are disabled automatically; open exceptions are reported monthly to the device owner.

Pilot selection, communications and handover

The pilot site sets the tone for the rest of the programme. Choose one with a representative mix of device classes, a local IT contact who will be on site during changes, and no business event in the change window. Avoid the head office reception floor and any clinical, trading or production area for the first enforcement wave.

Audience	What they need before their wave	When
Service desk	A script for "cannot connect" calls, how to read the RADIUS failure reason, how to raise a time-limited exception, and the escalation route on the day	Two weeks before the first enforcement wave
Device owners	The list of their devices that still fail authentication and the date their ports will enforce	Four weeks before their site's wave
Staff at the site	What changes (usually nothing visible), what a lockout looks like and who to call	One week before
Security operations	The new RADIUS log sources, alert rules and who owns tuning	Before monitor mode ends

Handover to operations should include: the port and SSID templates and how to apply the rollback template; the device class register and who keeps it current; certificate renewal ownership for both client and RADIUS server certificates; the exception register and its monthly report; and a quarterly review of RADIUS client secrets and of MAB entries whose devices have not been seen for 90 days (our recommendation). The steady-state checks are in the Network access control (NAC) health check.

Choosing the approach

Small organisation: start with WPA2 or WPA3-Enterprise and EAP-TLS on corporate wireless, a guest SSID, and port security on the few public wired ports. Full wired enforcement may not repay its cost.
Large campus: centralise policy, regionalise RADIUS, and run monitor mode everywhere early so data drives the wave order.
IoT-heavy or clinical sites: profiling and segmentation of device classes deliver most of the value; enforcement on those ports is the last wave. See the Network Segmentation Guide.
Old access switches: do not let the oldest hardware set the design. Put those sites in a later wave tied to the refresh plan.

Detection and measurement

Metric or signal	Source	What good looks like
Authentication success rate per site	RADIUS logs	Meets the exit threshold before each phase change
Unknown or unclassified devices	Profiling and accounting	Falls week on week; zero before closed mode
Share of ports and SSIDs enforcing	Configuration management	Rises on plan; reported per site
Open and expired exceptions	Exception register	No expired exceptions still active
Machine certificates expiring within 30 days	PKI and RADIUS failure reasons	Renewed before expiry
RADIUS packets without Message-Authenticator	RADIUS server logs	Zero once all clients are upgraded

Forward RADIUS authentication and accounting logs to the SIEM and alert on the same MAC address authenticating from two ports at once, MAB devices whose profile changes (a printer that now looks like a laptop), and spikes of failures from one switch. T1200 Hardware Additions in ATT&CK describes the rogue devices NAC is meant to stop.

Common failure patterns

Monitor mode forever: no exit criteria, so no site ever enforces and the project reports "deployed" while blocking nothing.
MAB as the catch-all: every failing device added to the MAC list with full access. A spoofed MAC then gets the network.
Unvalidated server certificates: supplicants that accept any RADIUS server let an attacker run a rogue access point and collect credentials (ATT&CK T1557 Adversary-in-the-Middle).
RADIUS left on legacy settings: no Message-Authenticator requirement and shared secrets reused across hundreds of switches.
Critical VLAN never tested: the first RADIUS outage takes down every enforcing site at once.
Authorisation changes in the same wave as enforcement: lockouts cannot be traced to a cause, and the business loses patience.

Framework mapping

Rollout activity	NIST SP 800-53 Rev. 5	NIST CSF 2.0	MITRE ATT&CK
Device discovery and class register	CM-8 System Component Inventory	ID.AM-01	T1200 Hardware Additions
Device authentication (EAP-TLS, MAB)	IA-3 Device Identification and Authentication	PR.AA-03	T1200
Role-based VLANs and ACLs	AC-3 Access Enforcement, SC-7 Boundary Protection	PR.IR-01	n/a
RADIUS hardening and secrets	IA-5 Authenticator Management, SC-8 Transmission Confidentiality and Integrity	PR.DS-02	T1557 Adversary-in-the-Middle
Phase changes and rollback	CM-3 Configuration Change Control	n/a	n/a
RADIUS log monitoring	SI-4 System Monitoring	DE.CM-01	n/a

Practitioner checklist

Switch, wireless and RADIUS client capabilities checked against the design, with gaps in the plan.
Device class register with an owner and a policy for every class that cannot do 802.1X.
Machine certificates and supplicant profiles deployed with server name and CA pinned, and expiry alerting on.
RADIUS redundant, Message-Authenticator required, unique shared secrets vaulted, UDP 3799 restricted.
Exit criteria written for monitor, low-impact and closed modes, and reported per site.
Critical VLAN and RADIUS outage tested in the lab and the pilot.
Exception process with expiry dates and monthly reporting.
One-change rollback per site, practised.
RADIUS logs in the SIEM with alerts for duplicate MACs and profile changes.

Network access control (NAC) rollout playbook: reach enforcement without locking out the business