When you enter the premarket submission phase, this expectation becomes a substantial documentation burden. At Blue Goat Cyber, we categorize the FDA’s requirements into 18 key cybersecurity deliverables that appear, in some form, in nearly every modern submission for a device with cybersecurity risk.
These aren’t an “official FDA checklist,” but they are a practical way to organize what the FDA’s June 2025 guidance and the latest eSTAR template (version 6) actually require.
Cybersecurity expectations are consistent – but scale with risk
A common misconception is that the FDA’s cybersecurity documentation requirements change significantly based on the device’s risk level or submission pathway. In reality, the categories of information the FDA expects are broadly consistent across “cyber devices” and other connected devices.
What does change is depth and complexity.
- A relatively simple, minimally connected device (for example, an oxygen pump with limited network exposure) will have:
- A simpler threat model
- Fewer architecture views
- Smaller SBOM and lighter test evidence
- A complex, highly connected system (for example, a surgical robot with cloud connectivity and multiple interfaces) will need:
- Detailed threat modeling across components
- Extensive architecture views
- A large SBOM and more rigorous testing (including deeper penetration testing and abuse-case testing)
Yes, the same types of documents apply, but the level of rigor, detail, and page count increases with the level of cybersecurity risk.
Christian Espinosa, founder of Blue Goat Cyber, and Trevor Slattery, our Chief Technology Officer, see this play out with clients every day. The biggest mistake? Treating cybersecurity as an afterthought instead of a structured, traceable part of the design from day one.
How our 18 cybersecurity deliverables line up with the FDA’s eSTAR
The FDA’s eSTAR (electronic Submission Template And Resource) organizes the Electrical, Software, and Cybersecurity content for electronic submissions. Within that structure, we consistently see 18 cybersecurity deliverables that together tell a complete story.
Below is how we define them and how they align with FDA expectations.
1. Risk Management Report
This is the core of your cybersecurity story and typically includes three significant pieces:
- Threat Model
A structured analysis of how an attacker could compromise your device or ecosystem. We often use STRIDE and reference frameworks like MITRE ATT&CK for Medical Devices to ensure we’re covering realistic tactics and techniques. - Cybersecurity Risk Assessment
For each threat/vulnerability pair, you evaluate likelihood and impact, then assign a risk level and define risk controls. This work should integrate seamlessly with your overall ISO 14971 risk management process. - Software Bill of Materials (SBOM)
A detailed inventory of all software components, including third-party and open-source libraries. This is now a hard expectation for cyber devices—and practically speaking, for most connected devices. - SBOM Supporting Material
Information about support status, maintenance, and vulnerability monitoring for each component—plus how you’ll keep the SBOM current over the device’s life.
2. Cybersecurity Assessment of Unresolved Anomalies
No non-trivial software is perfect at release. This deliverable documents:
- Known software anomalies or “acceptable” residual defects
- How they were evaluated from a security perspective
- Any mapping to frameworks such as CWE (Common Weakness Enumeration)
- Why do you consider the remaining risk acceptable, and what controls or compensating measures exist
The FDA wants to see that you didn’t ignore defects that might have cybersecurity implications.
3. Cybersecurity Metrics
This document outlines the methodology for measuring and monitoring your cybersecurity posture over time. Examples include:
- Percentage of identified vulnerabilities remediated within defined SLA windows
- Average time from vulnerability discovery to patch release and deployment
- Defect density over time by component or release
- Results of recurring security tests (e.g., trend in pen test findings by severity)
These metrics support the FDA’s emphasis on total product lifecycle (TPLC) risk management.
4. Cybersecurity Controls
Here, you translate the risk assessment into concrete controls and design decisions. This typically covers:
- Access control and authentication (e.g., roles, multi-factor, local vs. remote access)
- Encryption in transit and at rest
- Logging, audit trails, and event detection
- Network segmentation, firewalls, and secure network protocols
- Hardening and configuration management
- Safety-relevant behaviors in the presence of anomalous or malicious input
The FDA will look for clear traceability between risks and controls, as well as between controls and verification.
5. Security Architecture Views
Security architecture views give reviewers a clear picture of:
- Global system architecture (devices, cloud, apps, interfaces, networks)
- Data flows and trust boundaries
- Multi-patient or multi-system harm scenarios (e.g., what if this component is compromised?)
- Updatability and patchability—how you deliver authenticated updates
- Specific security use cases (e.g., secure provisioning, key management, credential rotation)
These visuals and descriptions make your design choices understandable and reviewable.
6. Cybersecurity Management Plan
Often called the postmarket cybersecurity management plan, this deliverable describes how you will:
- Monitor for new vulnerabilities (internal testing, external reports, threat intel)
- Intake and triage vulnerability reports (coordinated disclosure process)
- Assess risk, prioritize remediation, and issue patches or mitigations
- Communicate with customers and regulators as appropriate
The FDA wants to see a sustainable process, not just one-time design work.
7. Cybersecurity Testing
The FDA expects evidence that your controls were actually tested. We usually break this into several sub-deliverables:
- Static Application Security Testing (SAST)
Automated and manual review of source code for security-relevant issues. - Penetration Test Plan
Scope, methodology, and environment setup for security testing—including what is in scope (device, cloud, APIs, mobile apps) and what attack vectors will be exercised. - Penetration Test Cases / Procedures
Representative test cases and abuse cases are mapped to your threat model and controls. - Penetration Test Report
Findings by severity, exploitability, and impact, plus remediation status and residual risk justification.
Depending on the device, we may also include DAST, fuzz testing, protocol testing, and network assessments.
8. Cybersecurity Labeling
The FDA’s guidance has a lot to say about what should appear in labeling and customer-facing security documentation. We typically organize this into three parts:
- Customer Security Documentation (often aligned to JSP2)
Many manufacturers use documentation aligned with the Medical Device and Health IT Joint Security Plan (JSP2) to describe responsibilities, supported configurations, and security features in a structured way. - Manufacturer Disclosure Statement for Medical Device Security (MDS2)
A widely used form that provides healthcare delivery organizations (HDOs) and others with a detailed view of device security capabilities, dependencies, and expectations. - Interoperability Labeling
If your device integrates with other systems or supports interfaces that influence clinical decisions, you’ll need specific labeling to describe safe and secure use of those connections.
The FDA doesn’t “mandate” JSP2 or MDS2 by name, but they strongly align with the guidance’s requirements.
9. Interoperability Risk Assessment
If your device relies on external systems, services, or interfaces to perform critical functions, you’ll need a dedicated assessment that looks at:
- Risks introduced by those dependencies
- How you authenticate and authorize external connections
- How you handle data integrity, timing, and failure conditions across systems
- What happens if those external systems behave unexpectedly or maliciously
The FDA wants to understand how your security and safety perform in a real-world ecosystem, not just in isolation.
Why a structured, repeatable process matters
Across all 18 deliverables, one theme consistently emerges: structure and repeatability.
As Christian often says, “We have a very unique methodology that we follow… our risk is based on the actual worst-case scenario as opposed to hypotheticals around data, which is more traditional for cybersecurity risk assessments.”
In practice, that means:
- A consistent way to connect threats → risks → controls → tests
- Reusable patterns across product lines and submissions
- Transparency for both engineers and regulators
- A strong foundation for postmarket vulnerability handling
Trevor emphasizes the same point from a technical angle: “What can you do to get ready for it early? How can you maturely develop your software documentation to inform your security documentation? Make decisions like this early on and start with the end in mind.”
The documentation burden is real—plan for it
For most connected medical devices, cybersecurity documentation alone can easily run:
- ~150 pages for simpler, low-complexity devices
- 600+ pages for complex, multi-component systems with rich connectivity
That level of effort is almost impossible to bolt on at the end. It must grow in tandem with your design and development process.
Our advice:
- Start with the end in mind. Use the 18 deliverables as a planning checklist early in development.
- Integrate security into your SDLC and QMS. Let design documents, software requirements, and risk analysis inform your cybersecurity deliverables directly.
- Treat cybersecurity like any other safety-critical function. Traceable, verified, and maintained over time.
Partnering with medical device cybersecurity experts
If all of this feels overwhelming, you’re not alone. Most teams don’t build multiple FDA-grade cybersecurity packages a year—but we do.
At Blue Goat Cyber, we help medical device manufacturers:
- Build and refine threat models and cybersecurity risk assessments
- Create SBOMs and supporting processes that actually work
- Develop security architecture views and controls that reviewers can follow
- Plan and execute penetration testing that maps directly to FDA expectations
- Assemble, organize, and polish the complete cybersecurity documentation package for eSTAR submissions
“If you ever need help with this,” Christian likes to say, “this is what we do at Blue Goat Cyber. We can build these documents with you, take the learning curve off your shoulders, and help you get to an FDA-ready story faster.”
Need help with an FDA medical device submission or cybersecurity documentation?
Schedule a Discovery Session with Blue Goat Cyber, and let’s map out your path to a secure, submission-ready device.