Enterprise APs at the water utility authenticate users via RADIUS, but the AP-to-AAA shared secret remains the vendor default. What is wrong with that authentication design?
Select an answer to reveal the explanation.
Short Explanation
802.1X can be picture-perfect and still trip over a default RADIUS secret—that’s the AP’s handshake with AAA. Change it, protect it. AES on the air doesn’t forgive a factory secret on the wire to RADIUS.
Full Explanation
Enterprise APs at the water utility that authenticate users via RADIUS but still use the vendor-default AP-to-AAA shared secret have an incomplete authentication design: that shared secret authenticates NAS-to-AAA communication and must be unique and protected. Defaults are not fine merely because the SSID uses AES. RADIUS shared secrets remain relevant when EAP-TLS is selected; they protect the AP–RADIUS channel, not the EAP method inside. Defaults are not required for guest portals to reuse the same secret and should never be left in production. Exam caveat: Enterprise user auth can be correct while NAS–AAA hygiene is wrong—CWSP design items often test the shared-secret hardening step candidates forget. Operational check: replace default RADIUS secrets per AP/controller with unique high-entropy values stored in the municipal secrets vault, re-test authentication, and alert on RADIUS shared-secret mismatch logs. Include secret rotation in the water utility WLAN hardening baseline. In municipal WLAN operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the infrastructure versions and client fleets used by the civic environment.