New policy prefers WPA3-Personal for SOHO-style municipal field offices, and the laptops support it. What should the technician do on those clients?
Select an answer to reveal the explanation.
Short Explanation
Policy says WPA3-Personal and the laptops can do it—flip the security type and move on. Clinging to WEP or mixing Enterprise certs into a Personal SSID just breaks joins. Match the BSS, don't invent a fallback to open.
Full Explanation
When municipal policy prefers WPA3-Personal for SOHO-style field offices and the laptops support it, technicians should select WPA3-Personal on those client profiles so the security type aligns with the BSS and policy. Capable civic clients should not remain on weaker legacy modes when WPA3-Personal is both required and supported. Matching AKM and cipher expectations prevents association failures and advances the field-office hardening goal without inventing unsafe fallbacks.
Leaving profiles on WEP for printer compatibility keeps an obsolete cipher suite and violates the WPA3-Personal preference for municipal staff laptops. Forcing WPA2-Enterprise certificates on a Personal SSID mismatches authentication architecture and typically prevents join. Disabling modern AKMs so the AP falls back to open authentication undermines confidentiality and is not a legitimate migration path for field-office clients.
Exam caveat: client security type must follow both policy and BSS capability—laptop support alone is insufficient if the saved profile still says WEP or Enterprise. Operational check: update a field-office laptop to WPA3-Personal, join the SSID, confirm the association reports WPA3-Personal/SAE as expected, and remove conflicting legacy profile entries for the same SSID.