NAC Migration Playbook: Move Platforms Safely

Moving from one network access control platform to another means changing the RADIUS server that every switch, wireless controller and VPN concentrator trusts, and every supplicant that validates its certificate, so a careless migration either locks users out or quietly opens the network. Migrations follow end of support, a vendor change, a move to a cloud-delivered service, or a merger. This playbook covers what has to move, how to handle the EAP server certificate and the RADIUS shared secrets, migrating MAC Authentication Bypass (MAB) and guest populations without carrying old exceptions, cutover patterns, rollback, and decommissioning the old platform. It is vendor-neutral and written for network and identity engineers who already run NAC. How NAC works, EAP method choice and a first-time rollout are covered in the Network Access Control (NAC) Guide and the Network access control (NAC) rollout playbook; this page does not repeat them.

Key takeaways

The server certificate is the riskiest object. Supplicants that validate the EAP server certificate will fail against a new server unless the new chain and server name are trusted first; supplicants that do not validate it were already exposed and should be fixed during the move.
Re-issue every shared secret. Each network access device (NAD) gets a new, unique RADIUS secret on the new platform, and the migration is the moment to require Message-Authenticator and plan RADIUS over TLS.
MAB lists are where exceptions hide. Re-validate every MAC address and device group against the asset inventory instead of bulk importing the endpoint database.
Migrate one NAD group at a time. Point a pilot set of switches or SSIDs at the new servers in a non-enforcing mode, compare results with the old platform, then enforce and move on.
Decommissioning is a security task. The old servers hold directory credentials, certificates, secrets and endpoint data, and they still answer RADIUS until every NAD stops pointing at them.

What has to move

Start with an inventory of every object the old platform holds, and decide for each one whether it migrates, is rebuilt or is retired.

Object	Migration approach	Watch for
Network access device definitions (switches, wireless controllers, VPN)	Rebuild from the network inventory, not from the old NAD list	Stale NADs for devices long retired; whole subnets defined as one client
RADIUS shared secrets	New unique secret per NAD	Importing one shared secret used across the estate
EAP server certificate and chain	New certificate, trust distributed to supplicants before cutover	Exporting the old private key to save effort
Authentication and authorisation policy	Re-express as intent per network zone, then build	Rule order semantics differ between platforms
Authorisation results (VLANs, downloadable ACLs, security group tags)	Map each result to the target syntax and test on each switch model	Vendor-specific attributes that the new platform names differently
Endpoint database and MAB lists	Re-validate against the CMDB and recent accounting data	Static MAC entries nobody can explain
Identity sources (directory join, LDAP bind, certificate authorities)	New least-privilege service accounts; new trust configuration	Old bind accounts with broad directory rights left enabled
Guest portal, sponsors and guest accounts	Rebuild portal; let active guest accounts expire rather than migrate	Long-lived guest or contractor accounts carried across
Posture policies and agents	Rebuild checks; plan agent replacement on endpoints	Two posture agents running, or none during the gap
Change of Authorization (CoA) settings	Configure the new servers as dynamic authorisation clients on each NAD	Old servers still allowed to send CoA after cutover
Device administration (TACACS+), if hosted on the same platform	Treat as a separate workstream with its own cutover	Administrators locked out of switches mid-migration
Integrations (SIEM, firewalls, MDM, vulnerability scanners, ticketing)	New credentials per integration	API keys copied from the old platform

The EAP server certificate and supplicant trust

With EAP-TLS, PEAP and EAP-TTLS, the supplicant decides whether to trust the authentication server by checking its certificate. The new NAC servers will present a different certificate, often from a different issuing CA, and that single change causes most migration outages.

Find out how supplicants validate today: export the wired and wireless profiles from endpoint management for each platform and record the trusted root or issuing CA and any configured server names. Profiles with validation disabled, or users who were trained to click through certificate prompts, are an existing exposure to rogue access points and credential capture (ATT&CK T1557 Adversary-in-the-Middle).
Choose the new certificate: issue it from the internal PKI with a server name the profiles can pin. Keeping the same issuing CA and server name avoids profile changes.
Push the new trust first: deploy updated profiles that trust both the old and new server certificate chains, wait until the device management console shows coverage across the fleet, then cut over.
Handle unmanaged supplicants: devices configured by hand will not receive the new profile; list them from accounting data and plan manual changes.

For EAP-TLS, check that the new platform trusts the client issuing CAs, maps the same certificate fields to identity and checks revocation. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide and the Certificate Revocation Guide.

RADIUS secrets, Message-Authenticator and transport

Every NAD must be reconfigured to point at the new servers, so the migration touches each device's RADIUS configuration anyway. Use that change to fix the protocol weaknesses that have accumulated.

Unique secrets: generate a new, long, random shared secret for each NAD and store it in a secrets manager or the network automation system, not in a spreadsheet. RFC 5176 also recommends that each dynamic authorisation client have its own shared secret.
Message-Authenticator: the Blast-RADIUS research (CVE-2024-3596) showed that an attacker between a RADIUS client and server can forge an Access-Accept for non-EAP authentication such as PAP. The researchers' short-term mitigation is to require the Message-Authenticator attribute on all requests and responses, updating servers first and then clients. Build the new servers with that requirement on, and confirm each NAD software version supports it before moving the NAD.
RADIUS over TLS: the longer-term mitigation the same researchers recommend is to carry RADIUS inside TLS (RadSec), with TLS 1.3. Where NADs and the new platform support it, or where RADIUS crosses untrusted networks to a cloud-delivered NAC service, plan for it in the target design rather than as a later project. See the RADIUS Security Guide.
CoA hardening: RFC 5176 Change of Authorization and Disconnect messages use UDP port 3799, and the RFC's security considerations say a NAS should silently discard such requests from untrusted sources. On each NAD, accept CoA only from the new servers' addresses and remove the old servers as dynamic authorisation clients at cutover.

Migrating MAB, profiling and guest populations

MAC Authentication Bypass lets devices without a supplicant join on the strength of a MAC address that anyone can read and spoof. Old NAC platforms accumulate MAB entries for devices that left years ago, and bulk import moves all of them.

Population	Old state to check	Target treatment
Printers, phones, cameras, building systems	Static MAC lists, broad VLAN assignment	Re-validate against the CMDB and recent accounting; assign to a restricted segment per device type
Devices capable of 802.1X but using MAB	Convenience exceptions	Move to certificates during the migration; see the IoT and Device Certificate Provisioning (EST, SCEP) Guide
Profiled devices	Rules that trust DHCP or user-agent attributes alone	Combine profile with location and tight ACLs; never grant user-level access on a profile alone
Guests and sponsors	Guest accounts with long expiry; sponsors who left	Rebuild sponsor groups from the directory; let guest accounts expire on the old platform
Fail-open and critical VLANs	Behaviour when RADIUS is unreachable	Re-decide per site; document which ports fail open and to which segment

Re-validation rule (our recommendation): migrate a MAB entry only if the device appears in the asset inventory with an owner, and the MAC has authenticated in the last 90 days. Park the rest in a review list on the old platform; if a device is genuinely needed, its owner will raise it during the pilot. The IoT Device Onboarding Guide covers onboarding devices properly on the new platform.

Where identity fits: the platform's own non-human identities

A NAC platform is also a heavy user of machine credentials, and each one should be re-issued, not copied.

Directory accounts: the account used to join the domain or bind to LDAP needs read access only to the attributes and groups the policy uses. Create a new account for the new platform and disable the old one at decommissioning.
Integration API keys: SIEM, firewall context sharing, endpoint management and vulnerability scanner integrations each get their own scoped credential. See the Network access control (NAC) integration security guide.
Administrator access: federate admin sign-in with phishing-resistant MFA and keep one vaulted break-glass account per cluster.

Choosing a cutover pattern

Pattern	How it works	Choose it when	Trade-off
NAD group by NAD group	Reconfigure one site, building or switch stack to the new servers at a time	Most migrations; many sites	Two platforms run for months; policy changes must be made twice
SSID or port role first	Move a new SSID or a set of access ports, then retire the old ones	Wireless-heavy estates; profile changes needed anyway	Users must join a new SSID; coverage overlap required
Proxy through the old servers	Old servers forward RADIUS to the new platform for selected realms or NADs	NAD reconfiguration is slow or change windows are scarce	Extra hop and failure point; old platform stays in the path
Single weekend swap	All NADs repointed in one change	Small, single-site estates with a tested configuration	Every problem at once; rollback is a mass reconfiguration

Decision guidance: a small organisation with a few switches and one wireless controller can swap in one change window after lab testing, provided the old servers stay running for rollback. A large organisation should move NAD group by NAD group, start with an office site that has good local support, and leave data centre, OT and clinical areas until last. Avoid configuring the old server as primary and the new one as secondary on the same NAD unless both run the same policy: a timeout silently flips users to a different policy and makes faults hard to trace.

The phased playbook

Phase 0, inventory and baseline: export NADs, policy, endpoint and MAB data, certificates and integrations; record authentication success rates, active sessions per site and the top failure reasons from the old platform.
Phase 1, clean the source: remove dead NADs, unowned MAB entries, expired guests and unused rules on the old platform.
Phase 2, build the target: hardened management, federated admin access, central logging, new certificates and identity source accounts, then policy expressed per zone.
Phase 3, distribute trust: push supplicant profiles that trust both old and new server chains; track coverage per platform.
Phase 4, lab test: for each switch and controller model, test EAP-TLS, PEAP if still used, MAB, guest, VLAN and ACL assignment, CoA and Disconnect, re-authentication timers and RADIUS server failure behaviour.
Phase 5, pilot in a non-enforcing mode: move one NAD group with the new policy in monitor mode or a low-impact mode, and compare each session's result with what the old platform would have returned.
Phase 6, enforce and wave: enforce on the pilot group, then move groups in waves, with network and service desk staff briefed and a test script per site.
Phase 7, freeze and decommission: keep the old platform running but unused for an agreed freeze, then decommission it as below.

Rollback

Script the NAD change both ways: the configuration that points a NAD group at the new servers should have a tested reverse change.
Agree triggers in advance: for example authentication success below 95% of the site baseline after 30 minutes, or any critical clinical, production or safety device losing access (our recommendation).
Keep old trust in profiles until the freeze ends: otherwise a rollback fails on certificate validation.

Decommissioning the old platform

Confirm nothing still points at it: watch the old servers' RADIUS and TACACS+ logs for any request during the freeze; each one is a NAD or integration that was missed.
Remove it from every NAD: delete the old servers from RADIUS server groups and from the list of allowed CoA clients.
Revoke what it held: the old EAP server certificate, the directory and LDAP bind accounts, integration API keys and administrator accounts. Remove the old chain from supplicant profiles.
Archive logs and accounting: keep authentication and accounting logs for the period your retention policy sets (NIST SP 800-53 AU-11), encrypted and access restricted.
Sanitise appliances and virtual machines: they hold secrets and endpoint data; follow NIST SP 800-88 Rev. 2 and record it (MP-6).

Detection and measurement

Metric or signal	Why it matters	Target (our recommendation)
Authentication success rate per migrated site	Shows supplicant trust and policy problems	Within 2 points of the old baseline
MAB entries migrated without an inventory owner	Unexplained exceptions carried across	Zero
NADs sharing a RADIUS secret	One leaked secret affects many devices	Zero
Access-Requests without Message-Authenticator	Blast-RADIUS exposure	Zero on the new platform
Supplicant profiles with server validation disabled	Credential capture by rogue access points	Zero on managed devices
RADIUS requests still reaching the old servers	Missed NADs before decommissioning	Zero for the whole freeze period

Send authentication, accounting, CoA and admin audit logs to the SIEM before the pilot, and alert on reject spikes per NAD and on one MAC address seen on two ports at once.

Common failure patterns

Certificate surprise: the new server certificate is installed on cutover night and every validating supplicant fails, or worse, users are told to accept the prompt.
Bulk MAB import: the old endpoint database is imported whole, so years of unexplained MAC exceptions keep network access.
One shared secret everywhere: the old secret is reused on the new platform for speed, and stays in configuration backups for years.
Open mode becomes permanent: a pilot runs in monitor mode, the project loses momentum, and enforcement never returns.
Old servers left running: forgotten NADs still authenticate against an unpatched platform that holds valid directory credentials.

Framework mapping

Activity	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Other
Device authentication at the port and SSID	IA-3, AC-3	PR.AA-03	CIS Controls v8.1 Safeguard 13.9
Endpoint and MAB inventory	CM-8	ID.AM-01	Not mapped
Shared secrets, certificates and service accounts	IA-5, AC-6	PR.AA-01	ATT&CK T1078 Valid Accounts
Segmentation by authorisation result	SC-7	PR.IR-01	Not mapped
Rogue devices and interception	SI-4	DE.CM-01	ATT&CK T1200, T1557
Change control and rollback	CM-3	Not mapped	Not mapped
Log review and retention	AU-6, AU-11	PR.PS-04	Not mapped
Decommissioning	MP-6	Not mapped	NIST SP 800-88 Rev. 2

Practitioner checklist

Inventory every NAD, policy, certificate, identity source, integration and MAB entry, and treat exports as secrets stored encrypted.
Record how each supplicant platform validates the server certificate and fix profiles that do not validate.
Issue a new EAP server key pair and push trust for both old and new chains before any cutover.
Give every NAD a new unique RADIUS secret and require Message-Authenticator on the new servers.
Restrict CoA on each NAD to the new servers only.
Migrate MAB entries only with an inventory owner and recent activity; let guest accounts expire.
Create new least-privilege directory and integration credentials; never copy the old ones.
Pilot one NAD group in a non-enforcing mode, compare results, then enforce and move in waves with scripted rollback.
Watch the old servers for requests during the freeze, then revoke, archive and sanitise.

Network access control (NAC) migration playbook: moving platforms without losing control