A municipal SOC sees both PSK and 802.1X AKMs advertised on the same RSN-capable city SSID. How should the assessor interpret that mix?
Select an answer to reveal the explanation.
Short Explanation
Think of two doors on one building: some folks use the shared key door, others use the badge door. If both are open, weaker walk-ups can still sneak in that shared-key path. The SOC should not assume 'Enterprise-looking' equals Enterprise-only.
Full Explanation
When a municipal SSID’s RSN advertisement lists both PSK and 802.1X AKMs, different clients may negotiate different authentication paths—including weaker Personal paths if the AP still offers them. Assessors should interpret the mix as a menu of allowed AKMs, not as a requirement that every client complete both, and not as an automatic upgrade of all Personal clients to Enterprise mutual authentication. Claiming multiple AKMs always mean every client must complete both PSK and 802.1X before traffic flows misunderstands negotiation. Saying two AKMs automatically upgrade all Personal clients to Enterprise mutual authentication is false. Asserting the beacon is malformed and no client can associate until only one AKM remains contradicts common transition and mixed configurations. Exam caveat: Attack-surface selection follows the weakest offered AKM that in-scope clients will accept. Operational check: Decode the city SSID RSN IE, list each AKM, and test which path a lab client actually negotiates under authorization. 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.