If you build connected medical devices, cybersecurity is no longer a nice-to-have section at the back of your 510(k). Since March 2023, Section 524B of the Federal Food, Drug, and Cosmetic Act has required manufacturers of "cyber devices" to demonstrate that their products are cybersecure before they reach the market, and the FDA has steadily tightened what it expects to see. Penetration testing sits at the center of that evidence package, and weak or missing test reports are one of the fastest ways to earn a deficiency letter.
Infusion pumps make the stakes obvious. They are networked, they talk to EHRs and drug libraries, and a successful attack can change how much medication reaches a patient. In this guide, Redfox Cybersecurity breaks down what medical device penetration testing for FDA submissions actually involves: the 524B requirements, how pre-market and post-market obligations differ, how we approach an infusion pump assessment, and the HL7 weaknesses we keep running into. We close with a practical FDA cybersecurity checklist you can use to pressure-test your own submission.
Section 524B was added to the FD&C Act by the Consolidated Appropriations Act, 2023, and took effect on March 29, 2023. It applies to any premarket submission (510(k), PMA, De Novo, and others) for a cyber device. The FDA began refusing to accept submissions that lacked the required cybersecurity information on October 1, 2023, so this is now a gate, not a suggestion.
Under 524B(c), a cyber device is one that includes software validated, installed, or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. In practice, the FDA reads "ability to connect" broadly. Devices with Wi-Fi, Bluetooth, Ethernet, cellular, USB, or even a service port that can link to a networked system are commonly treated as in scope. Almost every modern infusion pump qualifies.
Failing to comply with 524B(b)(2) is treated as a prohibited act under Section 301(q) of the FD&C Act, which raises the consequences well beyond a delayed clearance.
The statute itself does not use the phrase "penetration test." The requirement comes through the FDA's guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. It was finalized in September 2023, revised in June 2025 to add detail on 524B, and revised again in February 2026 to align with the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 into 21 CFR Part 820. The guidance expects security testing as part of design verification, and it specifically calls out penetration testing alongside vulnerability scanning, fuzz testing, and testing of security controls.
The FDA also tells reviewers what a penetration test report should contain. Your report should document:
Third-party reports are expected in their original form. A two-page summary from your internal team stating "no critical issues found" will not satisfy a reviewer.
Manufacturers often treat the pentest as a one-time submission artifact. The FDA does not. Pre-market and post-market testing serve different goals, and your quality system needs to support both.
Pre-market penetration testing validates that the security architecture you describe in your submission actually works. It should be traceable to your threat model: every significant threat you identified should map to controls, and every control should be tested. Reviewers look for that traceability. Typical pre-market scope includes:
Once a device is cleared, 524B requires you to monitor and address vulnerabilities for the life of the product. The FDA guidance recommends recurring security testing after release, for example annually, and testing whenever significant changes are made. Post-market testing should also cover newly disclosed vulnerabilities in third-party components listed in your SBOM. A library that was clean at submission can carry a critical CVE eighteen months later.
Healthcare delivery organizations feel the post-market side directly, because they are the ones operating these devices on hospital networks. If you are a hospital evaluating the pumps, monitors, and imaging systems already deployed in your environment, a healthcare penetration testing engagement focused on clinical networks and connected devices can tell you how exposed you really are.
Infusion pump vulnerabilities are not theoretical. Over the past decade, independent researchers have published serious flaws in pumps from several major manufacturers:
The patterns repeat across vendors: exposed debug interfaces, credentials stored in cleartext, unauthenticated management commands, and trust placed in the network rather than in cryptographic controls. That is exactly what a good medical device penetration test should find before the FDA, or an attacker, does.
The walkthrough below reflects the methodology Redfox Cybersecurity applies to infusion pump engagements. It is generalized and contains no client details, but each phase describes the kind of work and the classes of findings that FDA reviewers expect to see addressed.
We start with the manufacturer's architecture documentation and threat model, then build our own view of the system. For a typical smart pump, the attack surface includes the pump itself, a Wi-Fi or wired network module, a drug library and fleet management server, an EHR interoperability engine, and sometimes a mobile or web interface for clinicians and biomedical engineers. We identify the safety-critical functions, such as rate, volume, and drug library limits, and prioritize every path that could influence them.
We open the device and look for exposed UART, JTAG, or SWD interfaces. Debug ports left enabled on production hardware are still common, and they often provide a root shell or a direct path to dump flash memory. Once we have firmware, we analyze it for hardcoded credentials, private keys, weak or missing signature verification, and outdated third-party components that should appear in the SBOM. We also verify secure boot: can a modified firmware image load and run on the device?
We assess the Wi-Fi implementation, including how network credentials are provisioned and stored, whether the device validates server certificates, and how it behaves on hostile or rogue access points. We then enumerate every listening service. Proprietary management ports frequently accept commands without authentication, mirroring the Baxter gateway issue described above. We test whether an attacker on the same network segment could change configuration, redirect communications, or cause a denial of service that interrupts therapy.
The drug library server is a high-value target because it defines safe dosing limits for the entire fleet. We test its web interface and APIs using OWASP methodology, focusing on authentication, authorization, and input validation. We also test the software update process end to end: are updates signed, is the signature checked on the device, and can an attacker downgrade to a vulnerable version?
Modern pumps increasingly support auto-programming, where an order flows from the EHR to the pump, and auto-documentation, where infusion data flows back. These integrations typically rely on HL7 v2 messaging, often following IHE Patient Care Device profiles. This is where we find some of the most consequential issues, which is why it gets its own section below.
Every finding is scored for exploitability and, critically, for patient safety impact. We map findings back to the threat model and recommend controls, then document everything in the format the FDA guidance describes: tester independence and qualifications, scope, duration, methods, and results. After remediation, we retest so the final submission shows both the findings and the verified fixes.
HL7 v2 was designed decades ago for trusted internal networks. It has no built-in authentication, no encryption, and very permissive parsing. When device manufacturers and hospitals connect pumps to EHRs, those assumptions often carry straight into production.
HL7 v2 messages are usually transported over the Minimal Lower Layer Protocol (MLLP) on a raw TCP socket. Unless it is wrapped in TLS or a VPN, every message, including patient identifiers, drug names, and infusion rates, crosses the network in cleartext. An attacker with access to the clinical VLAN can read PHI and observe exactly how orders are structured.
Many HL7 listeners accept any well-formed message from any source IP. If an interface engine or pump gateway does not authenticate the sender, an attacker can craft and inject messages. In an auto-programming workflow, a forged order message could attempt to pre-populate a pump with incorrect parameters. Pump-side safeguards and clinician confirmation reduce this risk, but they should not be the only line of defense.
HL7 parsers must handle field, component, and segment delimiters, escape sequences, and optional segments. We fuzz these parsers with malformed and oversized messages, and we regularly see crashes, hangs, and inconsistent handling between systems. Delimiter injection, where a value smuggles in extra fields or segments, can cause the receiving system to interpret data differently from the sender.
Because HL7 traffic carries PHI, these gaps are also HIPAA problems for the hospitals that deploy your device. Health systems that want to validate the interface engines, clinical networks, and integrations around their devices can pair device-level work with HIPAA penetration testing that maps findings directly to Security Rule safeguards.
Use this checklist to review your premarket submission before it goes to the FDA. If you cannot confidently check every item, expect questions from reviewers.
Not every pentest provider can produce work that stands up to FDA review. When evaluating a partner, ask whether they:
Redfox Cybersecurity's team brings together offensive security, hardware hacking, and healthcare compliance experience. Whether you are preparing a 510(k) or validating devices already in the field, our healthcare penetration testing services are built for exactly this work.
Medical device penetration testing for the FDA is about more than clearing a submission. It is about making sure a networked device cannot be turned against the patient it is meant to protect. If you are preparing a submission or need to validate devices in the field, talk to Redfox Cybersecurity about medical device and healthcare penetration testing, or explore our HIPAA penetration testing services for the networks and systems your devices connect to.
Redfox Cyber Security Inc.
8 The Green, Ste. A,
Dover, Delaware 19901,
United States.
.avif)
