An assessor reviewing wireless scans sees WPS states such as 'configured' versus 'not configured.' What should those flags guide?
Select an answer to reveal the explanation.
Short Explanation
Scan flags are the dashboard lights: configured, locked, on or off—they tell you if a WPS-class path is even worth discussing. They do not order a citywide SSID massacre, prove PMF status by themselves, or expand scope to the neighbor's house.
Full Explanation
Wash-scan WPS states such as configured versus not configured should guide interpretation of whether WPS is active, locked, or configured—and thus how feasible WPS-class testing is—not authorize chaos. Municipal assessors use flags for triage and reporting. Flags never authorize attacking residential neighbors on the channel.
'Immediate deletion of all municipal SSIDs that ever used guest Wi-Fi' fails because WPS flags do not call for immediate deletion of all municipal SSIDs that ever used guest Wi-Fi. 'Proof that PMF is disabled whenever any WPS flag appears' fails because a WPS flag is not proof that PMF is disabled whenever it appears. 'Authorization to attack every neighboring residential AP on the channel' fails because WPS flags do not authorize attacks on every neighboring residential AP on the channel.
Exam caveat: interpret flags → decide in-scope tests → still obey RoE. Operational check: map scan flags to AP inventory, select authorized WPS tests only where enabled and permitted, and recommend disablement. Keep a glossary of WPS state strings in the civic lab runbook. 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.