Wireless Security in Medical Devices: FDA Guide

Wireless security starts with patient safety - not just encryption. I start by checking whether Section 524B applies, then link each wireless risk to a control, a test, and safe behavior when connections fail.

For covered submissions filed on or after March 29, 2023, the law requires a vulnerability-monitoring and remediation plan, patch processes, and a software bill of materials (SBOM). Wireless capability alone does not make a device subject to Section 524B.

In this guide, I cover how to:

• Define device boundaries, supported wireless settings, and hospital responsibilities.
• Connect security threats to patient harm and set measurable test limits.
• Keep cybersecurity, wireless performance, coexistence, and EMC testing separate.
• Assemble submission records and deployment instructions backed by test results.
• Assign owners for vulnerability reports, patches, monitoring, and support deadlines.

My rule: <u>keep legal duties, FDA recommendations, and manufacturer choices separate</u> - and support each claimed control with test records.

Review Wireless Protocols and Security Controls

Compare Protocol Security and Deployment Limits

Assess each configured interface in the approved interface inventory - not just its protocol name. Review its configuration, deployment limits, and failure behavior in each clinical setting: home, clinic, ambulance, hospital, unmanaged networks, dense RF environments, roaming, power loss, and temporary disconnects. Record these limits alongside interoperability constraints.

Also review service-layer security for every wireless-connected interface. For application-layer services over wireless, check TLS versions, cipher suites, certificate validation, hostname checks, topic permissions, retained-message handling, association authentication, permitted destinations, and any enabled unencrypted transport. Document negative tests. A protocol name alone does not prove protection.

Link Wireless Attacks to Patient Harm

Trace attacks across each trust boundary. Spoofing or a rogue access point may allow credential theft. Stolen credentials or unauthenticated commands may then allow therapy changes. Replay can repeat a valid command, while interception, downgrade attacks, and insecure fallback can compromise data integrity. Denial of service can delay measurements or interrupt monitoring.

Separate PHI disclosure from safety consequences, such as incorrect therapy, delayed diagnosis, or lost essential performance. Deprecated cryptography, default passwords, and unsupported protocols are weaknesses that enable attacks - not patient harms themselves.^[4]

Define Security Controls and Safe Failure Behavior

Require mutual authentication where appropriate, message integrity, replay protection, least privilege, secure defaults, allowlists, and rate limits that do not block essential functions. Limit maintenance access through strong authentication and auditable, time-limited privileges.^[4] Define how keys are generated, stored securely, rotated, revoked, and recovered.^[4][9]

For interference, jamming, or network loss, define clinically justified local operation, alarms, stale-command rejection, bounded buffering, and recovery behavior. Keep records of control rationales, threat-model assumptions, protocol decisions, and accepted limitations.

Keep four evidence streams separate: cybersecurity, wireless QoS, coexistence, and EMC. Each answers a different question:

• Cybersecurity testing evaluates hostile actions and attempts to bypass controls. Wireless quality-of-service testing measures latency, throughput, packet loss, jitter, and reconnection.
• Coexistence testing evaluates operation alongside other RF systems; FDA identifies AAMI TIR 69 and ANSI C63.27 as relevant approaches. EMC testing addresses emissions and immunity under applicable requirements, including IEC 60601-1-2.

Passing one type of testing does not establish the others. Each needs its own methods and acceptance criteria tied to safe operation.^[5][6][8] Carry these separate records into the risk file and verification plan.

sbb-itb-535baee

Build the Risk File and Test Wireless Security

Compile the Cybersecurity Risk File

Start with the approved system boundary and protocol inventory. Treat approved wireless interfaces and supported configurations as the source of truth for the risk file.

Freeze a version-controlled baseline that includes architecture and data-flow diagrams, an asset inventory, a threat model, security requirements, implementation artifacts, and an SBOM. Tie the SBOM to component versions, suppliers, support status, end-of-support dates, known vulnerabilities, and controls.^[10][4]

Link each finding to the safety file using vulnerability → compromised function → hazardous situation → harm. Assess attacker access, exploit prerequisites, existing mitigations, and impact at both the device and system levels. A vulnerability score alone does not establish patient risk. Document residual-risk acceptance, benefit-risk analysis when needed, and assumptions about supplier support, monitoring, and remediation.^[3]

Use this baseline to set verification scope and test coverage.

Test Security Controls and Wireless Failures

Test the controls and failure modes identified in the protocol review - not just the protocol name. Tests must show that the device fails safely as defined, rather than simply meeting protocol requirements.

FDA identifies four test categories: security requirements, threat mitigation, vulnerability testing, and penetration testing.^[3] Use protocol-aware fuzzing, vulnerability scans, and attack-chain tests to cover invalid credentials, unauthorized commands, malformed inputs, and interrupted connections.

Also verify secure boot, firmware integrity, every supported update path, rollback safeguards, recovery, provisioning, and factory reset. Define the penetration-test scope and tester independence. Run disruptive radio tests in an isolated environment, with safety monitoring and clear stop criteria.^[11]

Document Test Coverage and Acceptance Criteria

Trace each test to its requirements. Set observable pass/fail criteria before testing, tied to requirements or risk controls. Keep one matrix row per requirement or threat mitigation. Use the fields below to link requirements to results and record how each finding was handled. Scan results alone are not enough.^[11]

Keep failed tests, deviations, fixes, and regression results - not just passing reports. Assign each finding an owner, due date, exploitability assessment, and patient-impact rationale. Obtain approval for unresolved residual risks.

Before citing a standard, check its current FDA recognition status, edition, scope, and exclusions. Recognized standards support device-specific evidence; they do not replace it or automatically satisfy every cybersecurity expectation.^[1]

Prepare the FDA Premarket Submission

Compile Design, Risk, and Test Records

After verification, assemble the approved evidence for the selected FDA pathway. Map the final verified build’s records to that pathway and determine whether Section 524B applies. For the applicable 510(k), De Novo, PMA, PDP, or HDE submission, include the device description, deployment setting, architecture, threat model, security risk-management report, requirements traceability, secure-development processes, and verification and validation reports. Index every artifact by revision, owner, and submission location. Don’t submit an unindexed risk file.^[12][13][15]

Keep statutory duties separate from FDA recommendations. For Section 524B-covered devices, include the required vulnerability-monitoring/remediation plan, patch process, and SBOM.^[3][16] Use the artifact index to guide deployment instructions and the readiness review.

Document Deployment Instructions and Wireless Limits

Turn verified technical limits into clear labeling and installation instructions. Specify supported networks and protocol versions, required security settings, hospital credential responsibilities, approved pairing and provisioning, prohibited configurations, logging, and incident-reporting channels. Explain how the device behaves when wireless service fails: fail safe, restricted mode, alarm preservation, data buffering, or manual recovery.^[7][13]

Document update authorization, update-package authenticity checks, interrupted-update recovery, rollback safeguards, and any clinical downtime restrictions. State the support period and how users will receive end-of-support notices. Keep every instruction within the submitted evidence: don’t promise recovery behavior or wireless settings that the evidence doesn’t support. Separate device-enforced controls from hospital-supplied controls, including network segmentation, access management, and monitoring.^[3][13]

Check Submission Readiness

Use the table to record actual status and open issues - not assumed completion. Before filing, resolve conflicting records, assess remaining vulnerabilities against the final build, and check current FDA pathway instructions and electronic templates. Keep the approved submission index, document-owner approvals, review comments and dispositions, final evidence versions, and the exact electronic package filed.^[2][14]

Assign Post-Release Duties and Monitoring

Assign Vulnerability Response and Patch Duties

After premarket review, name the owners for vulnerability response, patching, monitoring, and end-of-support. Use the approved risk file, SBOM, and wireless limits to set responsibilities and escalation paths. The manufacturer remains accountable for product cybersecurity. FDA premarket review does not transfer that accountability to the HDO. HDOs handle secure deployment, access control, logs, patch scheduling, backup, recovery, and removal of unsupported devices through collaborative risk management. Contracts and procedures should identify the security, quality, regulatory, and clinical owners at both organizations.^[3][10][19]

Hand off SBOM monitoring and a channel for reporting vulnerabilities. Tie each report and decision to the affected device model, firmware version, wireless interface, and risk file. Set response targets based on risk: urgent issues need immediate escalation and, when warranted, out-of-cycle remediation. Routine work needs a documented schedule. These targets are not universal FDA patch deadlines.^[3][10][17] Use the handoff matrix below to assign owners and timing.

Track site deployment acknowledgments separately from patch availability. Escalate sites that cannot update, document interim controls, and retain exception approvals.^[3][10][19]

Monitor Wireless Events and Review Changes

After deployment, use device and network logs to spot wireless issues early. Watch for unapproved pairing, authentication failures, unexpected access points, abnormal traffic, failed updates, and repeated disconnections. Specify which signals come from the device and which require HDO network logs.

Use synchronized timestamps, asset identifiers, firmware versions, and event outcomes. Minimize PHI, restrict log access, and define how logs will be securely transferred, retained, and deleted.

Reassess risk when new vulnerabilities, repeated failures, or clinical effects appear - or when radios, protocols, authentication, or networks change. Regulatory affairs must document any required submission, reporting, or correction/removal action, including evaluation under 21 CFR Part 806.^{[17][18][20][21]}

FDA cybersecurity requirements: What is surprising and new in 2026?

Conclusion: Confirm Wireless Security Readiness

Base readiness on traceable evidence, not a checklist. Once verification and package assembly are complete, confirm that the wireless requirements, protocol choices, deployment assumptions, and accepted residual risks support the final decision for the clinical use case.^[7][4]

Check that device versions, supported wireless configurations, test results, and limits align in the final package. Back every claimed control with evidence, including verified safe behavior during connectivity loss and recovery.^[3][4]

Close the review by assigning ownership and documenting postmarket follow-through. Record the final decision, device and software versions, approvers, approval date, evidence locations, and open issues. After submission, keep handoffs, monitoring and escalation plans, patch records, risk reassessments, and customer communications up to date.^[3][17]

FAQs

How do I determine whether Section 524B applies to my device?

Check whether your device meets all three FDA criteria for a cyber device under Section 524B of the FD&C Act:

• It incorporates software validated, installed, or authorized by the manufacturer.
• It connects directly or indirectly to the internet or other networks, including through USB, Bluetooth, or internal update servers.
• It has features that could make it susceptible to cybersecurity risks.

If your device meets all three criteria, Section 524B’s premarket and postmarket requirements apply.

How do I set clinically justified wireless test limits?

Set wireless test limits based on the device’s clinical use and risk profile, not just generic technical benchmarks. Identify wireless entry points and map each one to potential patient harm in your threat model.

Weigh CVSS exploitability metrics alongside clinical safety impacts. A moderate vulnerability may still need urgent mitigation when the device supports life-sustaining or time-sensitive care.

Document your reasoning, connect test objectives to risk controls, and show that residual risks are acceptable in the clinical setting.

When does a wireless security update require a new FDA submission?

A wireless security update requires a new FDA submission if it changes the device’s intended use or introduces new risks. Security fixes generally follow existing change-control processes when they maintain safety and effectiveness.

Manufacturers must follow the Design Changes process (820.30(i)) for every patch and update. This includes thorough documentation, verification, and validation. Manufacturers must also assess each change’s cybersecurity impact and determine whether a new filing is needed.

Related Blog Posts

• 7 Critical Medical Device Security Risks in Healthcare
• NIST SP 800-213 for Medical Devices: What to Know
• How Penetration Testing Supports FDA Compliance
• FDA Cybersecurity Rules for IoT Medical Devices