A coworker proposes enabling Shared Key Authentication on a municipal AP 'for compatibility with ancient scanners.' What should the technician do?
Select an answer to reveal the explanation.
Short Explanation
Shared Key Authentication is a museum piece that leaks enough to help attackers, not a compatibility gift. Refuse it even when someone waves an ancient scanner around. Compatibility pain gets solved with modern profiles or device upgrades—not 1999 crypto theater.
Full Explanation
When a coworker proposes enabling Shared Key Authentication on a municipal AP for compatibility with ancient scanners, the technician must refuse because Shared Key Authentication is legacy insecure practice. It exposes key material patterns historically tied to WEP-era weaknesses and is not an acceptable compatibility bridge for city WLAN. Open System with modern WPA2/WPA3 suites is the supported path; Shared Key is not a CWTS-approved shortcut.
Enabling Shared Key and disabling Open System everywhere hardens the wrong thing and reintroduces legacy risk. Enabling Shared Key only when combined with MAC filtering stacks two weak controls. Using Shared Key Authentication as a replacement for WPA3-Enterprise abandons modern Enterprise security entirely.
Exam caveat: Shared Key Authentication is refused, not conditionally embraced. Compatibility pressure does not revive legacy 802.11 auth modes on civic gear.
Operational check: leave Shared Key Authentication disabled, confirm Open System plus modern RSN/WPA2/WPA3 per design, test scanner connectivity on the approved suite, and escalate true legacy device exceptions through security design—not Shared Key. Municipal technicians document the verified setting in the as-built packet so the next shift inherits a known-good civic configuration rather than tribal knowledge.