Plan an ISE guest replacement with Cloudi-Fi while retaining 802.1X and TACACS+. Check service boundaries, run a pilot and plan the rollout.
ISE guest replacement can focus on visitor access while Cisco Identity Services Engine (ISE) continues to handle corporate device authentication and network administration. Cloudi-Fi manages the guest portal and login process. The existing wireless network and security tools still control where guests can connect.
Moving guest access to Cloudi-Fi gives IT teams a centrally managed portal to standardize visitor onboarding and branding across supported wireless environments. The organization can improve the guest experience while retaining its existing ISE services for corporate authentication and network administration.
In this article
- Focus the project on guest access
- Separate the three access services
- Check the current guest configuration
- Start with a small pilot
- Test guests and the services that remain
- Expand only after the pilot passes
- Measure the migration results
Focus the project on guest access
An enterprise planning discussion illustrates this approach. The organization wanted to move its guest portal from ISE to Cloudi-Fi while keeping ISE for corporate devices and network administrators. The proposed migration therefore focused on guest access.
The team could evaluate guest onboarding and portal management as a separate project. Before making changes, it needed to identify which settings also supported other ISE services.
Figure 1. Target service boundaries for a guest access migration. Authentication exchanges and internet traffic follow separate logical paths.
Separate the three access services
The design separates three services. Visitors use the guest portal, corporate devices use their existing authentication process, and administrators use their existing access to network equipment.
Visitors connect through Cloudi-Fi Captive Portal. Corporate devices continue to authenticate through ISE using 802.1X. Network administrators keep using TACACS+ for device access and activity logging, as described in Cisco’s device administration documentation.
Existing access points and controllers can remain if they support the required integration. Some settings may be shared with other services. The team should check those settings before changing guest access.
Check the current guest configuration
Record the guest network name, its authentication, authorization, and accounting (AAA) settings, and how visitors reach the portal. Include the portal address, certificates, and rules that allow access before login. This provides a reference for the migration and any rollback.
Check how guest traffic reaches the internet and where security rules apply. The setup can differ between branches and central sites. Cloudi-Fi provides Cisco Catalyst 9800 guides for local switching and central switching.
The team should answer four questions before the pilot.
- Which settings apply only to guests?
- Which settings also support corporate devices or network administrators?
- Which network component applies the guest access rules?
- How can the team restore the previous guest service if a test fails?
For example, changing a shared controller setting can affect more than guest access. The team should identify these effects and any required access point restarts before scheduling the change.
Start with a small pilot
Choose a pilot site that reflects the network being migrated. If sites use different wireless platforms or traffic paths, test each main setup before a wider rollout.
Agree how visitors will connect, whether through reception, a sponsor, or self-registration. Define how long access lasts and what information support needs to find a guest session.
Configure the pilot using the relevant Cloudi-Fi integration guide. Check that visitors can reach the portal, complete the login process, and receive the intended access. The guide provides the platform-specific settings.
A temporary guest network can help keep the pilot separate and make rollback easier. Set an end date for parallel operation so the temporary service does not remain in place indefinitely.
Test guests and the services that remain
A working login page is only part of the test. Confirm that guests receive the right access and that the retained ISE services still work.
- A visitor reaches the portal and completes the chosen login process.
- Support can find the session with the expected identity, site, and policy.
- The visitor can use permitted internet services but cannot reach protected internal resources.
- Access expires and the next connection follows the guest policy.
- A corporate device still authenticates through ISE using 802.1X.
- A network administrator can still sign in through TACACS+, with the correct permissions and activity logs.
Record the device, site, time, and result for each test. Check both allowed access and access that should be blocked. These records help support investigate any failure.
Expand only after the pilot passes
Assign an owner and a rollback plan to each rollout stage. If a test fails, restore the previous guest configuration and investigate. Pause the rollout if corporate authentication or administrator access changes unexpectedly.
Keep the old ISE guest configuration for the agreed rollback period. Remove it only after the new service works and the team confirms that other services no longer depend on it.
If ISE is also moving to a new hosting environment, track that change separately. Separate tests and change records make problems easier to trace.
Measure the migration results
The goal is a consistent guest experience across sites, with sessions that support can trace. Corporate devices and network administrators continue to use ISE. The pilot should confirm these outcomes before the rollout expands.
Track completed guest logins, support requests, and sites migrated without rollback.
Explore the Cloudi-Fi integration with Cisco wireless controllers to plan a guest access migration for an existing Cisco environment.