A vendor proposes enabling TKIP “for compatibility” on a brand-new municipal public-safety WLAN. Which encryption decision aligns with current security design practice?
Select an answer to reveal the explanation.
Short Explanation
TKIP was the duct-tape era after WEP—fine history lesson, bad choice for a fresh public-safety build. New designs should land on CCMP or GCMP with AES. Compatibility nostalgia is not a security architecture.
Full Explanation
For a brand-new municipal public-safety WLAN, current practice is to reject TKIP and select modern AES-based encryption such as CCMP or GCMP. TKIP was an interim integrity solution for the WPA era and is inappropriate as the encryption foundation of a greenfield civic safety network where confidentiality and integrity requirements for first-responder traffic are high. Vendor “compatibility” arguments do not override cryptographic retirement of TKIP when the design is new and the client fleet can be specified. Mandating TKIP-only because it is supposedly newer than WPA3 reverses chronology and standards guidance. Combining WEP and TKIP as a high-availability cipher pair stacks two deprecated mechanisms instead of providing resilience. Using TKIP for management frames while leaving data frames unencrypted fails both management-frame protection concepts and data confidentiality for the BSS. Exam caveat: rare legacy endpoints may force a temporary isolated SSID, but that exception must be segmented, monitored, and time-boxed—not used to justify TKIP on the primary public-safety profile. Operational check: in the RFQ and controller baseline, list allowed pairwise ciphers as CCMP and/or GCMP only, then scan production beacons to ensure TKIP bits are absent from the public-safety SSID advertisement before go-live.