A wash-class scan shows WPS version and manufacturer metadata on a city AP. What is the correct interpretation before claiming a finding?
Select an answer to reveal the explanation.
Short Explanation
Seeing the nameplate is not the same as picking the lock. WPS version and vendor info help you triage—then you still have to prove the weak class. Do not write "owned" on fingerprint alone.
Full Explanation
Wash-class or survey output showing WPS version and manufacturer metadata on a city AP is inventory and prioritization evidence, not automatic proof of exploitability. Metadata helps assessors flag likely weak implementations and plan authorized validation, but vulnerability classes still require confirmation within RoE before a report claims a successful exploit path. Manufacturer strings do not prove a pixie-class exploit already occurred during the survey pass. A WPS version field does not mean the PSK is public knowledge or already recovered. Fingerprint data should not be omitted solely as valueless—it is useful context when framed accurately for civic asset owners. Exam caveat: distinguish discovery indicators from validated findings to avoid overclaiming in municipal reports that executives will read. Operational check: record WPS metadata in asset notes, attempt only authorized validation steps next, and write the finding as suspected or prioritized until exploitability or passphrase impact is demonstrated. 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.