eSTAR v7.0 Cybersecurity Attachments: How the 8 Slots Map to the FDA's 2026 Guidance

eSTAR v7.0 gives you one Cybersecurity attachment area; the FDA's February 2026 final premarket cybersecurity guidance describes 15 deliverables that all need to land there. The template does not enforce a named slot per deliverable - that part is on you. This guide is the packaging we use: 8 named attachment groupings inside the Cybersecurity area, the guidance deliverables that go in each, and the most common Refuse-to-Accept (RTA) trigger per grouping. It is a recommended structure, not a template-defined one - but reviewers consistently respond well to it because it matches how the 2026 guidance reads.

Last reviewed: June 2026 against eSTAR v7.0 (nIVD and IVD templates) and the FDA final guidance issued February 26, 2026. The template-level v6.2 → v7.0 diff and migration checklist are consolidated into this page (see What changed from v6.2 to v7.0 below).

A note on "slots": eSTAR v7.0 itself does not expose 8 named cybersecurity attachment slots - the template has one Cybersecurity subform (plus a new short Controls free-text field in v7.0). The 8 groupings below are our recommended packaging of the guidance deliverables into clearly named attachments. Build to the 15 guidance deliverables; package to the 8 groupings; file into the single Cybersecurity attachment area.

The mapping at a glance

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.

Section-by-section expectations

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.

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.

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.

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.

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.

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.

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 the Threat Model section.

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 section against this list:

1. Every section has at least one attachment, and the attachments are named to match the section.
2. Architecture Views are inside the Threat Model section, not filed separately.
3. Labeling cybersecurity content is in the Labeling section, not duplicated into Cybersecurity.
4. The SBOM is machine-readable (open it in a parser, not just a text editor).
5. The traceability matrix in the Testing section references the threat IDs from Threat Model and the risk IDs from Risk Assessment.
6. The Postmarket plan in Metrics is executable by a team that did not write it.

For the underlying guidance summary, see FDA cybersecurity guidance and the FDA Premarket Cybersecurity Submission Checklist (2026).

eSTAR section → cybersecurity artifact map {#estar-section-map}

The 8 groupings above describe what goes into the Cybersecurity attachment area. This section describes where else in the eSTAR template cybersecurity content has to appear, because reviewers cross-check Sections 9, 15, 17, and 23 against the Cybersecurity section.

Section 14 - Software / Cybersecurity (the anchor)

Roughly 80% of the cybersecurity package lives here. Every attachment should 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).
• 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.
• 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.
• Coordinated Vulnerability Disclosure policy - published intake, triage workflow, SLAs, alignment to ISO/IEC 29147 and 30111.

The five eSTAR failure modes we see most often {#failure-modes}

1. 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."
2. SBOM only lists direct dependencies. NTIA minimum elements (now stewarded by CISA) require transitive dependencies. A direct-only SBOM is a near-automatic deficiency.
3. VEX is missing or "Under Investigation" for everything. Reviewers accept "Not Affected" with rationale. They do not accept "we'll figure it out later."
4. 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.
5. CVD policy linked but the URL 404s. Trivial to fix, common to ship. Test the link from a fresh browser session before submitting.

eSTAR pre-submission go/no-go checklist {#go-no-go}

Score the package before you click submit in the eSTAR template. If you cannot check all 20, you have known gaps the FDA is likely to flag.

1. Cybersecurity Management Plan uploaded to Section 14, lifecycle owner named.
2. Threat model with all four architecture views, attached to Section 14 and cross-referenced in Section 17.
3. STRIDE per element (not per system), every threat tied to a control or an accepted residual risk.
4. Security Risk Assessment with an explicit ISO 14971 traceability matrix.
5. SBOM is machine-readable CycloneDX or SPDX, regenerated on the build under review.
6. SBOM transitive dependencies included, not just direct dependencies.
7. VEX statements for every Critical and High CVE the SBOM surfaces.
8. SOUP analysis for each third-party component, with rationale for use.
9. 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).
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, end-of-support, and SBOM access.
15. CVD policy 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 the Section 17 risk analysis back to the 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.

Reviewers do not read submissions cover to cover; they sample, and the samples are predictable: traceability between requirements, threats, controls, tests, and risk. Build the package SPDF-first and organize it eSTAR-second and you have done the work the way the FDA expects to consume it.

What changed from eSTAR v6.2 to v7.0 {#v62-to-v70}

eSTAR v7.0 released June 1, 2026 and v6.2 retires August 3, 2026. Once you receive an FDA acknowledgment letter, your submission is grandfathered to the version you submitted on; AI and Technical Screening responses must use that same version.

Template-level cybersecurity changes (verified by diffing the XFA form definitions of both nIVD templates):

1. New Controls child subform inside Cybersecurity - one new free-text field for describing security controls inline rather than only via attachment.
2. Digital Health Resources bullet list reorganized - now pairs Cybersecurity with Interoperability explicitly and adds MMA, SaMD, AI/ML, MDDS, CDS, and Cloud Computing as categories.
3. Recognized Consensus Standards list refreshed - adds AAMI CR515:2025 (ML cybersecurity) and reformats IEEE 11073-40101/40102 entries. These are dropdown updates, not new question fields.

What did not change at the template level: no eight named attachment slots, no dedicated Metrics field, no Architecture Views field, no separate VEX upload field, and AAMI SW96:2023 is not explicitly named in a template caption. Those expectations live in the February 2026 guidance, not in v7.0 template fields - and submissions get held when they aren't met regardless.

What changed outside the Cybersecurity subform

These v7.0 changes still land on cybersecurity teams even though they sit outside the Cybersecurity section:

• Human Factors subsection added to Performance Testing. Cybersecurity-relevant human-factors content (usable authentication, alarm and notification handling, secure-update UX) now has a home there per the May 29, 2026 Human Factors Content Guidance (effective August 1, 2026).
• Standards / Additional Information ordering adjusted in several sections, including Cybersecurity-adjacent ones.
• PMA Facility Information added, relevant if your cybersecurity package is going into a PMA.
• Adobe rendering bug fix so attachments behave more consistently, useful when you carry many cybersecurity attachments.

Transition timing

• v7.0 released: June 1, 2026
• v6.2 retirement date: August 3, 2026
• After August 3, 2026 the FDA still accepts v6.2 submissions, but says they may draw additional information requests for content covered by v7.0 changes.
• Grandfathering: once you receive an FDA acknowledgment letter, the submission is locked to the version you filed on. AI and Technical Screening responses must use that same version.

Should you refile?

Cybersecurity migration checklist (v6.2 → v7.0)

If you are moving an in-progress v6.2 package to v7.0:

1. Populate the new Controls free-text field inside the Cybersecurity subform with a one-paragraph summary of your security-controls attachment (auth, crypto, patch/update, logging) so reviewers see the map inline.
2. Re-check Recognized Consensus Standards selections. Some cybersecurity-relevant entries were refreshed in v7.0 - re-pick your standards in the new dropdowns rather than carrying over assumed values.
3. Move any human-factors content that touches authentication, alarms, or secure-update UX into the new Performance Testing → Human Factors subsection and reference it from your cybersecurity controls write-up.
4. Keep your attachment package intact. v7.0 did not change the Cybersecurity attachment slot - your existing Management Plan, Security Risk file, Threat Model, SBOM, Controls, Testing, and Postmarket Plan attachments all still go in the same place.
5. Build to the Feb 2026 guidance, not just to the template. The template will let you submit a thin package; the guidance is what reviewers grade against.

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. There is no standalone Architecture Views section 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 sections.

What are the highest-frequency RTA triggers across the 8 sections?

Across hundreds of reviewed submissions, the four highest-frequency triggers are: no machine-readable SBOM (SBOM), missing vulnerability management content in the Management Plan, missing pen test report or scope mismatch (Testing), and a threat model that is a bullet list rather than a diagram-driven analysis (Threat Model).

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 vulnerabilities and exploits; processes and procedures providing a reasonable assurance of cybersecurity; and an SBOM. It lives in the cybersecurity section of eSTAR. See the Section 524B requirements guide.

How long does cybersecurity review take inside eSTAR review?

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

Do the cybersecurity artifacts themselves change between v6.2 and v7.0?

No. The threat model, SBOM, security risk assessment, pen test report, and postmarket monitoring plan do not change in substance. What changes is how they are attached and cross-referenced. Content built to the February 2026 guidance is portable across template versions; only the mapping needs rework, typically two to four weeks for a complete v6.2-era package.

Should we resubmit a cleared v6.2 device to bring it onto v7.0?

No. eSTAR version applies to new submissions and material changes. A cleared device does not need resubmission because the template updated. Postmarket obligations under Section 524B(b)(2) run against the current guidance regardless of which template the original submission used.

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.

In practice that means four things:

• A slot-by-slot attachment map before anything is written. We agree the eSTAR destination for every artifact at kickoff, so no deliverable is authored without a known home and nothing lands in a general attachments bucket where reviewers will not look for it.
• Traceability built during authoring, not reconstructed at the end. Threat IDs carry through the risk assessment, the control list, and the test reports, so the cross-references a reviewer follows are correct on the first pass.
• A pre-submission dry run against the form. We complete the cybersecurity sections of the eSTAR as though filing, which surfaces the mismatches (an answered "yes" with no attachment, a labeling section that contradicts the architecture) while there is still time to fix them.
• Deficiency response continuity. The team that authored the package writes the response, so a letter does not turn into a re-education exercise for a new vendor.

See FDA premarket cybersecurity services.

Sources & primary references

• FDA, Cybersecurity in Medical Devices: Quality Management 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)