eSTAR Cybersecurity Readiness Checklist (510(k) & De Novo)

eSTAR CYBERSECURITY READINESS · UPDATED 2026

A practical, section-by-section checklist that maps every cybersecurity control the FDA expects under Section 524B and the February 2026 final premarket cybersecurity guidance to the exact eSTAR section it belongs in. Use it as your pre-submission go/no-go before you hit "submit" in the eSTAR template.

• 250+ - Submissions
• Zero - Rejections
• 7 - eSTAR Sections
• 35+ - Cyber Artifacts

Why an eSTAR-specific checklist exists

Most cybersecurity checklists are organized around the SPDF, AAMI SW96, or IEC 81001-5-1. Those are the right starting points - but reviewers consume your submission through the eSTAR template, section by section, attachment by attachment. A cybersecurity package that is brilliant in isolation but landed in the wrong eSTAR section still triggers a Refuse-to-Accept hold.

This guide flips the orientation: it walks the eSTAR template top-down and tells you exactly which artifacts go where, what reviewers verify in each section, and the failure modes we see most often after 250+ FDA submissions.

Use this as a pairing tool. Read it side-by-side with the SPDF Playbook and the Premarket Cybersecurity Submission Checklist. The SPDF tells you what to build; this guide tells you where to put it.

eSTAR Section → Cybersecurity Artifact Map

Section 14 - Software / Cybersecurity (the anchor)

This is where 80% of the cybersecurity package lives. Reviewers expect every attachment here to be labeled, versioned, and cross-referenced from the device description and risk file.

• Cybersecurity Management Plan - lifecycle ownership, governance, escalation path. Maps to Section 524B(b)(1).
• Threat Model - data flow diagrams, trust boundaries, STRIDE enumeration, and the four architecture views (global system, multi-patient harm, updateability, security use case). See 12 Critical Threat Modeling Gaps for the specific depth reviewers look for.
• Security Risk Assessment - exploitability-to-harm mapping, integrated with the ISO 14971 hazard analysis. A standalone security risk register without 14971 linkage is one of the most common deficiency triggers.
• SBOM - machine-readable CycloneDX or SPDX, with transitive dependencies, suppliers, versions, and licenses. See SBOM Vulnerability Management for Medical Devices for the postmarket lifecycle expectations.
• Vulnerability Assessment / VEX - per-component triage of every CVE the SBOM surfaces, with VEX status (Not Affected, Affected, Fixed, Under Investigation) and rationale.
• Security Testing Results - SAST, SCA, fuzzing, and a full penetration test report scoped across every interface (wired, wireless, BLE, cellular, USB, cloud, service ports). Web-only pen tests are routinely rejected.
• Cybersecurity Architecture Views - all four views referenced in the FDA guidance, kept consistent with the threat model.
• Section 524B Attestation - the device meets the cybersecurity requirements of 524B(b)(1)-(3) including a plan to identify and address post-market vulnerabilities.

Section 15 - Labeling

Cybersecurity labeling is an explicit submission element. Reviewers verify that customers, IT, and security researchers have what they need to operate and report on the device.

• Cybersecurity section in IFU - supported configurations, network requirements, hardening guidance, end-of-support (EOS) dates.
• SBOM access mechanism - how customers obtain the SBOM (URL, portal, request process).
• CVD program reference - pointer to your Coordinated Vulnerability Disclosure intake.

Section 17 - Risk Analysis

Even though the security risk file lives in Section 14, Section 17 must reflect it.

• Hazard analysis updated with cybersecurity-derived hazards, harms, and residual risk.
• Bidirectional traceability between security risks (Section 14) and ISO 14971 hazards (Section 17). Reviewers spot-check this.

Section 9 - Indications for Use / Device Description

• Connectivity profile - every interface, every protocol, every cloud dependency listed. If it is not in the device description, it cannot show up in the threat model.
• Updateability statement - whether the device supports field updates, OTA, or service-only updates. Drives the updateability architecture view.

Section 23 - Postmarket (for De Novo and PMA; referenced for 510(k))

• Postmarket Cybersecurity Management Plan - operationalizes the SBOM, vulnerability monitoring sources, risk-based patch SLAs, validated update mechanism. See the Postmarket Cybersecurity Readiness Plan.
• Coordinated Vulnerability Disclosure policy - published intake, triage workflow, SLAs, alignment to ISO/IEC 29147 and 30111.

eSTAR Pre-Submission Go/No-Go Checklist

Score yourself before clicking "submit" in the eSTAR template. If you cannot check all 20, you have known gaps that FDA is likely to flag.

01 - Cybersecurity Management Plan uploaded to Section 14, lifecycle owner named.

02 - Threat model with all four architecture views, attached to Section 14, cross-referenced in Section 17.

03 - STRIDE per element (not per system), every threat tied to a control or accepted residual risk.

04 - Security Risk Assessment with explicit ISO 14971 traceability matrix.

05 - SBOM is machine-readable CycloneDX or SPDX, regenerated on the build under review.

06 - SBOM transitive dependencies included; not just direct dependencies.

07 - VEX statements for every Critical and High CVE the SBOM surfaces.

08 - SOUP analysis for each third-party component, with rationale for use.

09 - SAST/SCA configuration and results included, not just a summary statement.

10 - Penetration test report scoped across every interface declared in the device description.

11 - Fuzz testing results on protocols handling untrusted input (BLE, cellular, HL7, DICOM, MQTT, etc.).

12 - Architecture views in Section 14 match the diagrams in Section 9.

13 - Section 524B attestation signed by an authorized representative.

14 - Cybersecurity labeling in Section 15 covers configuration, network, EOS, and SBOM access.

15 - CVD policy is published at a stable URL and referenced in labeling.

16 - Postmarket cybersecurity plan named, with monitoring sources and patch SLAs.

17 - Validated update mechanism documented (signature, integrity, atomic install, rollback).

18 - Cross-references from Section 17 risk analysis back to Section 14 security risk file.

19 - File naming convention for cybersecurity attachments is consistent and reviewer-friendly.

20 - Page count discipline - each attachment has a clear purpose; no "kitchen-sink" PDFs that bury evidence.

The five eSTAR failure modes we see most often

01 - Architecture views in the threat model do not match the block diagram in Section 9. Reviewers cross-check; mismatches read as "the security team and the engineering team have different mental models."

02 - SBOM only lists direct dependencies. NTIA minimum elements require transitive dependencies. A direct-only SBOM is a near-automatic deficiency.

03 - VEX is missing or "Under Investigation" for everything. Reviewers accept "Not Affected" with rationale. They do not accept "we'll figure it out later."

04 - Pen test is web-only. If your device has BLE, cellular, USB, or a service interface, your pen test report needs sections covering each one.

05 - CVD policy linked but the URL 404s. Trivial to fix, common to ship. Test the link from a fresh browser session before submitting.

What FDA actually verifies in each section

Reviewers do not read submissions cover-to-cover. They sample. The samples are predictable: traceability between requirements, threats, controls, tests, and risk. The eSTAR sections above are the seams where that traceability lives or dies.

If you build the cybersecurity package SPDF-first and then organize it eSTAR-second, you have done the work the way FDA expects to consume it.

Where this fits in the cluster

This page sits inside our FDA premarket cluster. If you arrived here from a different starting point, these are the most useful adjacent pages:

• The SPDF Playbook for FDA-Ready Medical Devices
• FDA Premarket Cybersecurity Submission Checklist
• FDA Section 524B Cybersecurity Requirements Explained
• 12 Critical Threat Modeling Gaps in Medical Device Submissions
• SBOM Vulnerability Management for Medical Devices
• Vulnerability Disclosure Programs for Medical Devices

Related from Blue Goat Cyber

• FDA Premarket Cybersecurity Services
• eSTAR Cyber Checklist (Interactive Tool)
• Medical Device Threat Modeling
• FDA-Compliant SBOM Services
• Medical Device Penetration Testing

FAQ

Does the FDA require eSTAR for 510(k) submissions?

Yes. As of October 1, 2023, eSTAR is mandatory for all 510(k) submissions (excluding dual submissions, certain combination products, and a narrow exemption list). De Novo eSTAR became mandatory October 1, 2025. PMA still uses traditional eCopy/CDRH portal submissions but FDA has signaled eSTAR will expand.

What is the difference between eSTAR and the SPDF?

The Secure Product Development Framework (SPDF) is the engineering and QMS process that produces cybersecurity artifacts across the device lifecycle. eSTAR is the submission template that organizes those artifacts for FDA review. You need both - SPDF to build the evidence, eSTAR to deliver it.

Where in eSTAR does the SBOM go?

Section 14 (Software / Cybersecurity), as a machine-readable CycloneDX or SPDX file plus a human-readable summary. Reference it from the device description in Section 9 so reviewers can correlate components to interfaces.

What is a Section 524B attestation?

A signed statement from an authorized representative confirming the device meets the cybersecurity requirements of FD&C Act §524B(b)(1)-(3): a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits; design, develop, and maintain processes and procedures to provide a reasonable assurance of cybersecurity; and provide an SBOM. It lives in the cybersecurity section of eSTAR.

How long does cybersecurity review take inside eSTAR review?

Cybersecurity is reviewed in parallel with the rest of the submission. The full 510(k) substantive review is 90 FDA days; cybersecurity deficiencies most commonly surface in the Additional Information (AI) request around FDA day 60-75. A clean cybersecurity package can clear without an AI letter; a deficient one adds 8-12 weeks to clearance.

Sources & primary references

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (FDA, February 2026 final guidance)
• Section 524B of the FD&C Act
• eSTAR Program (FDA)
• ANSI/AAMI SW96:2023 Standard for Medical Device Security
• IEC 81001-5-1 Health Software Security Activities
• NTIA Minimum Elements for an SBOM