Introduction

A network access migration can bring the new 802.1X policy server online while wired or wireless clients still authenticate through the old one. Users stay in the wrong VLAN, certificates are validated against the retired NAC platform, or one office uses the new policy path while another still depends on the previous server because switch AAA settings, wireless controller profiles, and trust configuration often move unevenly.

Treat this as an authentication-path problem instead of a generic client access issue. Start by checking which policy server, RADIUS group, and certificate chain an affected client session actually uses, because migrations often validate the new NAC platform first while access devices continue forwarding EAP traffic to the previous backend.

Symptoms

  • 802.1X clients still authenticate against the old policy server after migration
  • Wired or wireless users land in the wrong VLAN or access policy
  • One switch stack, SSID, or site uses the new NAC path while another still uses the old one
  • Authentication fails only after the previous policy server is shut down
  • The new 802.1X platform is healthy, but live client sessions still depend on the retired backend
  • The issue started after moving NAC, RADIUS, or certificate-based access infrastructure

Common Causes

  • Switches, wireless controllers, or AP groups still point to the old RADIUS or policy server
  • AAA groups or dynamic authorization settings were updated on one device class but not another
  • Client trust chains or EAP certificates still validate against the previous platform
  • Automation templates or controller profiles keep restoring the old policy target
  • Different SSIDs, sites, or edge devices publish different policy paths
  • Validation confirmed the new policy server could authenticate requests but did not verify where live access devices actually sent them

Step-by-Step Fix

  1. Capture one affected client authentication attempt and record the access device, RADIUS target, and policy decision path it actually uses, because the runtime AAA path determines where network admission is enforced.
  2. Compare that active authentication path with the intended post-migration NAC design, because one stale RADIUS group or controller profile can keep large user segments tied to the retired policy server.
  3. Review switch AAA config, wireless controller settings, AP group profiles, server groups, and certificate trust paths for references to the old platform, because 802.1X enforcement spans network infrastructure and PKI together.
  4. Check wired access, wireless SSIDs, and branch sites separately if behavior differs, because migrations often fix one edge path while another still uses the previous policy server.
  5. Update the authoritative access-device and NAC configuration so affected sessions authenticate against the intended platform, because deploying the new policy server alone does not retarget existing RADIUS flows.
  6. Run a controlled client authentication test and confirm the intended policy server handles the request and returns the expected authorization result, because successful network access does not prove the right backend made the decision.
  7. Verify the old policy server no longer receives 802.1X requests from migrated access devices, because split NAC routing can remain hidden while both platforms stay online.
  8. Review certificate trust, EAP method compatibility, and dynamic VLAN or ACL assignment if users still fail, because the destination can be correct while client trust or authorization attributes still break access.
  9. Document which team owns edge AAA templates, wireless policy, and migration validation so future NAC cutovers verify the actual policy server handling live authentications before retiring the previous environment.