Migrating from Cisco ISE to cloud RADIUS: a phased cutover plan

You can move from Cisco ISE to cloud RADIUS in five phases without a flag day when every device trusts the new server certificate. Run Purple alongside ISE site by site. Keep IEEE 802.1X and EAP-TLS unchanged on the client. Cut over in waves, with ISE as the rollback path until the last site moves.

What changes when you move off Cisco ISE, and what stays the same?

The end state is short to describe. Your access points send authentication requests to Purple's cloud RADIUS instead of ISE nodes in your data centre. Purple checks identity against Microsoft Entra ID, Okta or Google Workspace. It then returns the VLAN that identity belongs on. ISE is powered down, its licences lapse, and nobody patches it again.

Some terms first. RADIUS (RFC 2865) is the authentication protocol your controllers already speak. IEEE 802.1X is the port-based access control standard that carries the login over WiFi. EAP-TLS (RFC 5216) authenticates each device with a certificate. PEAP wraps a password exchange inside an encrypted TLS tunnel. A VLAN, or virtual LAN, is the network segment a device lands on after it authenticates.

Four things change:

• RADIUS server addresses and shared secrets on every network access device (NAD), meaning the controller, AP or cloud dashboard that sends requests.
• The server certificate that devices see during 802.1X.
• Where policy lives. ISE policy sets and authorisation profiles become identity groups mapped to VLANs.
• Where identity comes from. A cloud directory replaces ISE joined to on-premise Active Directory.

Your SSIDs, access points, VLANs, switching and any client certificates from your own CA stay as they are. That is what makes a phased move possible. The ISE functions themselves need a destination, and not all of them land on the secure network.

What ISE does today	Where it goes	Purple network
802.1X for staff and corporate devices	Purple cloud RADIUS with EAP-TLS and your identity provider	Secure
MAB (MAC Authentication Bypass) for scanners, printers and sensors	A key per device or device group (iPSK or PPSK, together xPSK)	xPSK
Guest and sponsored portals	A captive portal, the sign-in page shown before access	Open
BYOD onboarding with the ISE internal CA	Certificates from your MDM or your own CA	Secure
TACACS+, wired 802.1X, posture, TrustSec	Out of scope for this plan; give each an owner	None

This plan covers WiFi authentication on your access points. If ISE also runs device administration, wired ports or posture, list each one before phase 1 and give it a separate owner. If ISE hosts a guest portal used for marketing, that moves to the open network and Purple Engage. The secure network guide to certificates, identity and Passpoint covers the target design in depth.

What has to be true before phase 1?

Six conditions, each a yes or no. Do not start building until all six are yes.

1. The inventory is complete. Every SSID, every NAD with its shared secret, every policy set and authorisation profile, and every endpoint group that relies on MAB.
2. You have an ISE baseline. Capture authentications per hour and success rate per SSID per site for at least two weeks. ISE's live logs and reports give you this. Without a baseline, you cannot say whether a wave passed.
3. The certificate plan is written. Note which CA issued your client certificates and which certificate ISE presents for EAP. Note whether any devices hold certificates from the ISE internal CA.
4. Identity groups exist in your directory. Each ISE authorisation rule needs a matching group in Microsoft Entra ID, Okta or Google Workspace, and each group needs a VLAN.
5. Sites can reach the cloud. Firewalls at each site allow RADIUS traffic from the controller or APs to Purple's RADIUS servers.
6. ISE stays supported. Keep ISE licensed, patched and owned until phase 5 exits. It is your rollback path.

One design decision belongs here too. PEAP-MSCHAPv2 checks a password hash that cloud directories such as Microsoft Entra ID do not expose to RADIUS servers. If ISE validates PEAP against on-premise Active Directory, move those devices to EAP-TLS first, while ISE still authenticates them. Change one thing per wave: the EAP method, then the RADIUS server.

{"tone":"warning","title":"The risk that bites: server certificate trust","text":"Every device checks the RADIUS server certificate during 802.1X. Profiles that trust only the ISE EAP certificate or its CA will refuse Purple until your MDM pushes the new trust, so deploy it in phase 2, not on cutover night."}

What are the phases of an ISE migration, in order?

Five phases, each with an owner and an exit test. The durations below suit a 40-site estate; scale them to your own. The cutover at any one site is usually a weekend exercise. The weeks before it are what make it one.

{"kind":"timeline","direction":"lr","caption":"Five phases for a 40-site estate moving from Cisco ISE to Purple cloud RADIUS. ISE stays live until phase 5 exits.","alt":"A timeline of five migration phases, from discovery in weeks 1 to 2 through to ISE decommission from week 10.","nodes":[{"id":"p1","label":"Phase 1: discover and design","sub":"Inventory NADs, policy sets, certificates and MAB devices","tone":"neutral","when":"Weeks 1-2"},{"id":"p2","label":"Phase 2: build in parallel","sub":"Cloud RADIUS, IdP groups, VLAN rules, certificate trust","tone":"brand","when":"Week 3"},{"id":"p3","label":"Phase 3: pilot one site","sub":"Every device class authenticates on the right VLAN","tone":"brand","when":"Weeks 4-5"},{"id":"p4","label":"Phase 4: cut over in waves","sub":"Weekend change windows, ISE kept as rollback","tone":"brand","when":"Weeks 6-9"},{"id":"p5","label":"Phase 5: decommission ISE","sub":"Zero ISE authentications, nodes powered down","tone":"success","when":"Week 10+"}],"edges":[{"from":"p1","to":"p2"},{"from":"p2","to":"p3"},{"from":"p3","to":"p4"},{"from":"p4","to":"p5"}]}

{"caption":"ISE to cloud RADIUS phase plan","asOf":"2026-06-10","columns":[{"key":"phase","label":"Phase"},{"key":"scope","label":"Scope"},{"key":"owner","label":"Owner"},{"key":"exit","label":"Exit test"}],"rows":[["1. Discover and design","Every SSID, NAD, policy set, authorisation profile, certificate and MAB device","Network architect","Signed mapping of each ISE rule to an identity group and VLAN"],["2. Build in parallel","Cloud RADIUS, IdP connection, VLAN rules, xPSK keys, server certificate trust","Identity and access lead","Test devices authenticate against Purple from a lab SSID"],["3. Pilot one site","One representative site, every device class","IT manager with the site lead","Five working days at or above the ISE baseline, correct VLAN for every class"],["4. Cut over in waves","Sites in groups, one change window each","Network operations","Each wave holds baseline for 48 hours with no rollback"],["5. Decommission ISE","ISE nodes, NAD entries, licences, internal CA","IT director","Zero ISE authentications for the period you set, evidence archived"]],"footnote":"Durations and thresholds are planning defaults for a 40-site estate. Set your own from the ISE baseline you capture before phase 1.","download":{"filename":"ise-to-cloud-radius-phase-plan.csv"}}

What happens in each phase of the ISE migration?

Phase 1: discover and design

Export what ISE knows before you change anything. List each policy set, its conditions and the authorisation profile it returns. Most estates find that years of rules collapse into a handful of real outcomes: staff VLAN, contractor VLAN, IoT VLAN, deny.

Write each outcome as an identity group and a VLAN. VLAN assignment over RADIUS uses the tunnel attributes described in RFC 3580. Some controllers also read vendor-specific attributes (VSAs), such as the role attribute HPE Aruba controllers use. Note which ones your hardware expects.

Then find the devices that cannot do 802.1X. ISE's endpoint list shows which MAC addresses authenticate by MAB. Each one needs an xPSK key and a VLAN before its site moves.

Phase 2: build Purple in parallel

Connect Purple to your identity provider and create the group-to-VLAN rules from phase 1. Upload the CA that issued your client certificates so EAP-TLS validates against it. Issue xPSK keys for the headless device groups.

Push trust for Purple's server certificate to every managed device through your MDM. This is the longest-running task in the build, so start it on day one. Set up a lab SSID pointed at Purple and authenticate one device of every class.

Phase 3: pilot one representative site

Pick a site with every device class you own: Windows, macOS, iOS, Android, scanners and anything unusual. Avoid your flagship site and your simplest one. Cut it over with the same steps you will use in the waves.

Hold it for five working days. Compare Purple's success rate with the ISE baseline for that site. Check that every device class lands on the right VLAN. Fix anything that fails here, not in a wave.

Phase 4: cut over in waves

Group the remaining sites into waves that one team can support in a single change window. Run the go or no-go check before each wave. Follow the same steps at every site.

{"title":"Cut over one site from ISE to Purple cloud RADIUS","steps":[{"title":"Record the baseline","body":"Note the site's ISE authentications per hour and success rate per SSID in the migration log.","check":"Baseline figures are logged before the window opens."},{"title":"Point the secure SSID at Purple","body":"Replace the ISE RADIUS servers with Purple's servers and shared secret. Keep the ISE entries written down for rollback.","check":"The dashboard shows Purple as the RADIUS server for this SSID.","variants":[{"label":"Cisco Meraki","body":"In Meraki Dashboard, edit the SSID access control settings and update the RADIUS server list."},{"label":"HPE Aruba","body":"In Aruba Central or the controller, update the server group used by the WLAN 802.1X profile."},{"label":"Ruckus","body":"In RUCKUS One or SmartZone, update the AAA server assigned to the WLAN."},{"label":"Juniper Mist","body":"In the Mist dashboard, edit the WLAN enterprise security settings and update the RADIUS servers."},{"label":"Ubiquiti UniFi","body":"In UniFi Network, update the RADIUS profile used by the enterprise SSID."}]},{"title":"Reconnect probe devices","body":"Reconnect one device of each class at the site, including headless devices on xPSK.","check":"Each probe device lands on its expected VLAN."},{"title":"Watch the first hour","body":"Read Purple's authentication logs and group failures by reason.","check":"Success rate is at or above the site baseline."},{"title":"Hold or roll back","body":"If the rate stays below baseline at the end of the agreed window, restore the ISE servers on the SSID.","check":"The decision and the reason are in the migration log."},{"title":"Close the site","body":"Mark the site migrated after 48 hours. Keep its NAD entry in ISE until phase 5 so rollback still works.","check":"ISE shows no new authentications from this site."}]}

Phase 5: decommission ISE

Start phase 5 only when ISE has seen zero WiFi authentications for a period you set, such as 30 days. Export the ISE authentication reports your audit retention policy requires. Remove the NAD entries, then power the nodes down. Let the licences lapse at renewal rather than cancelling early.

Retire the ISE internal CA last. Any certificate it issued stops chaining to a live CA once ISE is gone.

How do ISE and Purple run side by side during cutover?

There are two patterns, and they behave differently.

Parallel SSID. Broadcast a second secure SSID authenticated by Purple alongside the ISE SSID. Your MDM moves device groups to the new SSID profile in batches. Both networks run at once, so this is true side-by-side running. The cost is airtime from one more SSID for the length of the migration.

Same SSID, switched server. Keep one SSID and change its RADIUS server during the change window. This is cleaner on air, but it is a switch, not a blend.

The point most teams miss: RADIUS failover on most controllers triggers when the primary server stops responding, not when it rejects a device. If you list Purple first and ISE second, a reject from Purple does not fall back to ISE. Do not rely on server order as a safety net. Rely on the pilot.

Worked scenario: a 40-hotel group on Cisco Meraki

A hotel group runs Staff WiFi across 40 hotels on Cisco Meraki. Two ISE nodes in a data centre authenticate staff with PEAP against on-premise Active Directory. The group wants to retire the data centre.

The team split the move in two. First, it pushed EAP-TLS certificates and Purple server trust through its MDM while ISE still authenticated everything. ISE validated the new certificates, so nothing changed for staff. Second, it piloted one mid-sized hotel, then moved the rest in four weekend waves of nine or ten hotels.

The measurable outcome was the exit test itself. ISE's staff SSID authentication count reached zero after the last wave. No wave needed rollback. The ISE nodes were powered down at the end of the following month.

How do you roll back a wave that fails?

Rollback is the reverse of step two: restore the ISE servers and shared secret on the affected SSIDs. Because ISE stays live and its NAD entries stay in place, the site returns to its previous state at the next reconnect. Agree in advance who makes the call and how long you wait before making it.

{"title":"Go, no-go or roll back for a cutover wave","start":"q1","nodes":[{"id":"q1","question":"Did the pilot or the previous wave hold the ISE success-rate baseline?","help":"Compare Purple's success rate per SSID with the ISE baseline for the same sites.","options":[{"label":"Yes","to":"q2"},{"label":"No","to":"o3"}]},{"id":"q2","question":"Does every device in this wave trust Purple's server certificate?","help":"Check MDM deployment status for every device group at these sites.","options":[{"label":"Yes","to":"q3"},{"label":"No","to":"o2"}]},{"id":"q3","question":"Can every site in the wave reach Purple's RADIUS servers?","help":"Test through each site firewall before the window opens.","options":[{"label":"Yes","to":"q4"},{"label":"No","to":"o2"}]},{"id":"q4","question":"Is ISE still live, with a named rollback owner on call?","options":[{"label":"Yes","to":"o1"},{"label":"No","to":"o2"}]},{"id":"o1","outcome":"Go","detail":"Open the change window and follow the site cutover steps."},{"id":"o2","outcome":"No-go: fix and reschedule","detail":"Close the gap, then rerun this check before the next window."},{"id":"o3","outcome":"Roll back and diagnose","detail":"Restore ISE on the affected SSIDs, find the failing device class or rule, and fix it at the pilot site first.","link":"[Compare ISE alternatives](guide:cisco-ise-alternatives)"}]}

Worked scenario: a 300-store retailer on HPE Aruba

A retailer runs 300 stores on HPE Aruba. ISE authenticates staff laptops with EAP-TLS and handheld stock scanners with MAB. The pilot store passed, so the team moved the first wave of 30 stores.

Scanners failed at four stores in the second wave. Those stores had a newer scanner model whose MAC addresses had never reached the phase 1 inventory. The rollback owner restored the ISE server group on the affected WLANs within the change window, and scanning resumed.

The team pulled the new model's addresses from ISE's endpoint list and issued it xPSK keys. It tested one scanner at the pilot store, then reran the wave. All 300 stores finished on Purple. Every MAB rule was retired, and card terminals now sit on their own VLAN. That segmentation became evidence for the retailer's PCI DSS scoping.

How do you prove the migration from ISE is finished?

"Finished" is a set of facts, not a feeling. You are done when all of these are true:

• ISE has logged zero WiFi authentications for the period you set.
• Purple's success rate at every site is at or above its ISE baseline.
• Every identity group lands on its intended VLAN, checked with a probe device per class.
• No device holds a certificate that chains to the ISE internal CA.
• ISE reports for your retention period are exported and stored.
• The ISE nodes are powered down and the renewal is cancelled.

Keep one log for the whole programme. The checklist below is that log.

{"title":"ISE to cloud RADIUS migration log","groups":[{"heading":"Before phase 1","items":[{"text":"Every SSID, NAD and shared secret listed"},{"text":"Every policy set mapped to an identity group and VLAN"},{"text":"Two weeks of ISE baseline captured per site and SSID","why":"Without it, no wave can pass or fail"},{"text":"PEAP devices identified and an EAP-TLS plan agreed"},{"text":"MAB devices listed from the ISE endpoint list"},{"text":"Wired, TACACS+ and posture scope given separate owners"}]},{"heading":"Build and pilot","items":[{"text":"Identity provider connected and groups mapped to VLANs"},{"text":"Client certificate CA trusted for EAP-TLS"},{"text":"Purple server certificate trust pushed through MDM","why":"The risk that bites on cutover night"},{"text":"xPSK keys issued for headless device groups"},{"text":"Site firewalls allow RADIUS traffic to Purple"},{"text":"Pilot site held baseline for five working days"}]},{"heading":"Waves","items":[{"text":"Go or no-go check recorded for each wave"},{"text":"Rollback owner named for each window"},{"text":"Each wave held baseline for 48 hours"}]},{"heading":"Finished","items":[{"text":"Zero ISE WiFi authentications for the agreed period"},{"text":"No certificates chain to the ISE internal CA"},{"text":"ISE reports exported for audit retention"},{"text":"NAD entries removed and ISE nodes powered down"},{"text":"ISE licence renewal cancelled"}]}],"download":{"filename":"ise-migration-log.csv"}}

Which failure modes show up in the field?

Most failed waves trace back to a short list of causes.

• Untrusted server certificate. Devices prompt or silently refuse to join. Fix it in phase 2 through your MDM, never by asking staff to accept a prompt.
• Changing two things at once. Moving from PEAP to EAP-TLS in the same window as the server change hides which change broke what.
• Forgotten headless devices. Scanners, printers and sensors on MAB fail first, as the retailer found. Rebuild the MAB list from ISE just before each wave.
• Shared secret mismatches. One mistyped secret on one controller rejects a whole site. Copy secrets from one source, never by hand.
• Firewall egress. Sites with local breakout or older firewall rules block RADIUS traffic to the cloud. Test each site before its window.
• VLAN attribute differences. ISE authorisation profiles may return a VLAN name, a VLAN ID or a vendor-specific role. Match what each controller expects at the pilot site.
• Silent downstream consumers. If a firewall learned identities from ISE through pxGrid, that feed stops at cutover. If you rely on Change of Authorisation (RFC 5176) to end sessions, test it during the pilot.
• Relying on failover. Listing ISE as the secondary server does not catch rejects. Only a tested rollback does.

Where Purple fits

Purple Access runs three networks on the access points you already own: open, secure and xPSK. An ISE migration lands on the secure network. Purple cloud RADIUS authenticates with EAP-TLS against Microsoft Entra ID, Okta or Google Workspace. Passpoint, the Hotspot 2.0 standard for automatic and encrypted joining, extends the same identity across sites. Identity sets the VLAN on every network.

Purple is hardware-agnostic. It works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet, with no new hardware. Purple runs the largest cloud RADIUS in the world. It carries a 99.9% RADIUS uptime SLA on a platform that runs at 99.999% uptime.

{"items":[{"value":"99.9%","label":"RADIUS uptime SLA","note":"Purple's contractual SLA"},{"value":"99.999%","label":"platform uptime","note":"Purple's own data"},{"value":"80,000+","label":"live venues","note":"Purple's own data"},{"value":"90","label":"countries","note":"Purple's own data"}]}

{"tone":"proof","title":"Staff WiFi at branch scale","text":"JPMorgan runs Staff WiFi on Purple across 5,000 branches."}

Purple holds ISO 27001, Cyber Essentials and B Corp certification, and operates under GDPR and CCPA. Those certifications shorten the supplier assessment your security team will run. For the wider security picture, read the enterprise WiFi security guide. If you are still choosing a destination, see Cisco ISE alternatives for WiFi authentication.

Frequently asked questions

How long does it take to migrate from Cisco ISE to cloud RADIUS?

The cutover itself is usually a weekend exercise; the preparation takes longer. For a 40-site estate, plan two weeks of discovery, a week of build, a two-week pilot and several weekend waves. Certificates are the biggest variable. If devices already use EAP-TLS with certificates from your own CA, the plan shortens. If PEAP against Active Directory is in play, add a phase to move those devices to EAP-TLS first.

Do I need new access points to move off Cisco ISE?

No. Cloud RADIUS works with the access points and controllers you already run: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. The move is a configuration change on each SSID: new RADIUS server addresses, a new shared secret and, where needed, new VLAN attributes. Your switching, VLANs and SSIDs stay exactly as they are.

Can we keep the client certificates we already issue?

Yes, if your own CA or MDM issued them. Cloud RADIUS validates EAP-TLS certificates against the issuing CA, so they keep working once that CA is trusted. Certificates from the ISE internal CA are the exception. They chain to a system you are about to retire, so reissue them from your MDM or CA before phase 5 begins.

What happens to devices that use MAC Authentication Bypass in ISE?

They move to the xPSK network. MAB trusts a MAC address, which is easy to spoof. A key per device or device group gives scanners, printers and sensors their own credential and lands them on their own VLAN. Find them in phase 1 from ISE's endpoint list. Issue keys in phase 2, then test one of each model at the pilot site.

Does moving off ISE affect our PCI DSS or ISO 27001 evidence?

It changes where the evidence comes from, not whether you have it. Export ISE authentication reports for your retention period before decommission. From cutover onwards, Purple's authentication logs and VLAN assignments provide evidence for network segmentation and access control. Purple's own ISO 27001 and Cyber Essentials certification also supports the supplier assessment your auditors will expect to see.

How does cloud RADIUS pricing compare with Cisco ISE?

Compare total cost rather than licence lines. ISE cost includes licences, the nodes or virtual machines that run it, support contracts and engineer time spent patching and upgrading. Cloud RADIUS is a subscription with no servers for you to run. Purple quotes for your estate, so bring your site count, SSIDs and device numbers. The ISE alternatives guide sets out what else to compare.

Should we move wired 802.1X at the same time as WiFi?

No. Move WiFi first and treat wired 802.1X as a separate project with its own pilot. Wired ports often carry MAB devices, desk phones and posture rules that need their own inventory. Changing both in one window doubles the number of things that can fail at once. It also makes the rollback decision harder to call under pressure.

Is migrating from Aruba ClearPass any different?

The five phases are the same; the export differs. ClearPass stores policy as services, enforcement policies and profiles rather than ISE policy sets. Mapping those to identity groups and VLANs is the main phase 1 task. The certificate trust risk and the failover behaviour apply in exactly the same way. The ClearPass migration guide covers the export in detail.