FDA Medical Device Cybersecurity 2026: 524B eSTAR Checklist

Last updated: March 2026 (based on FDA’s current premarket cybersecurity guidance issued Feb 3, 2026).

If your device includes software, connectivity, or third-party components, the FDA’s 2026 cybersecurity guidance serves as your blueprint for what reviewers expect in a premarket submission. This page breaks down Section 524B (including what qualifies as a “cyber device”), and gives you a practical, eSTAR-ready checklist of the deliverables you should have in hand for a 510(k), De Novo, or PMA.

Quick navigation

What the FDA’s 2026 guidance emphasizes
Section 524B overview: “cyber device” + what FDA expects
Premarket package checklist (deliverables)
“eSTAR-ready” language + packaging tips
Common gaps that trigger FDA questions
FAQs

What the FDA’s 2026 guidance emphasizes (practically)

FDA’s 2026 update reinforces a simple standard: cybersecurity is part of device safety and effectiveness, and it needs to be managed through lifecycle processes—not handled as a last-minute document dump.

Three themes drive how the FDA reviews your submission:

Design for security: show how the architecture and controls reduce realistic threats.
Transparency: provide the details users (and hospital IT) need to deploy and maintain the device securely.
Submission-quality evidence: include traceable documentation and test results scaled to risk.

Primary sources: FDA guidance landing page (Feb 2026) | Download the FDA final guidance (PDF)

Section 524B overview: what is a “cyber device” and what the FDA expects

What is a “cyber device”?

Section 524B applies to devices that meet the statutory definition of a “cyber device”. In plain English, a device is a cyber device when it:

Includes software (validated, installed, or authorized by the sponsor) as a device or in a device,
Has the ability to connect to the internet, and
Has technological characteristics that could be vulnerable to cybersecurity threats.

Two FDA interpretations matter in real submissions:

“Software” includes firmware and programmable logic—not just “apps.”
“Ability to connect to the internet” can include unintentional connectivity through any means in the environment of use (not just what you intended in your design).

Primary sources: FDA Cybersecurity FAQs (524B definition + requirements) | 21 U.S.C. § 360n-2 (Ensuring cybersecurity of devices)

What does the FDA expect for 524B?

Section 524B requires sponsors of cyber devices to include in their premarket submissions information demonstrating that the device meets the statutory cybersecurity requirements. In practice, the FDA expects three things to be clearly addressed and supported by evidence:

(1) A vulnerability monitoring and response plan (including coordinated vulnerability disclosure and related procedures)

(2) Lifecycle processes and procedures that provide a reasonable assurance the device and related systems are cybersecure—and that you can provide updates and patches postmarket

(3) An SBOM covering commercial, open-source, and off-the-shelf software components

If you want the fastest reviewer comprehension, treat 524B like a “show your work” standard: threat model → risk assessment → control rationale → test evidence → postmarket readiness (including SBOM and vulnerability response).

Premarket package checklist (deliverables)

This is a practical checklist you can use to build a complete, reviewer-friendly premarket cybersecurity package. Scale depth to risk and complexity, but keep the categories consistent.

1) Reviewer roadmap (submission guide)

One-page cybersecurity overview (device scope, key risks, key controls)
Crosswalk: guidance topic → your artifact → where it is attached in eSTAR
Traceability snapshot: threats/risks → requirements/controls → verification evidence

2) Security risk management package

System description (including environment of use and connectivity reality)
Asset inventory + trust boundaries
Threat model with data flows and abuse/misuse cases
Cybersecurity risk assessment tied to patient harm pathways and system impact
Risk control rationale and residual risk acceptability
Interoperability considerations (dependencies on external networks/systems)
Assessment of unresolved anomalies with security impact rationale

Need help building this fast? Medical device threat modeling services

3) Security architecture package

Security requirements (authentication, authorization, cryptography, integrity, logging, recovery, updates)
Architecture views that make enforcement obvious (trust boundaries, data/control flows, privileged paths)
Design decisions for updateability/patchability across the total product lifecycle
Third-party component strategy (selection, qualification, update control)

4) SBOM + third-party software evidence

Machine-readable SBOM (e.g., SPDX or CycloneDX) covering commercial, open-source, and OTS components
Component lifecycle context (maintained vs end-of-support + relevant dates)
Vulnerability monitoring sources and triage approach for components
Supply-chain controls for suppliers and updates

FDA-compliant SBOM services for MedTech

5) Cybersecurity verification and validation (test evidence)

Security test plan tied to risks and controls (what you tested and why)
Results summary + detailed reports (tooling versions, pass/fail criteria, retest evidence)
Penetration testing/adversarial testing summary (scope, methodology, findings, remediation status)
Justification for any remaining limitations or compensating controls

FDA-compliant vulnerability & penetration testing

6) Transparency deliverables (labeling + customer-facing security info)

Cybersecurity labeling: secure configuration, network requirements, recommended controls
Security maintenance guidance (updates, patching expectations, responsibilities)
Where users will find security information (e.g., security whitepaper, portal, MDS2, instructions for use)

7) Cybersecurity management plan (postmarket readiness)

Vulnerability intake and monitoring (vendor advisories, CVEs, healthcare alerts)
Triage and remediation workflow with decision criteria (including out-of-cycle patches)
Coordinated vulnerability disclosure (CVD) process and communications plan
Update and patch delivery approach for the device and related systems

FDA postmarket cybersecurity management services

8) If the FDA sends a deficiency, have a response plan

Pre-drafted evidence map (so you can answer quickly)
Owner assignments for remediation + retesting + document updates
Submission-ready language that connects fixes to risk controls and test evidence

FDA cybersecurity deficiency response support

“eSTAR-ready” language + packaging tips

For most teams, “eSTAR-ready” means two things:

Your attachments match the questions (no missing evidence, no mislabeled files).
Your story is traceable (reviewers can connect risks → controls → test results quickly).

Primary sources: FDA eSTAR Program overview | FDA eSTAR 510(k) template guidance (Oct 2023)

eSTAR packaging tips that reduce reviewer friction

Use a single naming convention (e.g., “Cybersecurity – Threat Model v1.2”, “Cybersecurity – SBOM (SPDX)”, “Cybersecurity – Pen Test Report”).
Lead with a crosswalk table mapping each guidance topic/524B requirement to your artifacts.
Attach the traceability matrix once and reference it—don’t spread traceability across five documents.
Call out “related systems” explicitly (update servers, apps, cloud, hospital networks) and show how you address them.

Copy/paste “eSTAR-ready” language (edit to fit your device)

SPDF / lifecycle statement: “We establish, implement, and maintain secure development and maintenance processes across the total product lifecycle. Cybersecurity risk management is integrated with design controls, verification/validation, and postmarket feedback.”
Threat modeling statement: “Threat modeling was performed to identify realistic attack paths across device interfaces, data flows, and trust boundaries, including environment-of-use connectivity.”
SBOM statement: “A machine-readable SBOM is provided and includes commercial, open-source, and off-the-shelf components, along with component lifecycle context to support vulnerability monitoring and remediation.”
Updates/patching statement: “The device and related systems are designed to support timely security updates and patches. Update integrity is verified, and recovery/rollback mechanisms are defined and tested where applicable.”
Vulnerability management statement: “Postmarket vulnerability monitoring and response procedures are defined, including coordinated vulnerability disclosure, triage criteria, remediation planning, communications, and retesting.”

Pro tip: Add a one-page “Reviewer Roadmap” at the top of the cybersecurity section. That single page often prevents a chain of clarification questions.

Common gaps that trigger FDA questions

Cyber device determination is unclear: you didn’t address all three criteria or the FDA’s connectivity interpretation.
SBOM is present but not actionable: missing lifecycle context (e.g., end-of-support) or monitoring approach.
The threat model is thin: architecture diagrams lack trust boundaries and enforcement points.
Testing is not tied to risk: scan outputs exist, but verification rationale and pass/fail criteria do not map to controls.
Postmarket plan is vague: no triggers, no timelines, no communication path, no update strategy.

Key takeaways

524B is a “show your work” requirement: vulnerability plan + lifecycle processes + SBOM.
FDA’s 2026 guidance expects traceability from threats to controls to verification evidence.
eSTAR readiness is packaging discipline: crosswalk, clean attachments, and a single traceability matrix.
Plan for postmarket on day one: updates, monitoring, disclosure, and communications.

FAQs

How do I know if my device is a “cyber device” under Section 524B?

If your device includes software (including firmware or programmable logic), has the ability to connect to the internet (including connectivity that can occur in the environment of use), and has characteristics that could be vulnerable to cybersecurity threats, it likely meets the definition. When in doubt, build your submission to cover 524B expectations.

What are the minimum 524B submission requirements?

At minimum, sponsors should address: (1) a plan to monitor, identify, and address postmarket vulnerabilities and exploits (including coordinated vulnerability disclosure), (2) processes and procedures providing reasonable assurance the device and related systems are cybersecure (including updates/patches), and (3) an SBOM covering commercial, open-source, and off-the-shelf software components.

What makes an SBOM “FDA-ready” in practice?

A machine-readable SBOM is the baseline. Most teams also need to show component lifecycle context (e.g., end-of-support risk) and a clear vulnerability monitoring/triage approach that ties SBOM components to action.

What does “eSTAR-ready” mean for cybersecurity documentation?

It means your responses are accurate, your attachments directly answer the questions, and your evidence is traceable. A crosswalk + consistent file naming + a single traceability matrix makes review faster and reduces follow-up questions.

Do I need penetration testing for every device?

Testing should scale to risk and complexity. For connected devices and systems with meaningful attack surface, adversarial testing (including penetration testing) is often the most credible way to validate control effectiveness and detect real-world weaknesses.

What are “related systems” under 524B and why do they matter?

FDA expects you to consider the device as part of a broader system (e.g., companion apps, cloud services, update servers, hospital networks). Your cybersecurity evidence should address these dependencies, especially where they affect updates, authentication, data flows, and safety impacts.

Book a Discovery Session to discuss an eSTAR-ready premarket cybersecurity package aligned to the FDA’s 2026 expectations.

Related Blue Goat Cyber resources

Note: This content is for general informational purposes and is not legal advice.