Medical Device Attack Surface Analysis: A Practitioner Method

Part of our Cybersecurity risk management series (AAMI TIR57, ISO 14971, IEC 81001-5-1). For the full overview, start with AAMI TIR57 Risk Management for Medical Devices.

A reviewer does not accept "we considered the attack surface" as a claim. They expect a list of interfaces, evidence that each one was found through a method rather than memory, and a line from each interface to a threat and a test case. Teams that skip this rigor tend to discover the missing interface during a deficiency letter or, worse, during an incident. This post gives you the enumeration method: the interface classes to work through, what evidence documents each one, how the list feeds the threat model in the relevant threats post, and which interfaces get missed most often.

Why This Matters

The FDA's final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued February 3, 2026 and following the September 2023 and June 2025 versions in that chain, asks for a security risk assessment built on the device's architecture and interfaces. You cannot produce that assessment from memory once a device has more than a handful of components.

An incomplete attack surface produces two failure modes. The threat model omits a class of attack the interface enables, so the risk assessment understates residual risk. The penetration test scope then mirrors that same gap, so testing confirms a false sense of security instead of finding the real one.

eSTAR v7.0, effective June 1, 2026, collapses the cybersecurity content into one attachment area rather than the eight separate slots some older guidance implied. That consolidation makes the attack surface inventory more important, not less, because the reviewer is now reading one coherent narrative and expects the interface list, the threat model, and the test report to visibly agree with each other.

What counts as an interface for attack surface purposes?

An interface is any point where data, power, or physical access crosses the boundary of the device. Group them into eight classes so nothing gets lost in an undifferentiated list.

How do you find every interface instead of the obvious ones?

You find the full surface by combining four independent methods, because any single method misses classes of interface the others catch. Schematic and bill of materials review catches physical and debug interfaces that software documentation never mentions. Firmware and binary analysis catches network listeners, hardcoded services, and third party libraries that open their own connections without engineering's knowledge.

Dynamic discovery, port scanning, protocol fuzzing, and RF spectrum analysis, catches what actually runs at power on versus what the design intended. Interviews with firmware, mobile, and cloud engineers catch service modes and debug backdoors that exist for manufacturing or support and never made it into a requirements document. Cross-check the four lists against each other; disagreements between them are usually where the real gaps sit.

What evidence documents each interface?

Each interface needs a specific artifact, not a checkbox, because the reviewer is evaluating whether the claim is verifiable. The table below maps interface class to the evidence a submission should be able to produce on request.

How does the interface list become a threat model and a test scope?

The interface list becomes a threat model by running STRIDE against each interface rather than against the device as a single black box. Each interface, or the data flow crossing it, gets evaluated for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege, and the full method for deciding which resulting threats are actually relevant to your device lives in the relevant threats post.

The same list becomes the penetration test scope directly. Every interface class with a nontrivial risk rating in the threat model should appear as a line item in the test plan, with a stated method, hardware access for physical interfaces, protocol tooling for wireless, credentialed and uncredentialed testing for network services, and static plus dynamic analysis for the app and cloud layers.

See also: CVSS Scoring for Medical Devices: A Complete Walkthrough, Healthcare Cybersecurity Companies: A Buyer's Selection Guide, and Medical Device Software Development: A Compliance Guide.

Which interfaces do teams forget?

Debug headers left populated on production boards are the most common miss, because engineering assumes they will be removed before manufacturing and nobody verifies it on the shipping unit. Service and maintenance mode is a close second; it is authenticated in the design document and unauthenticated in the field build because the credential got hardcoded during bring up and never rotated.

Third party SDKs embedded in the mobile app or the cloud backend open their own network connections for analytics, crash reporting, or licensing, and those connections are rarely inventoried as part of the device's attack surface even though they carry device or patient data. Removable media is frequently treated as a convenience feature rather than a data exfiltration path, especially when the card holds calibration data alongside clinical logs.

Legacy interfaces from a prior hardware revision, an old cellular modem's AT command interface, or a diagnostic port kept for backward compatibility with older service tools, also get left off current documentation because nobody updates the interface list when a component is deprecated rather than removed.

How Blue Goat Cyber Approaches This

We start every engagement with a structured interface enumeration across the four discovery methods, schematic review, firmware analysis, dynamic discovery, and engineering interviews, before we open a threat modeling session. That order matters, because a threat model built on an incomplete interface list produces a test plan with the same blind spots.

Our team, made up of CISSP and OSCP certified engineers including former military red team members, treats the interface list as a living artifact that gets revisited whenever the architecture changes, in line with what AAMI SW96 expects from an ongoing security risk management process. We hand back a reconciled set: the interface inventory, the threat model built from it, and the test scope that covers every interface with material risk. If the FDA raises cybersecurity deficiencies tied to our submission work, we resolve them at no additional cost. Our medical device penetration testing and medical device threat modeling services both start from this same interface inventory.

Frequently Asked Questions

What is the difference between attack surface analysis and threat modeling?

Does attack surface analysis apply to legacy devices already on the market?

How often should the interface list be updated?

Can a penetration test substitute for attack surface analysis?

Do we need to attack-surface-map third party components we did not build?

Where does removable media fit if the device never leaves the clinical setting?

CTA

If your current attack surface documentation is a paragraph rather than a list with evidence, that gap will surface as a reviewer question or a missed finding in testing. Book a discovery session and we will walk your architecture against this enumeration method before it becomes a deficiency letter.