Remote county clinicians work from hotel and coffee-shop Wi-Fi to reach clinic EHR apps. Link crypto on those foreign SSIDs is unknown. What additional control should the WLAN security design require for application traffic?
Select an answer to reveal the explanation.
Short Explanation
Hotel Wi-Fi is someone else’s driveway—you do not control the lock on the gate. A VPN wraps the clinician’s EHR traffic in a tunnel you do trust, on top of whatever (or nothing) the coffee-shop AP provides. Hiding SSIDs or hoping for WEP is not a remote-access design.
Full Explanation
Remote county clinicians on hotel and coffee-shop WLANs face unknown or hostile link cryptography outside the clinic’s control. Organizational WLAN security design therefore requires a VPN that encrypts application sessions—especially EHR paths—back to enterprise gateways under clinic policy, independent of whatever the foreign SSID happens to offer. The VPN complements, rather than assumes, third-party RF encryption and keeps confidentiality and access policy under municipal control on untrusted paths. Disabling encryption to avoid VPN overhead inverts the risk model for protected health information in transit and fails basic remote-access design. Asking the hotel front desk to switch to WEP if staff will share a key is both operationally unrealistic and cryptographically unacceptable. Hiding the clinic’s own SSID name does nothing for clinicians already using foreign networks and is not a confidentiality control for application traffic traversing someone else’s access point. Exam caveat: VPN does not remove the need for strong link security on the clinic’s own campus SSIDs; it specifically addresses the untrusted off-campus path when clinicians work remotely. Operational check: require split or full-tunnel VPN per policy on clinician endpoints, then from a lab SSID that mimics open public Wi-Fi verify EHR flows are encapsulated before leaving the device and that plaintext EHR hostnames or payloads are not visible in an RF or local packet capture.