A city uses a unique 20-character random PSK on a staff IoT SSID. What residual risk class remains even when offline guessing looks impractical?
Select an answer to reveal the explanation.
Short Explanation
A long random PSK is a tough lock, but it is still one spare key hanging on a shared hook. Staff, vendors, and sticky notes can still spread it, and rotation still matters. Offline toughness is not the same as perfect Personal-network hygiene.
Full Explanation
A unique 20-character random PSK on a staff IoT SSID strongly resists practical offline guessing in typical assessment timeboxes, yet shared-PSK operational risks remain: the same secret is still copied to devices, vendors, and support staff, and rotation or compromise handling still matters. Civic risk framing should separate 'hard to dictionary-crack' from 'no longer a shared-secret problem.' Strong entropy reduces one failure mode without deleting key distribution, leakage, and reuse issues. Random long PSKs do not make monitor mode illegal or force assessments to stop; legality comes from authorization, not passphrase strength. Strong PSKs do not eliminate shared-secret operational issues such as copying the key to vendors; logistics of a single PSK persist. A 20-character PSK does not automatically upgrade the SSID to WPA3-Enterprise with per-user keys; security mode and AAA design are separate configuration choices. Exam caveat: impractical offline recovery ≠ zero wireless risk—still assess WPS, rogue attraction, physical access to labels, and inventory hygiene. Operational check: for the municipal IoT SSID, confirm random PSK policy, check whether the passphrase appears on stickers or shared tickets, review rotation procedures, and prefer Enterprise or SAE migration where devices allow. Document residual shared-PSK findings even when cracking demos are out of scope due to entropy.