A procurement RFP for civic APs says only 'AES encryption' without specifying WPA2 versus WPA3. What should security reviewers demand?
Select an answer to reveal the explanation.
Short Explanation
Saying 'AES' is like ordering 'metal locks' with no brand, keyway, or door. Reviewers need WPA2 vs WPA3, Personal vs Enterprise, and PMF called out. Vague RFPs buy mystery boxes.
Full Explanation
An RFP that says only “AES encryption” without specifying WPA2 versus WPA3, Personal versus Enterprise, or PMF expectations is incomplete. Security reviewers for civic APs should demand full suite clarity so vendors cannot deliver TKIP-tolerant WPA2-Personal when the city believed it bought high-assurance Enterprise. Cipher marketing words are not a substitute for AKM, generation, and management-frame requirements. Accepting “AES” alone because CCMP always implies WPA3-Enterprise 192-bit mode is incorrect. Replacing cipher requirements with MAC filtering language weakens the RFP. Removing AKM details so vendors can choose TKIP for compatibility invites deprecated suites. Exam caveat: Procurement language drives what assessors later find in beacons—fix ambiguity early. Operational check: Amend the RFP checklist to require explicit WPA2/WPA3, Personal/Enterprise, PMF, and forbidden TKIP/WEP clauses before award. In civic WLAN stewardship, keep authorization boundaries explicit, prefer the least disruptive technique class allowed by RoE, and record BSSID, channel, band, and security mode beside every conclusion so another assessor can reproduce the observation. In civic WLAN stewardship, keep authorization boundaries explicit, prefer the least disruptive technique class allowed by RoE, and record BSSID, channel, band, and security mode beside every conclusion so another assessor can reproduce the observation.