.svg)
Medical device penetration testing tends to land on the project plan late, usually the week someone reads FDA's submission checklist closely and realizes the cybersecurity section isn't a formality. Here's the short version: if your product counts as a cyber device, FDA expects security documentation and testing evidence in your premarket submission, and since October 1, 2023 the agency can refuse to accept a submission that doesn't include it. The fix isn't complicated. You scope a test against the device, its wireless interfaces, its companion app, and its cloud backend, you get a report written for a regulatory reviewer, and you file it with the rest of your documentation. Affordable Pentesting does exactly that for device makers working against submission dates: a fixed quote up front, testing booked in days rather than months, and findings your regulatory consultant won't have to translate.
Why FDA now expects security testing evidence
The legal hook is section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023. It's been in effect since March 29, 2023, and it applies to 510(k), PMA, and De Novo submissions for anything that meets the cyber device definition. FDA backed it with a refuse-to-accept policy: since October 1, 2023, a cyber device submission that doesn't address the 524B requirements can be bounced at the door, before anyone even looks at your predicate argument.
The agency's detailed expectations live in its premarket cybersecurity guidance, and that document keeps moving. The current version, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," was finalized in February 2026 and superseded the June 2025 edition, which had itself replaced the September 2023 original. Two revisions in under three years means advice written against the old text may already be stale, so check anything you read (including this) against the current guidance. Everything here is accurate as of August 2026.
Here's what the statute itself asks of you, and what reviewers expect to see against each part:
| Section 524B requirement | What satisfies it in practice |
|---|---|
| A plan to monitor, identify, and address postmarket vulnerabilities | A written vulnerability management plan with a coordinated vulnerability disclosure process |
| Reasonable assurance the device and related systems are cybersecure | Security architecture, threat model, and testing evidence, including a penetration test report |
| Update and patch capability, on a regular cycle and out of cycle for critical flaws | A tested update mechanism and documented patch timelines |
| A software bill of materials | An SBOM covering commercial, open source, and off-the-shelf components |
Is your product a cyber device
The statutory definition has three parts: the device includes software, it can connect to the internet, and it has technological characteristics that could be vulnerable to cybersecurity threats. Read that honestly and most connected products qualify. A glucose monitor with a phone app qualifies. An infusion pump that joins hospital Wi-Fi qualifies. An imaging accessory that pushes studies to a cloud viewer qualifies. If your device talks to anything, assume FDA will treat it as a cyber device and plan your evidence accordingly.
What surprises engineering teams isn't the definition, it's the blast radius. FDA's guidance treats the device and its related systems as one system: firmware, physical and radio interfaces, the mobile app, provisioning, the update path, and the cloud services behind all of it. Testing the firmware alone doesn't answer the question the agency is asking, because the riskiest paths usually run through everything else. There's a budget silver lining hiding in that breadth, though: a well-scoped engagement covers the whole connected system in one pass, so you aren't buying a device test, an app test, and a cloud test as three separate line items from three separate vendors.
What a medical device pentest actually covers
A useful test follows the same paths a hostile researcher would, and it's shaped by a threat model rather than a generic scanner profile. That's the difference between a vulnerability scan with a medical logo on it and testing a reviewer will accept.
On the device side, testers go after debug interfaces, exposed services, stored secrets, and the pairing and update flows, because a writable update path is the single worst finding a connected device can have. On the connected side, the companion app and the cloud APIs usually carry the highest-impact findings, since that's where patient data aggregates and where authorization bugs let one user see another's records. We've seen more devices compromised through a forgotten staging API than through the hardware itself, and that's precisely why the scope can't stop at the enclosure.
A word on safety, because it's the first question clinical teams ask: testing happens against bench units, test accounts, and staging environments, never against devices attached to patients. Exploits get demonstrated where they can't hurt anyone, then documented so precisely that your engineers can reproduce them without us in the room. If a vendor's plan doesn't spell out that separation, that's not a vendor who's tested medical devices before, and you shouldn't be their learning curve.
What your submission needs from the report
FDA's guidance is unusually specific about testing documentation. For penetration testing, reviewers look for who performed the test, evidence they were independent of the team that built the device, the scope and duration of the work, the methods used, and the findings with how you resolved them. A two-page executive summary doesn't carry that weight, and neither does a raw scanner export. Ask any vendor for a submission-ready sample report before you book. If they can't produce one, you've learned what you needed to.
Timing matters just as much. Test early enough that you can fix what's found and retest before you file, because a finding that's still open at submission time becomes a conversation with a reviewer instead of a line in your closure table. Working backwards from a filing date, you'd want testing finished six to eight weeks out. That's comfortable on our schedule, and it's exactly the kind of deadline work a big consultancy's booking queue can't absorb.
How the test runs
Scoping is a short call plus an interface inventory: what radios, what apps, what cloud services, what update path. Threat modeling turns that into an attack plan reviewers can trace. Then it's hands on: every interface probed, every trust boundary pushed, real exploit chains demonstrated safely on bench units rather than production patients' devices. You get findings as they're confirmed, not weeks later, and the retest of your fixes is part of the engagement rather than a second invoice.
The hospital customers asking about HIPAA
FDA isn't the only party grading your security. Your buyers are covered entities, and their procurement teams send security questionnaires that ask for recent penetration test results. It's worth being precise about hipaa penetration testing requirements here: the HIPAA Security Rule requires a risk analysis, and it doesn't name penetration testing anywhere in the regulation. Hospitals ask anyway, because a pentest report is the cleanest proof that somebody actually tried to break what you built. The same engagement that supports your FDA submission doubles as the evidence for those reviews, which is one reason device makers get more mileage per testing dollar than almost anyone else we work with. The vertical picture, from clinics to health systems, is covered in our guide to penetration testing for healthcare, and if your own operation handles PHI, our HIPAA compliance help page walks through what the Security Rule side actually demands.
FDA pentest questions device makers ask
Our predicate device never had security testing. Do we still need it?
Yes. Section 524B attaches to your submission, not your predicate's. Predicates cleared before March 2023 went through a different gate than the one you're walking through now, and reviewers won't accept the comparison as a substitute for evidence.
Can our own engineers run the test?
They can test all they want, and they should, but the premarket guidance calls for testers who are independent of the development team, and reviewers read the report with that in mind. An external test also tends to find the assumptions your team can't see because they made them.
What happens if the test finds something serious?
You fix it and retest, and the finding becomes part of your risk management story rather than a landmine in review. That's the whole argument for testing months before you file instead of weeks. A serious finding discovered by FDA's reviewers, or worse by a researcher after clearance, costs you far more than the fix.
Does FDA require a new pentest every year after clearance?
There's no named annual pentest mandate in 524B. What you've committed to is a postmarket plan for monitoring and addressing vulnerabilities, and periodic testing is the obvious way to make that plan real. Most device makers we test settle into an annual cadence plus testing after significant changes, which also keeps their hospital customers' questionnaires easy.
Get the testing done before the gate, not after
An RTA letter costs you a review cycle. A researcher finding the bug after clearance costs you a disclosure, a patch sprint, and a very uncomfortable customer call. Testing before you file costs a few weeks and a fixed fee, and it's the only one of those three you get to schedule. Send your interface list and filing date through the pentest quote page and you'll have a fixed number and a start date this week, with a report built for the reviewer who'll actually read it.