Medical Device Cybersecurity Checklist: Design to Postmarket

Part of our Medical device cybersecurity strategy, culture, and lifecycle series. For the full overview, start with Total Product Lifecycle Security for Devices.

Reviewed September 17, 2026

A missing piece of cybersecurity evidence can stall a submission for months, and a gap discovered after launch can trigger a recall. Medical device manufacturers face both risks at once: the FDA reviews cybersecurity documentation line by line during premarket review, and attackers look for the same gaps once a device reaches hospitals. Neither problem is solved by a single test or a late-stage document push.

A checklist only helps if it maps to evidence a reviewer or an auditor will actually ask for, not vague reminders to "be secure." This piece organizes that evidence by the phase in which it needs to exist: design, development, testing, submission, and postmarket. Each item states what a reviewer expects to see, not just what practice to follow, so teams can self-check readiness before an FDA request or an internal audit surfaces the gap.

Why This Matters

Cybersecurity gaps in medical devices are not abstract compliance risks; they are patient safety risks with regulatory consequences attached. A device that ships without a documented threat model or a current SBOM cannot demonstrate that its security controls address realistic attack paths, and that gap is exactly what the FDA's February 3, 2026 final premarket guidance was written to close. This guidance replaced the June 27, 2025 version and the original September 2023 guidance, and it holds manufacturers to the same total product lifecycle expectation across design, development, testing, submission, and postmarket support.

The cost of getting this wrong compounds. A submission missing SBOM detail or security risk traceability generates additional information requests that delay clearance by months. A device that reaches the field without a patch delivery mechanism cannot respond quickly when a vulnerability is disclosed, which is now a documented gap under CP 7382.850, the inspection procedure that replaced QSIT on February 2, 2026. A checklist tied to evidence, rather than general best practices, gives manufacturers a way to check their own readiness before either of those failures happens.

This also protects manufacturers from an easy mistake: assuming a third-party penetration test alone satisfies the requirement. A test can confirm whether a control resists a specific attack, but manufacturers are the ones who must verify that the requirement was met against their own design inputs.

Design Phase: What Evidence to Build First

The design phase is where cybersecurity evidence is cheapest to produce and most expensive to skip. Reviewers expect to see a threat model, an architecture diagram with trust boundaries marked, and a documented set of security requirements before any test occurs.

[KEY REQUIREMENT] A threat model must identify assets, trust boundaries, and attack surfaces specific to the device's actual architecture and intended use environment, not a generic template. Reviewers can typically tell the difference between a device-specific threat model and a copy-pasted one within a few pages.

Checklist items for this phase:

• Document the device architecture, including wireless interfaces, cloud connections, and hospital network touchpoints.
• Build a threat model using a structured method such as STRIDE, tied to the specific interfaces identified.
• Translate threat model findings into testable security requirements, not general statements of intent.
• Define the security risk management process that will track these requirements through design changes.

Development Phase: Turning Requirements into Verifiable Code

Development is where security requirements either become verifiable controls or stay aspirational. The evidence expected here includes static analysis results, dependency tracking, and a running SBOM that updates as components change.

Static and dynamic code analysis findings must be triaged and resolved or formally risk-accepted, not simply generated and filed away. A running SBOM should capture every open-source component, its version, and known vulnerabilities at the time of each build, since a stale SBOM is one of the most common reasons reviewers send additional information requests.

[KEY REQUIREMENT] Every SBOM entry needs a support end-of-life date and a vulnerability monitoring source, because an SBOM without this metadata cannot support the ongoing vulnerability management plan the guidance requires.

Checklist items for this phase:

• Run static application security testing (SAST) and dynamic analysis (DAST) against the codebase, not just the final build.
• Maintain the SBOM continuously as dependencies change, rather than generating it once before submission.
• Track triage decisions for every flagged vulnerability, including risk-acceptance rationale where a fix is deferred.
• Verify secure coding standards, such as input validation and secure default configurations, against the documented requirements.

Testing Phase: What a Reviewer Wants to See Verified

Testing is where manufacturers confirm, with evidence, that the controls built during development actually hold up against realistic attacks. This includes penetration testing of every external interface, fuzz testing of parsers and communication protocols, and verification that each security requirement from the design phase was tested, not just exercised generally.

A penetration test report needs to map findings back to the specific security requirements it was scoped to evaluate. This mapping is what turns a test into evidence a reviewer can use, rather than a narrative of findings with no connection to the design inputs.

[KEY REQUIREMENT] A manufacturer, not the penetration testing vendor, must verify and document that each security requirement was satisfied. A clean penetration test report does not by itself attest that design inputs were met; that verification is the manufacturer's responsibility.

See also: 8 FDA Cybersecurity Deficiencies, Ranked From Real Letters, FDA IDE Cybersecurity Requirements: 2026, and SBOM Diffing & CVE Correlation Postmarket.

Checklist items for this phase:

• Test every external interface: wireless radios, APIs, cloud integrations, and physical debug ports.
• Fuzz test protocol parsers and file format handlers exposed to untrusted input.
• Map every finding, and every closed requirement, back to the original security requirements list.
• Retest after remediation to confirm fixes hold and did not introduce new issues.

Submission Phase: Assembling the Package

The submission package is where all prior evidence gets assembled into the documentation the FDA reviews. Missing or inconsistent artifacts here are the most common reason for additional information requests under the February 3, 2026 final guidance.

Checklist items for this phase:

• Include a complete SBOM with support end-of-life data, consistent with the version actually shipping.
• Submit the postmarket vulnerability management plan describing how issues will be identified, triaged, and patched after clearance.
• Provide a security risk traceability matrix connecting requirements, tests, and results.
• Confirm alignment with recognized standards, including AAMI SW96 (FDA recognition number 13-131), IEC 81001-5-1, and ISO 14971 for risk management.
• Address the 510(k) substantial equivalence requirements alongside cybersecurity documentation so the two do not conflict.

[KEY REQUIREMENT] Every artifact in the submission package must be internally consistent: the SBOM version, the architecture diagram, and the test report must all describe the same build, since discrepancies between them are a frequent trigger for deficiency letters.

Postmarket Phase: Sustaining the Evidence Trail

Cybersecurity evidence does not stop being relevant once a device clears review. Manufacturers need an active coordinated vulnerability disclosure program, a mechanism to deliver patches, and ongoing monitoring of the SBOM against newly disclosed vulnerabilities in third-party components.

The FDA's inspection approach for these obligations changed on February 2, 2026, when QSIT retired and was replaced by CP 7382.850. That procedure looks for documented evidence of the postmarket practices described in the submission, not just the existence of a plan on paper.

Checklist items for this phase:

• Operate a coordinated vulnerability disclosure program with a published contact and response timeline.
• Monitor the SBOM against vulnerability databases on a recurring schedule, not only at renewal.
• Maintain a signed, validated patch delivery mechanism and document each patch release.
• Feed field findings, including customer-reported issues, back into the risk management file.
• Reassess the threat model when the device architecture or intended use environment changes materially.

How Blue Goat Cyber Approaches This

Blue Goat Cyber works with manufacturers at each phase covered above, building the evidence trail rather than assembling it after the fact. That includes threat modeling during design, SBOM generation and monitoring through development and postmarket, and scoped penetration testing that maps findings to the manufacturer's own security requirements. Because manufacturers retain responsibility for verifying that design inputs were met, the goal is a documentation set the manufacturer can defend on its own, supported by services such as FDA premarket cybersecurity services for submission-stage work and ongoing postmarket support for SBOM and vulnerability monitoring once the device is in the field.

To keep your SBOM and vulnerability records current after clearance, GoatWatch matches components to new CVEs and tracks VEX decisions.

Frequently Asked Questions

What is the single most common reason a submission gets an additional information request on cybersecurity?

Inconsistency between artifacts is the most common trigger, such as an SBOM version that does not match the tested build or a test report with no link back to documented security requirements. Reviewers cross-reference these documents closely, and gaps between them read as unresolved risk rather than a paperwork issue.

Does a penetration test satisfy the FDA's cybersecurity requirements on its own?

No. A penetration test confirms whether specific controls resisted specific attacks, but the manufacturer must independently verify and document that its own security requirements, tied to its design inputs, were satisfied. A test report is one input to that verification, not a substitute for it.

How often should the SBOM be updated?

The SBOM should update every time a dependency changes, not just before a submission or renewal. Postmarket, it should be checked against vulnerability databases on a recurring schedule so new third-party disclosures are caught before they become field incidents.

What changed with the retirement of QSIT?

QSIT retired on February 2, 2026 and was replaced by CP 7382.850, the inspection procedure the FDA now uses to evaluate quality system compliance, including postmarket cybersecurity practices. Inspectors under this procedure look for documented, operating evidence of the practices described in a submission, not just a written plan.

Which standards does the current FDA guidance point to?

The February 3, 2026 final guidance points to AAMI SW96 (FDA recognition number 13-131) for premarket cybersecurity risk management, IEC 81001-5-1 for secure product lifecycle processes, and ISO 14971 for overall risk management. Aligning documentation to these standards helps a submission match reviewer expectations.

CTA

Building this checklist into your product lifecycle takes structure, not just a document template. If you want help mapping your current evidence gaps against the February 3, 2026 guidance before your next submission, book a discovery call with Blue Goat Cyber.