A WPA2-PSK municipal kiosk AP shows no associated clients overnight, and the rules of engagement forbid deauthentication. Why might handshake-based recovery be blocked until later?
Select an answer to reveal the explanation.
Short Explanation
No clients means no dance to record—if deauth is off-limits, you wait for someone to reconnect. Beacons keep advertising; they do not hand you a finished 4-way. Come back when the kiosks wake up.
Full Explanation
If a WPA2-PSK municipal kiosk AP shows no associated clients overnight and RoE forbids deauthentication, handshake-based recovery may be blocked until stations return: without clients—and without allowed traffic-forcing—complete handshake material may be unavailable. Civic scheduling should plan daytime reconnect windows rather than violating RoE. Beacons alone do not finish the offline Personal prerequisite.
'PSK networks never produce handshakes even when clients roam in at opening time' fails because PSK networks do produce handshakes when clients roam in—they are not permanently handshake-less. 'Overnight silence permanently retires the PMK so future clients cannot authenticate' fails because overnight silence does not permanently retire the PMK so future clients cannot authenticate. 'Beacon frames alone always substitute for handshakes when the AP is clientless' fails because beacon frames alone do not always substitute for handshakes when the AP is clientless.
Exam caveat: no-clients plus no-deauth is a collection constraint, not proof the PSK is strong. Operational check: schedule authorized client joins during business hours, keep the capture running on the kiosk BSSID, verify EAPOL completeness when devices return, and note RoE limits in the municipal timeline. In municipal wireless operations, record the rationale in the engagement notes so future assessors know which control or technique class was chosen and which failure modes the rejected options would create for city services.