A nonprofit asks whether an open guest SSID plus captive portal is secure enough for staff workflows that handle PII. What is the sound OSWP-aligned answer?
Select an answer to reveal the explanation.
Short Explanation
A guest portal is a bouncer for coffee-shop Wi-Fi, not a vault for case files. Staff PII needs real auth and crypto, not a splash page. Do not dress Internet gating up as enterprise confidentiality.
Full Explanation
An open guest SSID plus captive portal is not an appropriate primary control for staff workflows that handle PII. Portals mainly gate Internet access or acceptable-use acceptance; they do not provide the mutual authentication and strong air encryption expected for sensitive municipal or nonprofit staff traffic. Open-plus-portal is not equivalent to EAP-TLS confidentiality and accountability for clinic or case-management workloads. Captive portals do not encrypt staff PII with SAE automatically merely because a splash page exists. Guest open or portal designs are not adequate by default for HIPAA-regulated or similarly sensitive workloads without additional strong segmentation and staff SSID controls. Exam caveat: guest portals can still be appropriate for true visitor Internet access when segmented; the failure is using them as a staff data network. Operational check: map which civic devices handle PII, confirm they use WPA2 or WPA3-Enterprise or a carefully risk-accepted Personal mode, and verify guest VLANs cannot reach staff data segments. 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.