Medical Device Wi-Fi Security Guide

Reviewed September 17, 2026

A hospital biomedical engineering team cannot assume the Wi-Fi network their infusion pumps, patient monitors, or imaging gateways join is trustworthy. Guest networks, misconfigured VLANs, legacy access points, and shared passphrases are common in clinical environments, and a device that treats "connected" as "safe" inherits every weakness of that network. When a connected device's therapy delivery, alarms, or telemetry depend on Wi-Fi, a handshake flaw or a weak authentication choice is not a theoretical IT problem, it is a patient safety and regulatory problem. Manufacturers that get this wrong face rework late in development, FDA additional information requests, and postmarket incident response that could have been avoided with better upfront architecture decisions and documented evidence.

Why This Matters

Wi-Fi is the default connectivity path for infusion pumps, patient monitors, imaging workstations, remote monitoring hubs, and home-use devices. Unlike a wired connection, Wi-Fi extends the device's attack surface to anyone within radio range, and clinical environments are dense with overlapping networks, guest access, and legacy equipment that IT teams cannot always segment or patch quickly. A device that authenticates weakly, reuses static keys, or blindly trusts the local subnet can be intercepted, spoofed, or used as a pivot point into a broader clinical network.

This matters for three reasons. First, availability: a disrupted Wi-Fi session can delay alarms, therapy delivery, or monitoring data, with direct clinical consequences. Second, confidentiality and integrity: poorly authenticated Wi-Fi links can expose patient data or allow manipulation of device commands. Third, regulatory exposure: the FDA's current premarket cybersecurity guidance treats wireless interfaces as part of the required threat model, security architecture, and verification evidence. Manufacturers who treat Wi-Fi as "solved by the chipset vendor" typically discover the gap during FDA review or, worse, after a field incident, when the cost of remediation is far higher than it would have been at the design stage.

How Does the WPA2/WPA3 Handshake Secure Medical Device Wi-Fi?

The WPA2 4-way handshake exchanges four EAPOL-Key messages between a device and an access point to confirm both sides hold the same key material and to derive fresh session keys. It does not transmit the passphrase itself, and it is what actually encrypts traffic after a device associates with a network. WPA3 replaces the PSK exchange with Simultaneous Authentication of Equals (SAE), which resists offline dictionary attacks even against weak passphrases.

For medical devices, the practical difference is resilience under real-world conditions. WPA2-Personal security depends almost entirely on passphrase strength, something the manufacturer usually does not control in the field. WPA3 raises the floor by making brute-force attacks against captured handshakes much harder, and it requires Protected Management Frames (PMF), which reduces disruption from spoofed deauthentication frames.

[KEY REQUIREMENT] New Wi-Fi enabled device designs should support WPA3 or WPA2/WPA3 transition mode, and should never depend on a hardcoded or default passphrase as the sole protection for network access.

What Is KRACK and Does It Still Matter for Medical Devices?

KRACK (Key Reinstallation Attack) exploited a flaw in how some WPA2 implementations handled retransmitted handshake messages, allowing an attacker to force key reuse and decrypt or forge traffic. Vendor patches addressed the specific CVEs starting in 2017, but the underlying lesson still applies to long-lived medical devices: protocol implementations can have bugs, and a device that cannot receive validated firmware updates carries that risk for its entire service life.

KRACK matters today less as an active threat and more as a test case for patchability. A device fielded in 2026 running an unpatched 2016-era Wi-Fi stack is still vulnerable in principle, even though the industry-wide patching cycle finished years ago. Reviewers and integrators increasingly ask what a manufacturer's process is for responding to a newly disclosed wireless vulnerability, not just whether the device shipped clean.

Three questions determine whether a device is defensible against the next KRACK-class finding: can the Wi-Fi stack be updated in the field, does the manufacturer track the chipset vendor's security advisories, and is there a documented process for validating and deploying an emergency patch without disrupting clinical use. A device that cannot answer yes to all three carries open-ended postmarket risk regardless of its day-one configuration.

802.1X and EAP-TLS vs. Pre-Shared Keys: Which Should Your Device Support?

Enterprise authentication using 802.1X with EAP-TLS is generally preferable to a pre-shared key for any device deployed in a hospital, because it replaces one shared secret for the whole network with a unique certificate per device. Under 802.1X, the device authenticates to a RADIUS server using a client certificate, and the resulting session keys are unique to that session and that device, so compromise of one device's credential does not expose the entire fleet.

PSK-based WPA2 or WPA3-Personal remains appropriate for home-use devices, where hospital-grade infrastructure (RADIUS, certificate authorities) is not available and the user manages a household router. In that case, the design should compensate at the application layer, using TLS with certificate pinning or mutual authentication so that Wi-Fi access alone never grants device control.

[KEY REQUIREMENT] Devices intended for hospital deployment should support 802.1X/EAP-TLS as a configuration option, even if PSK is retained as a fallback for smaller sites, and the fallback path must be documented and risk-assessed.

How Should Manufacturers Handle Certificate Provisioning and Rotation?

See also: Bluetooth in Medical Devices: Security Risks and Controls, NeuroTech Cybersecurity Risks, and PATCH Act: Legacy Device Cyber Gaps.

Certificate provisioning must be planned as a manufacturing and lifecycle process, not a one-time engineering task. Each device needs a unique identity certificate issued during manufacturing or first commissioning, tied to a private key generated or injected securely, and a defined expiration and renewal path that does not require returning the device to the factory.

Rotation is where most programs struggle. A certificate with no renewal plan either expires and disconnects the device from the network, or is issued with an unrealistically long validity period that undermines the security benefit of using certificates at all. A practical approach uses a device-initiated renewal request well before expiration, backed by a hospital-integrated or manufacturer-hosted certificate authority, with a documented fallback for devices that miss the renewal window.

Manufacturers also need a revocation path. If a device is decommissioned, lost, or found to be compromised, its certificate should be revocable without disrupting the rest of the fleet, which is one of the structural advantages of certificate-based authentication over a shared PSK.

What Hospital Network Assumptions Should Manufacturers Avoid?

Manufacturers should never assume the hospital network is segmented, monitored, fully patched, or free of legacy Wi-Fi equipment. Biomedical and IT teams manage large, heterogeneous environments, and a device that only works correctly on an idealized, well-managed network will behave unpredictably in the field.

Common bad assumptions include: that the local subnet is trusted and any device on it can be treated as authorized, that the hospital's access points are all running current firmware and support WPA3, that guest and clinical traffic are always separated, and that IT staff will proactively update device-facing network configuration. None of these hold universally across hospital systems, and a device architecture that depends on any of them will eventually fail somewhere in the field.

The safer design principle is to treat the Wi-Fi network purely as transport and to enforce authentication, authorization, and integrity checks at the application and device level regardless of network configuration. This also gives manufacturers a stronger answer when hospital IT asks what happens if the device ends up on a flat, unsegmented network by mistake.

What Does the FDA Expect Documented About Wireless Interfaces?

The FDA expects wireless interfaces to appear explicitly in the system architecture, threat model, and verification evidence submitted as part of a premarket cybersecurity submission. This traces to the current final guidance chain (September 2023, updated June 27, 2025, and finalized February 3, 2026) on cybersecurity in medical devices, which frames connectivity, including Wi-Fi, as a required element of the security risk assessment under Section 524B of the FD&C Act.

In practice, reviewers look for a data flow diagram showing where Wi-Fi enters and exits the trust boundary, a threat model that addresses handshake weaknesses, rogue access points, and weak authentication, documented security requirements for supported Wi-Fi modes (WPA2-Personal, WPA2-Enterprise, WPA3), and verification evidence showing those requirements were tested, including negative testing against misconfiguration. Manufacturers can also reference AAMI SW96 (recognition number 13-131) for structuring the underlying security risk management process that ties these pieces together.

How Blue Goat Cyber Approaches This

Blue Goat Cyber works with manufacturers to threat model wireless interfaces early, before architecture decisions are locked in, so that Wi-Fi authentication choices, certificate lifecycle plans, and network trust assumptions are traceable to documented requirements and verification results. This includes evaluating whether a device needs 802.1X support for hospital deployment, reviewing certificate provisioning and rotation design, and validating handshake and configuration behavior through hands-on testing.

For teams preparing a submission, our medical device penetration testing services validate wireless configurations against real attack techniques, while our medical device threat modeling work builds the documented trust boundary analysis reviewers expect to see. The goal is a wireless security story that holds up under FDA review and under real hospital network conditions, not just a chipset vendor's default configuration.

Frequently Asked Questions

Is WPA2 still acceptable for medical devices?

WPA2 remains acceptable when configured correctly, meaning current firmware, strong passphrases or 802.1X authentication, and Protected Management Frames enabled where supported. New designs should plan a path to WPA3 or transition mode, since WPA3 raises the baseline against offline password attacks and requires PMF by default.

Do all medical devices need to support 802.1X?

Not all devices need 802.1X, but any device intended for hospital enterprise networks should support it as an option. Home-use devices typically rely on WPA2/WPA3-Personal because hospital-grade RADIUS and certificate infrastructure is not available in a home setting.

What happens if a device's Wi-Fi certificate expires in the field?

Without a renewal plan, an expired certificate disconnects the device from the network until it is manually reprovisioned. Manufacturers should design automated, pre-expiration renewal requests and a documented fallback procedure so a missed renewal window does not take a clinical device offline unexpectedly.

How is this different from the site's Bluetooth and NFC/RFID coverage?

This article focuses specifically on Wi-Fi authentication and the WPA2/WPA3 handshake. For short-range wireless risks, see our coverage of Bluetooth in medical devices and NFC and RFID security in medical devices.

CTA

If your device connects over Wi-Fi and you need a defensible security architecture, from authentication model to certificate lifecycle to FDA-ready documentation, Blue Goat Cyber can help you build and test it. Book a discovery session to scope the work for your device.