Policy for new community-center SSIDs requires a WPA3 security baseline. Which deprecated options must the design reject as AKM/cipher choices under that baseline?
Select an answer to reveal the explanation.
Short Explanation
WPA3’s baseline is basically no museum crypto on the community-center SSID. If someone tries to sneak WEP or TKIP back in, the answer is no—keep SAE and modern ciphers, not the 1990s leftovers.
Full Explanation
Policy requiring a WPA3 security baseline for new community-center SSIDs must reject WEP and TKIP—and legacy WPA patterns that depend on them—as allowable AKM or cipher choices. Those mechanisms are the museum cryptography the baseline exists to exclude from civic guest and staff networks alike. Community-center designs should land on modern Personal or Enterprise AKMs and AES-based pairwise protection appropriate to WPA3-era guidance, not reopen transitional integrity wrappers or broken stream-cipher history under a “temporary compatibility” excuse. SAE for Personal mode and GCMP for pairwise protection on capable APs align with modern baselines and are not deprecated options to reject. 802.1X with EAP-TLS on WPA3-Enterprise staff SSIDs is desirable for identity-bound access, not forbidden by a WPA3 baseline. OWE on a separate open guest SSID that still needs encryption is a contemporary open-network control, not a deprecated cipher to ban when drafting new community-center profiles. Exam caveat: a WPA3 baseline on paper fails if controller templates still permit TKIP mixed mode for “just a few” kiosks—audit the live RSN IE, not only the policy PDF presented to council. Operational check: create a new community-center SSID from the approved template, capture its beacon, and fail the change ticket if WEP or TKIP appears anywhere in the advertised suites or fallback profiles.