A distribution centre is adding ISE-based BYOD to its wireless network, but the site broadcasts a single SSID: 200 handheld scanners were provisioned with that exact profile and the reconfiguration window has closed. Staff must still earn a client certificate before they reach the inventory VLAN, so first-time users need a guided onboarding path. Which BYOD flow fits this one-SSID deployment?
Select an answer to reveal the explanation.
Short Explanation
The single-SSID flow is built for exactly this squeeze: one broadcast name that still runs a full portal handoff. A device joins, installs its profile, and then comes back as a certificate-bearing client on that same SSID. Your handhelds don't need a second network.
Full Explanation
The single-SSID flow keeps onboarding and normal access on one broadcast name by splitting the two audiences with policy. A first-time device joins the SSID, ISE authenticates it with the user's directory credentials, redirects the browser to the BYOD portal, and client provisioning configures a native supplicant profile to use a certificate issued to the device. The device's private key is generated and stored on the device. After a change of authorization, the device reconnects on that same SSID as an EAP-TLS client, at which point your authorization rules place it in the inventory VLAN. Devices that already hold credentials, such as your handhelds, skip the portal and authenticate normally, so one broadcast serves both groups. A second BYOD SSID is the classic alternative and the easiest design to explain, but it breaks the single-broadcast constraint you cannot reopen. MAC-based authorization keeps existing hardware online with no portal at all, yet it mints no certificate, so first-time staff never gain the credential the requirement demands. Sending everyone through the shared guest portal delivers web authentication and can gate on posture, but a guest session carries no enterprise credential and posture scores health rather than identity. Exam caveat: single-SSID onboarding depends on a working redirect ACL and a portal the client can reach, or the page never loads. Practical check: onboard a clean device end to end, then confirm in Live Logs that its second connection used EAP-TLS.