Inventory shows a city IoT SSID with WPS push-button configuration (PBC) enabled. What awareness point should the assessment highlight?
Select an answer to reveal the explanation.
Short Explanation
Push-button is less 'guess the PIN from parking lot' and more 'who can reach the button.' Still watch physical access and policy—PBC is not a magic PSK shredder. Treat proximate misuse as a real story.
Full Explanation
Push-button configuration (PBC) reduces remote PIN guessing relative to a static eight-digit PIN left enabled, but it still needs physical or proximate misuse controls and policy limits. Municipal guidance should not treat PBC as risk-free: a person with brief physical access can still complete onboarding. Civic policy should define when PBC is allowed and how it is monitored.
'PBC makes online PIN brute force faster because the button transmits the full PSK in beacons' fails because PBC does not make online PIN brute force faster by transmitting the full PSK in beacons. 'Enabling PBC cryptographically deletes the WPA passphrase after each press' fails because enabling PBC does not cryptographically delete the WPA passphrase after each press. 'Push-button mode is identical in risk to leaving a static eight-digit PIN with no lockouts' fails because push-button mode is not identical in risk to leaving a static eight-digit PIN with no lockouts—but it is also not zero risk.
Exam caveat: PBC trades remote PIN spraying for proximity/physical window risk—describe both sides. Operational check: if the city keeps PBC for kiosks, restrict who can press, log activations where supported, prefer disable on staff SSIDs, and verify wash scans match intended mode. Document residual physical-access risk in the municipal report. 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.