An assessor studies a rogue Enterprise AP concept that presents a familiar municipal SSID. What attack surface does that scenario primarily define?
Select an answer to reveal the explanation.
Short Explanation
Think of a look-alike city Wi-Fi sign that funnels staff into the wrong authentication desk. A rogue Enterprise AP with a familiar SSID is about stealing or intermediating 802.1X/EAP toward attacker-controlled AAA—not about PSK handshake cracking or Bluetooth pairing.
Full Explanation
A rogue Enterprise AP that presents a familiar municipal SSID primarily defines an evil-twin attack surface against 802.1X clients: the twin can induce EAP authentication toward attacker-controlled AAA so credential or certificate-trust failures become exploitable under authorization. That scenario is not mainly a test of whether guest captive portals force HTTPS upgrades on open SSIDs. It also does not prove that WPA3-SAE handshakes can be cracked offline like classic PSK captures. Bluetooth pairing replacing 802.1X is unrelated to this 802.11 Enterprise impersonation class. Exam caveat: Enterprise twins hinge on client trust behavior and EAP method choice; SSID similarity alone is incomplete without discussing certificate validation. Operational check: in a scoped civic lab, advertise only the authorized lookalike, confirm whether staff profiles attempt EAP to the lab AAA, and tear down before production clients remain associated. For municipal and campus engagements, keep the finding language tied to authorized scope, name the building or SSID class affected, and state the residual risk to residents or staff if the rejected option had been chosen. Re-validate after the next change window that the selected control still matches inventory, monitoring, and RoE abort criteria used by the city wireless program.