County policy requires AES-CCMP for the assessor’s office WLAN and forbids mixed TKIP/AES profiles. A controller template still offers “TKIP+AES” mixed mode. What should the designer do?
Select an answer to reveal the explanation.
Short Explanation
Mixed TKIP+AES is the halfway house policy already banned. Lock the template to AES-CCMP only and deal with stubborn clients through remediation or isolation—not by reopening the deprecated door. Cipher policy only works if the profile matches the paper.
Full Explanation
When county policy requires AES-CCMP for the assessor’s office WLAN and forbids mixed TKIP/AES profiles, the designer must enforce an AES-CCMP-only SSID profile and remediate or isolate clients that cannot comply. Mixed mode exists specifically to keep weak TKIP negotiable; leaving it enabled recreates the attack and compliance surface the written standard bans. Cipher policy is only real when the controller template, beacon advertisement, and exception process all match the paper. Keeping mixed mode so a few unscanned legacy scanners can join without review postpones risk instead of managing it through remediation VLANs, device upgrades, or a time-boxed exception SSID. Switching the SSID to WEP-104 to avoid negotiation complexity is a severe cryptographic regression. Disabling encryption entirely and compensating with a longer SSID name provides neither confidentiality nor integrity for assessor data. Exam caveat: some vendor UIs still default toward mixed compatibility profiles—CWSP candidates should treat defaults as suspect until verified against county crypto policy. Operational check: export the assessor SSID cipher configuration, confirm TKIP is disabled in both UI and CLI/API views, then attempt association with a deliberately TKIP-preferring test client to prove it is rejected or quarantined rather than silently admitted.