This guide is written for organizations that manage Wi-Fi network credentials manually in ManageXR. A credential update is possible with no user interruption as long as the change is coordinated between ManageXR and your network team. This applies whether you are updating a CA cert, an auth cert, an identity, domain, or any combination of those across WPA2-Enterprise and WPA3-Enterprise networks.
The network details that change during a migration can vary greatly between organizations or even different geographic locations under the same deployment umbrella. This guide uses certificates and connection details (domain, identity, password, etc.) as a catch-all for whatever your network requires. The admin(s) overseeing the migration should have working knowledge of their organization's RADIUS server configuration and Public Key Infrastructure (PKI). If your network team or a third party manages those components, walk through your chosen approach with them before making any changes.
What to Confirm with Your IT Team
Before starting a migration, confirm the following with your network team:
What is changing and why? Confirm which certificates and connection details the migration affects: the CA certificate, authentication certificate, other connection fields (domain, identity, etc.), SSID, or a combination. This helps determine which option applies.
Is it fleet-wide or rolling?
Can your RADIUS server run an overlap window? Confirm it can be configured to accept both the old and new credentials at the same time. This is generally feasible but must be verified against your specific RADIUS setup.
What is the timeline for the network changes? This ensures the overlap window is open at each site before you push updated credentials, and that it stays open long enough for all devices to sync after changes are made.
Migration Options
There are several ways to update certificates and connection details without interrupting users. Which one fits depends on what is changing and whether you have a fallback network. The options below are listed below, and ManageXR support can help you identify which is easiest or most common for your situation.
Tip: Validate any network change on a single or small number of devices before rolling it out. A failed swap can leave devices unable to remotely connect to any network and typically requires manual connection from within the headset.
Option 1: Use a fallback or provisioning network (Easiest)
Using a provisioning network (a guest network, a low-security network, or a hotspot) is the simplest option because the device always has a path to reach ManageXR and pull a new profile or changes to an existing profile. Some organizations do not have a viable fallback network at every site, for example where a guest network relies on per-user captive portal access that is not always active, or one simply doesn't exist because of IT security restrictions. If that is your situation, see Options 3 and 4.
If you have a provisioning network available, devices can connect to it, receive the updated credentials, then transition back to the enterprise network once the new certificate is valid. In practice this would look like:
Create a Wi-Fi network profile for your provisioning network
Assign the provisioning network to your configuration, alongside your existing enterprise network profile.
Verify that your device(s) can connect using the provisioning network as a fallback.
Assign the deployment and provisioning networks to the same configuration.
Ensure your devices’ sync status in ManageXR is “Up To Date.”
Verify that your device(s) are now connected using the intended Wi-Fi network for your deployment.
(Optional) If not, you can change your configuration settings to Always connect if available to your enterprise network.
(Optional) Remove the provisioning network from the configuration.
A common safety practice is to not remove the provisioning network from your devices so you have a fallback network in case there's an issue with your enterprise network. The problem then is that your devices may bounce between your provisioning and enterprise network. To prevent this, you can set your configuration to force-connect to your enterprise network. Instructions here.
Option 2: Open a RADIUS overlap window, then update the profile in place (Industry standard)
When the SSID must stay the same and there is no fallback network, configure an overlap window on the RADIUS server so that your RADIUS server accepts both the legacy and the new credentials at the same time during a defined migration window (RADIUS servers can support trusting multiple identities and multiple auth certificates simultaneously). Once the overlap window is open, update the existing Wi-Fi profile in ManageXR with the new certificates and connection details. Devices pull the updated profile and reconnect over the same SSID. After your fleet has fully migrated, your IT team removes the legacy credential acceptance from the RADIUS server and closes the overlap window.
This is the standard approach for credential migrations because there is never a moment when a device holds credentials the network will not accept. With large fleets, it's not uncommon for batches of devices to remain powered off for long periods of time. An overlap window gives flexibility for devices to migrate over time, and is especially useful for a one-time, fleet-wide change, such as a CA certificate update that applies to every site at once.
Option 3: Create and deploy a new SSID alongside the old one (Situational)
If the migration includes a new SSID, the new network can be deployed alongside the old one, since different SSIDs do not conflict. Devices stay on the old network until the new one is available, then transition to the new SSID. This option applies only if your network team is able to stand up a new SSID as part of the change. Step-by-step:
Assign the new SSID network to your desired configuration.
Ensure all of your devices’ sync status in ManageXR is “Up To Date.”
Verify that your device(s) are now connected using the new SSID.
Change your configuration settings to Always connect if available to your new SSID.
Ensure all of your devices’ sync status in ManageXR is “Up To Date.”
Remove the old enterprise network/SSID from your configuration.
![ManageXR - 18 June 2026.mp4 [video-to-gif output image]](https://downloads.intercomcdn.com/i/o/xjloufys/2486434004/81e09d107339f23dfabf44be2774/ezgif-7e089b6dc8c5c597.gif?expires=1783101600&signature=f659857aabfde7b657bbc5b0f656a255c6194d15190bc487f077a361e7376a07&req=diQvEM19mYFfXfMW3nq%2BgQD2t2xQnSrpicIqMO89UI%2Bdg%2BsImbXURbpLYDlW%0AnmGAFnXFgiR1lTThRpSKp6qCvcg%3D%0A)
Option 4: Hot-swap an OLD and NEW profile per configuration (Situational/Site-specific)
For rolling changes that happen site-by-site, such as a bandwidth upgrade that requires new authentication certificates and/or RADIUS server details that are specific to each site, maintain two versions of the Wi-Fi profile in ManageXR, an OLD version and a NEW version, and swap them per configuration as each site is ready.
When a site's network is ready to accept the new credentials, update that site's configuration to remove the OLD profile and add the NEW profile at the same time. ManageXR handles the underlying process of uninstalling the old profile and installing the new one without interruption to connectivity. The device updates over its existing managed connection, so there is no need to drop to an unmanaged network.
Important: Timing is critical! Do not push the updated profile to a site until that site's network is ready to accept the new credentials. If the new profile is deployed before the network accepts it, or the network changes before the new profile is deployed, the device either cannot connect initially or cannot reconnect after the update. During the transition, the network must accept both the old and new credentials.
FAQs
Why can't I deploy two Wi-Fi profiles with the same SSID to one configuration?
Why can't I deploy two Wi-Fi profiles with the same SSID to one configuration?
You can't deploy two Wi-Fi network profiles with the same SSID to a single ManageXR configuration because device operating systems do not allow it. This applies to any WPA2-Enterprise or WPA3-Enterprise network regardless of the authentication method in use.
A device's built-in Wi-Fi client ties one set of credentials to each SSID, and the OS doesn't allow MDMs to supply two competing credential sets for the same SSID. If two profiles existed at once, the device would have no way to determine which to present to the network. This causes failed authentication or a connection that bounces between profiles.
This constraint applies to every device type: phones, tablets, laptops, and XR headsets. ManageXR blocks this to prevent aforementioned connectivity failures on devices. Because two same-SSID profiles cannot run side by side, a seamless migration requires a different approach. The sections above cover your available options.