There Is Finally a Common Standard for Medical Device Penetration Testing

Until this summer there was no common answer to a question every connected device manufacturer has to answer: what does an adequate penetration test look like?

FDA expects one. The statute assumes one. But the how has been left to whichever firm you hired, which means two manufacturers could buy the same deliverable name and receive work differing by an order of magnitude in rigor, with no shared vocabulary for saying so.

MDIC published a framework on 29 June 2026 to close that gap. It came out of a working group of device manufacturers, FDA cybersecurity staff, and security researchers, which is worth noting. It is not a vendor's methodology promoted to a standard.

The five stages

The framework covers the lifecycle rather than the engagement:

Scoping. Define attack surfaces, system boundaries, and the threat scenarios worth testing.

Resourcing and supplier selection. Identify testers with the right expertise, the right independence, and regulatory experience.

Execution. Prepare the environment, run the engagement, keep communication working while it runs.

Findings and risk disposition. Turn vulnerabilities into decisions.

Reporting and communication. Align what was found with internal stakeholders, customers, and the submission.

Read that as a practitioner and one thing stands out. Two stages happen before anyone touches the device and two happen after the testing stops. Exactly one is the test.

That ratio is the argument. Most organizations buy the middle stage and improvise the other four.

Scoping is where the test is won or lost

The most common scoping failure is not testing too little of the device. It is testing the device.

A modern connected product is not a device. It is a device, a mobile companion app, a cloud backend, an update channel, and whatever the hospital network does to all of it. An attacker does not respect the boundary between the thing you manufacture and the thing you operate. Scope the firmware alone and you have bought a test of the part that was probably fine.

The scoping stage should produce a written system boundary naming what is in, what is out, and why. That document is worth as much as the report later, because the first question anyone reviewing your evidence asks is what you did not test.

Your exclusion list has two kinds of entries and should say which is which

This is the part I would add to the framework rather than take from it.

When you write down what is out of scope, the entries fall into two categories that look identical on the page and read completely differently to anyone assessing your evidence.

The first kind is covered by something else. There are always a few things you need verified independently that do not belong in a penetration test: a control better demonstrated by a unit test, a configuration confirmed by review, a supplier attestation you are relying on. Excluding those is correct. The test is not the only verification activity you have, and pretending otherwise makes it worse rather than more thorough.

The second kind is not covered by anything. Something got left out because there was not enough time, or budget, or because the environment was not ready. That is a legitimate decision. It is not a legitimate silence.

In practice most exclusions are the second kind, and most of those are driven by schedule rather than by risk. Internal tooling is the usual casualty, because it is the easiest thing to argue is lower priority when a submission date is approaching. The exclusion that ages worst is the internal tool that is scheduled to stop being internal. Trust boundaries move, and an exclusion written against last year's boundary quietly becomes wrong without anyone editing the document.

So write the two categories separately, and put a trigger next to every schedule-driven exclusion rather than a justification. Not "internal tooling was out of scope for this engagement," which reads as a shrug, but "out of scope this cycle, in scope when it becomes externally reachable." A reviewer reading the first one wonders what else you decided not to look at. A reviewer reading the second one sees a program.

Supplier selection has a constraint people discover late

The framework's emphasis on independence is not bureaucratic, and it has a downstream consequence that catches teams by surprise.

A tester genuinely independent of your design team cannot then remediate what they found, because an assessor who fixes their own findings and retests them has no independence left to certify anything. That is the correct position and reputable firms hold it.

Which means choosing a testing supplier is also, implicitly, deciding who is going to close the findings. If the answer is "we will figure that out when the report arrives," the report arrives and the work stalls. I have written separately about who closes penetration test findings; the short version is that it is neither your testing firm nor, usually, your MSP.

Decide it before you sign the testing contract, not after.

Disposition is the stage that decides everything

If you read one section of the framework, read this one. It is where the difference between evidence and paperwork lives.

A vulnerability is not a finding until somebody has decided what it means for this product. That decision has a small number of legitimate outcomes: remediate it, mitigate it with a control that makes it not matter, establish that it is not true of your system, or accept it with a stated rationale. Every finding gets exactly one, in writing.

What separates a defensible mitigation from an evasion is whether you can state three things: what the residual risk actually is, why it is acceptable, and what would have to change for that answer to change. The third gets skipped most and matters most, because a mitigation always rests on something. A signature check, a network boundary, a feature nobody uses yet. When that thing changes, the mitigation silently stops being one, and nobody gets a notification.

The mechanics of working a report into that shape are covered in what to do with a penetration test report.

Why this matters outside medical devices

Nothing in the five stages is specific to a regulated product.

A payments company, a legal SaaS platform, a business closing an enterprise security questionnaire: all of them buy penetration tests, and all of them buy the middle stage and improvise the rest. The difference is that a device manufacturer has an agency that will eventually ask to see the disposition record. Everyone else finds out later, and less formally, usually from a customer or an acquirer.

If you are outside medical devices and you want a defensible testing program, this framework is the most rigorous public description of one currently available. The regulatory framing is a feature. Somebody with subpoena power pressure-tested the structure on your behalf.

What to do with it

Read it before your next test, not after. Most of its value sits in stages that happen before an engagement starts, and those decisions are expensive to revisit once a statement of work is signed.

Write the system boundary down, with the two exclusion categories kept apart.

Decide who closes findings before you commission the test.

Build the disposition tracker on day one. A row per finding, with the component it belongs to, the disposition, and a free-text field for what you did and why. That last column is what a reviewer reads, and reconstructing it from memory four months later is far harder than capturing it as you go. It is also what turns a test into an answer for a deficiency letter rather than a new source of them.

This is engineering guidance, not legal or regulatory advice.