When sponsors open eSTAR v7.0 with the FDA's February 2026 final premarket cybersecurity guidance in hand, they hit a confusing mismatch: the guidance describes 15 cybersecurity deliverables, but eSTAR exposes only 8 Cybersecurity attachment slots. Both numbers are correct. eSTAR is a packaging template; the guidance is a content checklist. This guide shows exactly which deliverables go in which slot, what reviewers expect in each attachment, and the most common Refuse-to-Accept (RTA) trigger per slot.
Last reviewed: June 2026 against eSTAR v7.0 (nIVD and IVD templates) and the FDA final guidance issued February 26, 2026.
The mapping at a glance
| # | eSTAR v7.0 Cybersecurity slot | Guidance deliverables that go here |
|---|---|---|
| 1 | Management Plan | Cybersecurity Management Plan; SPDF / QMS integration evidence (IEC 81001-5-1, NIST SSDF); Coordinated Vulnerability Disclosure (CVD) policy |
| 2 | Risk Management | Security Risk Management File (AAMI SW96:2023) and its trace to ISO 14971 safety risk |
| 3 | Threat Model | STRIDE / TARA threat model; Architecture Views (global system, multi-patient harm, updateability, security use-case); Interoperability assumptions |
| 4 | Risk Assessment | Threat scoring; patient-harm mapping; residual-risk justifications |
| 5 | SBOM | CycloneDX or SPDX file; known-vulnerability assessment; VEX statements; KEV / EPSS cross-references |
| 6 | Controls | Authentication & access control; Cryptography inventory + key management; Patch / update mechanism (Section 524B(b)(2)); Audit logging |
| 7 | Testing | Penetration test report; SAST / DAST / fuzz results; protocol and RF testing; traceability matrix |
| 8 | Metrics | Postmarket monitoring KPIs; vulnerability-handling SLAs; patch cadence; Postmarket Cybersecurity Management Plan (Section 524B(b)(1)) |
Two guidance items do not live under Cybersecurity in eSTAR:
- Labeling for Cybersecurity is filed in the separate Labeling section.
- Cyber Device Determination is captured in the cover/administrative pages, not as a Cybersecurity attachment.
Slot-by-slot expectations
Slot 1 — Management Plan
What goes in: The Cybersecurity Management Plan describing how security is wired into your QMS lifecycle (design inputs, design reviews, V&V, change control). Reference IEC 81001-5-1 and NIST SP 800-218 (SSDF). Include your CVD policy with a published intake channel (security.txt or dedicated email) and response SLAs.
Most common RTA trigger: "Policy only" evidence with no artifacts. Reviewers want training rosters, review records, and tooling output, not a marketing PDF.
Slot 2 — Risk Management
What goes in: A security risk file aligned to AAMI SW96:2023 (FDA-recognized), with TIR57 as supporting reference. The file must be separate from ISO 14971 safety risk and explicitly map security risks to patient-harm scenarios.
Most common RTA trigger: Merging security risk into the ISO 14971 file. Reviewers want two distinct artifacts with an explicit trace between them.
Slot 3 — Threat Model
What goes in: A diagram-driven threat model — STRIDE per data-flow boundary is the most common format, TARA is acceptable when justified. Architecture Views live here, not as a separate attachment: global system view, multi-patient harm view, updateability/patchability view, and security use-case view. Cover external interfaces, wireless protocols, update mechanisms, debug/service interfaces, cloud APIs, AI/ML model endpoints, and interoperability assumptions (EHR, HL7/FHIR, adjacent devices).
Most common RTA trigger: A bullet list instead of diagrams. This is one of the four highest-frequency RTA triggers across all cybersecurity content.
Slot 4 — Risk Assessment
What goes in: The scoring layer on top of the threat model. CVSS v3.1 or v4.0 for the technical severity, plus a patient-harm mapping that translates each threat into a clinical impact. Document residual-risk acceptance.
Most common RTA trigger: Threats enumerated but never scored, or scored without a clinical-impact mapping.
Slot 5 — SBOM
What goes in: A machine-readable SBOM in CycloneDX or SPDX format with the seven NTIA minimum data fields plus dependency relationships, license, and hash. Pair it with a known-vulnerability assessment (KEV-aware) and VEX statements for unaffected CVEs.
Most common RTA trigger: No SBOM, or an SBOM that is not machine-readable. This is the #1 SBOM-related RTA trigger.
Slot 6 — Controls
What goes in: The technical-control bundle — authentication and access control (role-based, service accounts), cryptographic inventory (algorithm, mode, key length, FIPS validation status, key lifecycle), patch and update mechanism design (Section 524B(b)(2)), and audit logging (sources, retention, tamper resistance).
Most common RTA trigger: Missing patch / update mechanism description. Section 524B(b)(2) explicitly requires devices be "designed to be updated and patched" — omitting this attachment is a statutory miss.
Slot 7 — Testing
What goes in: An independent penetration test report covering every external interface and protocol (Wi-Fi, BLE, USB, NFC, cellular, web/API, mobile companion app, DICOM, HL7/FHIR). Name the tools (Nessus or OpenVAS for network, Burp Suite for web/API, protocol-specific fuzzers, RF tooling where applicable). Include the traceability matrix that maps security requirement → design element → V&V test → residual risk.
Most common RTA trigger: Pen test scope that does not match the interface inventory in Slot 3.
Slot 8 — Metrics
What goes in: The Postmarket Cybersecurity Management Plan (Section 524B(b)(1)) and the KPIs you will report against it: SBOM maintenance cadence, vulnerability monitoring sources, patch SLA by severity, customer notification process, CAPA integration.
Most common RTA trigger: A plan that reads like a one-page commitment rather than something a different team could execute on day one of postmarket.
Why the mismatch exists
The 2026 guidance describes content: 15 distinct deliverables, each with its own standard (AAMI SW96, IEC 81001-5-1, NIST SSDF, NTIA SBOM minimum elements, Section 524B statutory items). eSTAR v7.0 is a template: it bundles related deliverables into 8 attachment slots to keep the package navigable for reviewers.
Architecture Views, for example, are a guidance deliverable in their own right, but in eSTAR they live inside the Threat Model attachment because the views are how reviewers verify the threat model's scope. The Controls slot bundles four guidance items (auth, crypto, patch/update, logging) because they share an evaluation pattern.
The practical implication: build to the 15 deliverables, then package to the 8 slots. If you build only to the 8 slot names, you will under-deliver on the underlying content.
Pre-submission cross-check
Before you hit submit in eSTAR, verify each slot against this list:
- Every slot has at least one attachment, and the attachments are named to match the slot.
- Architecture Views are inside Slot 3, not filed separately.
- Labeling cybersecurity content is in the Labeling section, not duplicated into Cybersecurity.
- The SBOM is machine-readable (open it in a parser, not just a text editor).
- The traceability matrix in Slot 7 references the threat IDs from Slot 3 and the risk IDs from Slot 4.
- The Postmarket plan in Slot 8 is executable by a team that did not write it.
For a deeper section-by-section walkthrough, see the eSTAR Cybersecurity Readiness Checklist and the FDA Premarket Cybersecurity Submission Checklist (2026). For the underlying guidance summary, see The FDA's February 2026 Premarket Cybersecurity Guidance, Summarized.
FAQ
Is eSTAR mandatory for cybersecurity content?
For 510(k) submissions, yes — eSTAR is mandatory and the Cybersecurity attachments must be populated. De Novo submissions are increasingly on eSTAR as well. PMA submissions use a different packaging model but the same 15 underlying deliverables apply.
Where do Architecture Views go in eSTAR v7.0?
Inside the Threat Model attachment (Slot 3). There is no standalone Architecture Views slot in eSTAR v7.0. Reviewers expect the multiple views (global, multi-patient harm, updateability, security use-case) bundled with the threat model so they can verify the model's scope.
Where does Labeling go?
In the separate Labeling section of eSTAR, not under Cybersecurity. Cybersecurity-specific labeling content (controls list, secure-configuration description, network ports, SBOM pointer, CVD intake, end-of-support date, environment assumptions) belongs there.
Does eSTAR v7.0 satisfy the February 2026 guidance on its own?
No. eSTAR is a packaging template; it does not validate the content quality of your attachments. A submission can pass the eSTAR completeness check and still draw an RTA hold or a deficiency letter if the attachments are weak. Build to the 15 guidance deliverables, then package to the 8 eSTAR slots.
What are the highest-frequency RTA triggers across the 8 slots?
Across hundreds of reviewed submissions, the four highest-frequency triggers are: no machine-readable SBOM (Slot 5), missing vulnerability management content in the Management Plan (Slot 1), missing pen test report or scope mismatch (Slot 7), and a threat model that is a bullet list rather than a diagram-driven analysis (Slot 3).
How Blue Goat Cyber helps
We package every artifact in the 15-deliverable list and load it into the correct eSTAR v7.0 slot for you — and we stay through deficiency response if a letter lands. See FDA premarket cybersecurity services.
Sources & primary references
- FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (final guidance, February 2026)
- FDA, eSTAR templates — nIVD eSTAR v7.0 and IVD eSTAR v7.0
- Section 524B of the Federal Food, Drug, and Cosmetic Act
- AAMI SW96:2023 — Standard for medical device security — Security risk management
- IEC 81001-5-1:2021 — Health software and health IT systems safety, effectiveness and security
- NIST SP 800-218 — Secure Software Development Framework (SSDF)
- NTIA, Minimum Elements for a Software Bill of Materials (SBOM)