A regional insurer lets each employee register up to three personal devices through the BYOD portal and remove their own devices through that same portal instead of a service ticket. When a device is lost or reassigned, revoking it must cut access right away, and that device must re-enroll before it returns. Which BYOD lifecycle design satisfies both the device limit and the revocation flow?
Select an answer to reveal the explanation.
Short Explanation
You covered both halves here: the enrollment cap and a genuine revoke. Deleting the registration is what forces the device through setup again, like cancelling a hotel key card so the next swipe fails. It's the cap that keeps the portal manageable.
Full Explanation
ISE tracks the devices each user has registered in the BYOD portal, so your design can check that count before another enrollment is accepted, and it keeps a registration record for every device the user owns. Revocation only does its job when that record goes away, because the device then loses its standing at once and must run the enrollment flow again before it reaches resources. Parking the device in a blocked endpoint group cuts access now but preserves the record, so it can be restored without onboarding again and the re-enrollment requirement stays unmet. Dropping the per-user cap lets one account fill the portal with devices nobody can audit, which defeats the stated limit. Requiring an administrator to delete the record removes the self-service path and leaves the employee waiting on a ticket. Exam caveat: the portal wording and the exact place a device cap is configured move between ISE versions, so keep the concept of a per-user cap rather than a memorized number. Practical check: register devices up to the cap, revoke one from the portal, and confirm the device must enroll again before it reaches the network.