eSTAR cyber readiness

eSTAR Cybersecurity Section Checklist

Sixteen artifacts FDA reviewers look for in the eSTAR cybersecurity sections. Check what you have; we show you what's missing and where it goes.

Reviewed by

Christian Espinosa

Founder & CEO, Blue Goat Cyber

Last reviewed June 10, 2026

0 of 16 artifacts ready0% complete

Cybersecurity cover-letter section mapping each §524B artifact to its eSTAR location

Cover Letter · Reviewers triage by cover letter; a missing map = AI request.

Cybersecurity section of the IFU: intended environment, user responsibilities, security update process

Labeling (IFU) · Required for §524B-eligible devices and any networked device.

Completed MDS² (Manufacturer Disclosure Statement for Medical Device Security)

Labeling · Hospital procurement and reviewers both expect this.

ISO 14971 risk file with cybersecurity hazards linked to threat model

Risk Analysis · Cyber risk must roll into the device risk file, not live separately.

STRIDE or PASTA threat model with traceability to interfaces, assets, and controls

Cybersecurity - Threat Model · AAMI TIR57 / SW96 aligned - the #1 deficiency-letter trigger.

Security architecture views: data flow, trust boundaries, interfaces, third-party components

Cybersecurity - Architecture · Reviewers need a picture before they read controls.

Security controls table mapped to threats, with verification evidence per control

Cybersecurity - Controls · 'We use TLS' is not a control; the mapping is the control.

Machine-readable SBOM (SPDX 2.3+ or CycloneDX 1.5+) covering all components incl. transitive + OS

Cybersecurity - SBOM · Statutory under §524B.

VEX statements (or equivalent) for known CVEs in the SBOM

Cybersecurity - SBOM · Without VEX, every CVE looks open.

Independent penetration test report with CVSS-rated findings and remediation evidence

Cybersecurity - Testing · Reviewers expect third-party, not internal-only, testing.

Fuzz and abuse-case testing evidence for interfaces and parsers

Cybersecurity - Testing · Required for cyber devices, called out in 2026 guidance.

Postmarket monitoring & patching plan with SLAs by severity

Cybersecurity - Postmarket · Statutory under §524B.

Published Coordinated Vulnerability Disclosure (CVD) policy + security contact

Cybersecurity - Postmarket · Statutory under §524B; reviewers will check the URL.

Secure software update mechanism description (signing, rollback, customer notification)

Cybersecurity - Postmarket · Must show how patches actually reach the field safely.

PCCP that explicitly covers cybersecurity impact of authorized changes

Cybersecurity - AI/ML (if applicable) · AI/ML modifications can change attack surface; PCCP must address it.

Traceability matrix: requirement → threat → control → verification

Cybersecurity - Traceability · Most efficient way to pre-empt deficiency questions.

What you'll see after you submit

Check what you have - see the eSTAR cyber readiness ring

RingScore infographic showing the percentage of the 16 cyber artifacts you have ready.
Per-artifact list of what's ready vs. missing, with the eSTAR section number for each.
Reviewer-aligned definition of 'ready' so a half-done draft doesn't count as complete.
Print-to-PDF audit trail for your internal submission-readiness review.

Common misconceptions

Myth: eSTAR auto-validates our cybersecurity content.

Reality: eSTAR validates structure and required attachments, not content quality. A PDF named 'SBOM.pdf' that's actually a screenshot will pass eSTAR and fail RTA review.
Myth: All 16 artifacts must be one document each.

Reality: Some sections accept consolidated documents (e.g., security risk management report can roll up threat model + SBOM analysis). The checklist shows acceptable consolidations.
Myth: The architecture diagram is for context, not review.

Reality: Reviewers literally trace threats and controls on your diagram. A vague network diagram is the #1 cause of follow-up AI letters in cybersecurity sections.
Myth: If we use a Premarket Cybersecurity Decoder, eSTAR is done.

Reality: Decoders map content to sections; they don't generate the content. You still need each artifact to exist, be current, and match the rest of the submission.