A city wants to keep push-button WPS available only when an admin is physically present. How should an OSWP-style assessment view that control?
Select an answer to reveal the explanation.
Short Explanation
Babysitting the WPS button is better than leaving it on 24/7—but the grown-up move is still off. If nobody needs WPS, kill the feature. Supervision is a compromise, not a force field.
Full Explanation
From an OSWP-style assessment viewpoint, keeping push-button WPS available only when an administrator is physically present is a useful operational control that shrinks the exposure window compared with always-on WPS, yet it does not eliminate the WPS attack-surface class and does not equal certificate-based Enterprise authentication. Disabling WPS entirely remains the safest posture when the feature is unused for business operations. Push-button WPS is not immune to all attack classes, so supervision is not pointless theater for civic WLAN hygiene. Admin presence does not convert WPS into EAP-TLS or otherwise upgrade the cryptographic model. Supervised WPS does not require RF jamming to be considered relatively safer; jamming is a separate, typically unlawful denial technique. Exam caveat: time-boxed WPS reduces opportunity but residual risk remains whenever the feature can be enabled on municipal access points. Operational check: document civic procedures for supervised WPS including who may enable it, maximum duration, and verification of disablement afterward, and recommend permanent disablement on APs that never need it. For municipal and campus engagements, keep the finding language tied to authorized scope, name the building or SSID class affected, and state the residual risk to residents or staff if the rejected option had been chosen. Re-validate after the next change window that the selected control still matches inventory, monitoring, and RoE abort criteria used by the city wireless program.