A manufacturer wants posture on the plant WLAN. Endpoints that have yet to install the posture agent must keep limited access while they reach ISE's download portal, the assessment must actually run on the device after Secure Client installs, and ISE must re-authorize the session by CoA once the result arrives. Which posture flow sequence should be configured?
Select an answer to reveal the explanation.
Short Explanation
You've got the posture dance in the right order: limited access first, install second, then a fresh authorization once the result is in. The change of authorization is what actually moves the session between those states, like swapping a ticket at the door instead of hoping the usher notices you upgraded. Without it, the new result just sits there.
Full Explanation
Posture begins with an authorization decision rather than with the agent: unknown endpoints receive a redirect profile that keeps them on a restricted ACL while still permitting access to the ISE provisioning portal, so the user can download and install Secure Client with its posture module. Once installed, the module reports the assessment to the ISE posture service, posture policy evaluates the results, and ISE sends a RADIUS change of authorization that replaces the redirect profile with the compliant profile. Blocking admission until an agent exists defeats redirection, because the endpoint can never reach the portal that delivers the client. Leaving the original session untouched fails for the same reason a locked gate does: the posture result is known, yet without a CoA the authorization on the device never changes. Treating installation as compliance skips the assessment itself, so a device with the client installed but without the required protection still passes. Exam caveat: CoA transport and support vary by device, so verify the platform before designing around it. Practical check: run a live session and watch ISE's RADIUS live logs for the CoA request that follows the posture result.