FDA’s 18 Cybersecurity Deliverables

Part of our FDA 2026 medical device cybersecurity submission series. For the full overview, start with FDA Cybersecurity Requirements for Medical Devices (2026).

Developing a medical device is a complex, multi-disciplinary effort, and cybersecurity is no longer optional. If your device connects, communicates, or relies on software, the U.S. Food and Drug Administration (FDA) expects you to demonstrate that you’ve thought about cybersecurity across the entire product lifecycle.

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 February 2026 final guidance and the latest eSTAR template (version 6) actually require.

Why this matters

The FDA's Cybersecurity in Medical Devices final guidance dated February 3, 2026 expanded the cybersecurity evidence reviewers expect to see in a premarket submission, and eSTAR v7.0 now has dedicated slots for those artifacts. Section 524B of the FD&C Act makes two of the eighteen deliverables, the SBOM and the postmarket Cybersecurity Management Plan, statutory requirements; the remaining sixteen are non-negotiable in practice because reviewers will issue a deficiency without them. The FDA's FY2025 MDUFA Performance Report lists cybersecurity among the subject-matter expert areas that may be involved in reviewing a device submission, alongside sterility, biocompatibility and software. Treating the list as a checklist works only if every item maps cleanly to its eSTAR slot, traces back to the threat model, and is internally consistent, gaps and contradictions are what reviewers flag first.

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, sees 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 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

See also: Breakthrough Device Designation and Cybersecurity, FDA Penetration Testing Requirements, and Letter to File vs New 510(k).

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

the team 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.

How Blue Goat approaches this

Blue Goat Cyber's medical device practice is led by engineers with CISSP, OSCP, and prior military red-team backgrounds. We treat cybersecurity documentation as design-controlled engineering output, not a submission template, every artifact (threat model, SBOM, security risk assessment, penetration test, labeling) traces back to a controlled requirement and a verified result.

Our engagements deliver the full Feb 3, 2026 guidance documentation set scoped to the device's risk profile, integrated with the existing IEC 62304 software lifecycle and ISO 14971 risk file. See our medical device cybersecurity services for the full scope. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.

FAQs

What is the FDA's current cybersecurity guidance?

The FDA's current cybersecurity guidance is the February 3, 2026 final guidance. It outlines the agency's expectations for cybersecurity in medical device premarket submissions.

Does the FDA cybersecurity guidance apply to all medical devices?

The FDA cybersecurity guidance applies to devices that are connected, communicate, or rely on software. The specific documentation burden scales with the cybersecurity risk posed by the device.

What is an SBOM and why does the FDA require it?

An SBOM, or Software Bill of Materials is a detailed inventory of all software components in a device. The FDA requires it to help manufacturers and users identify, understand, and manage cybersecurity risks from third-party software.

How does the FDA evaluate cybersecurity testing?

The FDA expects evidence that cybersecurity controls were tested through methods like SAST, penetration testing, and other security assessments. Submissions should include test plans, procedures, and reports with findings and remediation status.

What is a postmarket cybersecurity management plan?

A postmarket cybersecurity management plan describes how a manufacturer will monitor for new vulnerabilities, triage reports, assess risk, and issue patches or mitigations after a device has been cleared or approved.

How many pages of cybersecurity documentation does the FDA expect?

The FDA documentation can range from approximately 150 pages for simpler devices to over 600 pages for complex, multi-component systems, depending on the device's complexity and connectivity.

More on this topic

• What are Medical Device De Novo Requests?
• What is a Modular PMA Submission?
• Premarket FDA Cybersecurity Checklist