Municipal policy requires WPA3, but an SSID still allows TKIP. What mitigation best addresses that finding?
Select an answer to reveal the explanation.
Short Explanation
Policy says WPA3; the SSID still speaks TKIP—that is a config fix, not a poster project. Turn off the deprecated cipher and make the air match the written rule.
Full Explanation
When municipal policy requires WPA3 but an SSID still allows TKIP, the mitigation that best addresses the finding is adjusting the WLAN configuration so the SSID conforms to security policy by removing TKIP and enforcing approved cipher suites. Configuration conformance is the direct fix for policy drift on cipher negotiation and prevents clients from selecting a deprecated suite. Leaving TKIP enabled and adding a longer captive-portal disclaimer does not remove the weak cipher and may create a false sense of compliance. Printing the policy on posters near the APs without changing controller settings leaves the vulnerable negotiation path active for every association. Lowering AP transmit power so TKIP becomes an "acceptable compensating control" misunderstands compensating controls—RF power does not remediate weak cryptography. Civic auditors typically treat lingering TKIP on a WPA3-requiring SSID as a clear, configuration-level remediation item. Exam caveat: if a legacy client still needs weak ciphers, isolate it on an exception SSID with ownership, monitoring, and a sunset date rather than weakening the primary staff SSID. Operational check: inspect the SSID's allowed cipher list in the controller, remove TKIP and other legacy suites, validate staff clients still connect with approved WPA2/WPA3 ciphers, monitor for association failures from forgotten legacy devices, and retain a configuration-diff screenshot for audit evidence.