A standard SaaS pentest and a MedTech pentest are not the same engagement. The scope is different, the regulatory context is different, the documentation requirements are different, and the consequences of getting it wrong are different. If you are building a medical technology platform, whether that is a connected device, a digital health SaaS product, or a clinical data system, and you are trying to understand what a pentest actually involves in your context, this is the post for you.
A medtech pentest is increasingly required rather than optional, and the regulatory landscape has changed significantly since 2023. Here is what you need to know before you start scoping an engagement.
What Actually Classifies as a MedTech Company
Before getting into the pentest specifics, it helps to be clear about what we mean by MedTech, because the regulatory requirements vary significantly depending on what you are building.
If you are building a software-only digital health platform, a remote patient monitoring tool, a clinical decision support system, a telehealth application, or a SaaS platform that helps healthcare organizations manage patient data, you are likely a Software as a Medical Device (SaMD) company. Your primary regulatory exposure is HIPAA if you handle protected health information, and potentially FDA oversight if your software meets the definition of a medical device under Section 524B of the Food, Drug, and Cosmetic Act.
If you are building hardware or a connected device, an implantable device, a diagnostic instrument, a wearable health monitor, you are building a medical device proper, and your pentest requirements are driven directly by FDA premarket submission requirements, which are significantly more prescriptive.
Both categories share some common ground: they handle sensitive health data, they operate in an environment where security failures have direct patient safety implications, and they sell to enterprise healthcare buyers who have their own security review processes that go well beyond a standard vendor questionnaire.
The FDA Requirement That Changed Everything for MedTech Pentests
In December 2022, the Consolidated Appropriations Act was signed into law. Section 3305 of that act, adding Section 524B to the FD&C Act, fundamentally changed the cybersecurity requirements for medical device manufacturers submitting premarket applications to the FDA.
Effective March 29, 2023, manufacturers of cyber devices must include specific cybersecurity information in premarket submissions including 510(k), PMA, PDP, De Novo, or HDE applications. Since October 1, 2023, the FDA has enforced a Refuse to Accept policy for premarket submissions that fail Section 524B requirements. That means a submission without adequate cybersecurity documentation does not just get flagged, it gets rejected before review even begins.
What counts as a “cyber device” under this definition? A cyber device is a device that includes software validated, installed, or authorized by the sponsor as a device or in a device, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. In practical terms, virtually any connected medical device or software-based health platform qualifies.
A penetration test report with threat model traceability and remediation evidence for all findings is among the required elements for premarket submission. This is not a recommendation, it is a documented expectation in FDA guidance that submissions must satisfy to avoid rejection.
The FDA’s updated guidance, finalized in June 2025 and superseded by a further update shortly after, reinforces that cybersecurity controls in medical devices require testing that goes beyond standard software verification activities. A pentest is explicitly identified as part of the evidence package FDA reviewers expect to see.
What a MedTech Pentest Needs to Cover
A medtech pentest is not simply a web application or API test with a healthcare logo on the cover. The scope needs to reflect the specific attack surfaces and risk scenarios that exist in medical technology environments.
Application and API security. Most MedTech platforms expose significant functionality through APIs, to clinicians accessing the platform, to patients using a mobile interface, to EHR systems pulling or pushing clinical data, and to connected devices sending telemetry. Every one of these API surfaces represents a potential attack path to protected health information. Authenticated and unauthenticated testing across all user roles is standard. Authorization failures between user types, where a patient can access another patient’s data, or a clinician can access data from outside their organization, are the most common critical finding in MedTech API testing.
External network perimeter. Any public-facing infrastructure that could provide a path to systems handling patient data needs to be included in scope. This includes cloud-hosted infrastructure, exposed services, and any integration endpoints connecting to external systems.
Threat model traceability. This is the element that separates a compliant MedTech pentest from a generic web app test. FDA guidance expects the pentest to be traceable to a threat model, meaning the test scenarios should map directly to the threats identified in your threat modeling exercise, and the report should document which threats were validated, which were not observed, and how findings relate back to the risk framework. A pentest report that simply lists CVSS-scored vulnerabilities without this traceability is insufficient for FDA submission purposes.
Remediation evidence. The FDA expects not just a list of findings but documentation that findings were remediated and that remediation was verified through retesting. A pentest report without a retest letter confirming Critical and High findings are closed does not satisfy premarket submission requirements.
HIPAA Adds a Second Layer
Most MedTech companies that handle patient data are also subject to HIPAA, which adds a second set of expectations on top of FDA requirements.
HIPAA’s Security Rule does not explicitly name penetration testing, but the 2025 HIPAA Security Rule NPRM, not yet finalized as of mid-2026, proposes annual penetration testing as a required control. Even before finalization, most HIPAA auditors treat penetration testing as an expected component of a defensible risk analysis, and enterprise healthcare buyers routinely require current pentest reports as part of their vendor security review.
For a MedTech company, the combination of FDA premarket submission requirements and HIPAA compliance expectations means a pentest is not one of several options for demonstrating security. It is effectively the required mechanism for satisfying both regulatory frameworks simultaneously, provided it is scoped and documented correctly.
What to Look for in a MedTech Pentest Vendor
Not every pentest firm understands what a MedTech pentest actually requires. The gap between a firm that does web application testing for generic SaaS companies and one that understands FDA 524B documentation requirements, threat model traceability, and the specific attack vectors relevant to clinical data systems is significant.
Before signing with a vendor, ask specifically how they have handled FDA premarket submission pentests before, whether their report format includes threat model traceability, and how they document remediation evidence for retesting. Ask whether they understand the distinction between testing a SaaS platform handling PHI and testing a connected medical device, the scope and methodology differ meaningfully between these two contexts.
For a SaaS-based MedTech platform, the pentest scope you need is manual testing covering your web application, API surface, and external network perimeter, with explicit attention to PHI-handling endpoints, cross-tenant data isolation, and authentication flows managing access to patient data. The report needs to be structured to support both FDA submission evidence and HIPAA risk analysis documentation.
For a connected device manufacturer, the requirements extend further, into firmware security, hardware interfaces, and the communication protocols between device and cloud backend, and typically require a vendor with specific embedded systems and medical device security expertise.
Why Enterprise Healthcare Buyers Require It Too
Beyond the regulatory frameworks, MedTech companies selling to hospitals, health systems, and enterprise healthcare organizations face a third layer of pentest expectations: the vendor security review.
Enterprise healthcare buyers conduct thorough security assessments of every vendor before granting access to their systems or patient data. A current pentest report, less than twelve months old, from a credentialed firm, covering your actual production environment, is typically a baseline expectation before a vendor assessment will proceed. For a MedTech company, the absence of a pentest report in a vendor security review is not just a gap. It is a signal that the company may not understand the regulatory environment it operates in, which raises broader concerns for the buyer’s security team.
The fastest path through an enterprise healthcare security review is having a well-scoped, current pentest report that covers your PHI-handling architecture, maps findings to compliance frameworks, and includes documented remediation evidence for any Critical or High findings discovered.
Getting the Scope Right Before You Start
The most common mistake MedTech founders make when commissioning their first pentest is letting the vendor define the scope based on a generic template rather than the specific regulatory and security requirements of their environment.
Before your first scoping call, know which regulatory frameworks apply to your specific platform, FDA 524B if you are submitting a premarket application, HIPAA if you handle PHI, and potentially both. Know whether your product qualifies as a cyber device under FDA’s definition. Know which systems and environments should be in scope versus which are out of scope for the submission or compliance framework you are targeting. And know what your auditor or FDA reviewer will actually need to see in the final report, because a pentest that covers the right systems but produces the wrong documentation is no more useful than one that covered the wrong systems entirely.
Packet33 conducts web application, API, and external network penetration tests for MedTech and HealthTech startups, with reports scoped and formatted to support FDA premarket submissions, HIPAA compliance documentation, and enterprise healthcare security reviews. We work with MedTech founders at the seed and Series A stage who are navigating these requirements for the first time.
Talk to us about scoping a medtech pentest for your environment.
Packet33 is a penetration testing and compliance advisory firm serving SaaS and HealthTech startups in the US, Canada, and UK.