On this page
Published: · Updated:
Key Takeaways
- A shallow or late [threat model](/services/medical-device-threat-modeling "medical device threat modeling") is the single biggest cause of cybersecurity deficiencies, because every other artifact traces back to it.
- Reviewers read SBOMs for disposition, not inventory. A component list with no VEX statement reads as unmonitored.
- eSTAR v7.0 gives cybersecurity exactly one attachment area, so your threat model, SBOM, test reports, and postmarket plan must read as one cross-referenced package, not scattered files.
- Penetration testing evidence is judged by whether findings map back to the threat model, not by the count of findings.
- Postmarket cybersecurity fails most often because ownership was never assigned, not because the process was never written.
- Access control and update integrity failures still account for a large share of field compromises, ahead of exotic protocol attacks.
Medical device cybersecurity best practices means building evidence a reviewer can trace end to end: a system-level threat model built to ANSI/AAMI SW96, security requirements traced to controls and tests, an operational SBOM with VEX statements, risk-based testing including penetration testing, signed updates, and a staffed postmarket program with coordinated disclosure. Each piece has to survive the specific question a reviewer asks about it, not just exist in a binder.
A deficiency letter on cybersecurity almost never says "you have no security features." It says the threat model does not match the architecture diagram, the SBOM has no VEX statements, or the penetration test report does not map findings back to the threats you claimed to have modeled. Those are process failures, not missing controls, and they cost a submission cycle to fix. This guide is the build plan we use with engineering and regulatory affairs teams before that letter arrives: what a reviewer actually checks, what evidence satisfies it, and where teams lose the most time.
Why This Matters
The FDA's cybersecurity expectations for premarket submissions were first finalized in September 2023, updated in draft form in June 2025, and finalized again as Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions on February 3, 2026. That guidance, read alongside Section 524B of the FD&C Act, is what a reviewer is holding when they open your submission.
The practical effect is a single traceable story: threats, controls, tests, and a postmarket plan that all reference the same system model. When one link in that chain does not match another, the reviewer asks a question, and that question becomes weeks of delay. A build plan that produces matching artifacts the first time is the fastest path through review, not a compliance nicety.
What does a reviewer actually want from your threat model?
A reviewer wants a system-level model that names your actual interfaces, not a generic list of attacker categories copied from a template. Your device is rarely just the hardware. It is the firmware, the companion app, the cloud API, the update pipeline, and the customer network it deploys into, and the threat model has to name all of it.
Build it against ANSI/AAMI SW96:2023 using STRIDE per data flow element, and include multi-patient harm scenarios, not single-device ones. Map every threat to a mitigation and a piece of verification evidence, because a threat with no downstream control or test is a gap a reviewer will find. If your architecture diagram and your threat model describe different systems, fix that before you fix anything else, because every other deficiency downstream traces back to that mismatch.
Which standard applies: SW96, TIR57, or TIR97?
For new submissions, ANSI/AAMI SW96:2023 is the primary reference for security risk management, and TIR57 and TIR97 cover narrower, older, or postmarket-specific ground. Citing the wrong one, or citing TIR57 as if it were still the primary standard, is a common and avoidable flag in a submission.
| Standard | FDA recognition number | What it covers | When you cite it |
|---|---|---|---|
| ANSI/AAMI SW96:2023 | 13-131 | Security risk management across the total product lifecycle | Primary reference for new threat models and risk files |
| AAMI TIR57 | 13-83 | Legacy security risk management guidance that predates SW96 | Historical reference only, for programs that started before SW96 adoption |
| AAMI TIR97 | 13-112 | Postmarket vulnerability management and coordinated disclosure | Building or auditing your postmarket program |
If your risk management file still cites TIR57 as the primary security risk standard for a new submission, update it to SW96 before you submit. A reviewer who sees TIR57 alone in a 2026 filing will ask why.
What makes an SBOM operational instead of decorative?
An SBOM satisfies a reviewer when every listed component has a disposition, not just a name and version. That means SPDX or CycloneDX format, coverage of third-party and open-source components, and a VEX statement (not affected, affected, fixed, or under investigation) for every known CVE in the shipping configuration.
Build it as a living document tied to each release, monitored against KEV, EPSS, and NVD feeds, with version mapping so you know which shipped units are exposed when a new CVE lands. For the minimum elements themselves, CISA's 2026 Minimum Elements for a Software Bill of Materials supersede the earlier NTIA 2021 baseline, so align your SBOM template to the current CISA elements rather than the retired NTIA version. An SBOM that only gets regenerated at each submission is not operational, and a reviewer can usually tell.
Operationalizing a device security program?
Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. Postmarket cybersecurity services
What does eSTAR v7.0 change about how you package evidence?
eSTAR v7.0, released June 1, 2026, gives cybersecurity a single dedicated attachment area, not several separate slots for the threat model, SBOM, and test reports. That single-attachment structure means your evidence has to be assembled as one coherent package before it goes in, with clear internal cross-references, rather than left as separate documents you hope the reviewer connects.
Build the attachment in this order: system description and architecture, threat model, security requirements and traceability, verification and test results including penetration testing, SBOM with VEX, and the postmarket plan. A reviewer working through one attachment in that order finds fewer reasons to send an Additional Information request.
Where does penetration testing evidence fall apart?
Penetration testing evidence fails when the findings do not map back to the threat model that was supposedly guiding the test. A report that lists generic web vulnerabilities against a device whose threat model discussed wireless pairing and firmware tampering tells a reviewer the two documents were produced independently.
See also: How to Choose a Medical Device Cybersecurity Firm, What Is MedTech? MedTech vs Medical Device vs Life Sciences, and CVSS Scoring for Medical Devices: A Complete Walkthrough.
Scope testing to the interfaces your threat model actually names: the device, wireless and companion app interfaces, cloud APIs, and update mechanisms. Every finding needs a severity rating tied to patient impact, a remediation status, and retest evidence proving the fix closed the finding rather than just documenting that a fix was planned. Retesting is the step teams skip under deadline pressure, and it is the step reviewers ask about most.
Why do postmarket programs fail after launch?
Postmarket cybersecurity programs fail almost always because nobody owns them day to day, not because the written plan was inadequate. The submission gets a polished postmarket section, and then the vulnerability intake inbox, the SBOM monitoring cadence, and the coordinated vulnerability disclosure process never get staffed.
Build the program with the same rigor as the submission: a named vulnerability intake owner, a documented triage process weighing patient safety impact and exploitability, a coordinated vulnerability disclosure workflow, and SBOM monitoring that actually triggers action when a new CVE affects a shipped configuration. AAMI TIR97 is the reference to build this against. A postmarket plan that exists only on paper is the fastest way to turn a routine CVE into a Warning Letter.
How Blue Goat Cyber Approaches This
For the full scope of what we deliver, see our medical device cybersecurity services.
We build the threat model first, against ANSI/AAMI SW96, because every other artifact in the submission traces back to it, and a model that does not match the architecture is the single most common source of review delay. Our engineers hold CISSP and OSCP certifications, several with prior red-team backgrounds, and they build the security requirements, traceability, SBOM with VEX, and test plans as one connected package aligned to the FDA's February 3, 2026 final premarket cybersecurity guidance and Section 524B.
We scope penetration testing to the interfaces the threat model names, retest after remediation to close findings with evidence, and help stand up the postmarket program (intake, triage, coordinated disclosure, SBOM monitoring) so it survives past launch day. Our commitment: if the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our FDA premarket cybersecurity services to start.
Frequently Asked Questions
CTA
If your submission evidence is scattered across documents that do not quite agree with each other, that is the deficiency waiting to happen. Book a discovery session and we will walk your threat model, SBOM, and test plan against what a reviewer will actually check.
Related reading
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.