eSTAR v7.0 Cybersecurity Attachments Mapped to 2026 Guidance

eSTAR v7.0 gives you a Cybersecurity section with its own fields; a cyber device submission needs 18 deliverables that all need to land in the right one. Several deliverables share a field (all testing artifacts go under Cybersecurity Testing, for example), so how you name and split attachments is on you. This guide is the packaging we use: 8 named attachment groupings across the Cybersecurity fields, 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 3, 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": the 8 groupings below are our recommended packaging, not eSTAR field names. The template's own fields are listed field by field in our deliverables and eSTAR v7.0 map. Build to the 18 deliverables; package to the 8 groupings; file each attachment in the matching eSTAR field, one artifact per attachment.

What is FDA eSTAR?

eSTAR stands for electronic Submission Template And Resource. It is the FDA's free, interactive PDF template for preparing medical device premarket submissions. Instead of assembling a submission as a loose set of documents with a cover letter, the sponsor works through a guided form. The form asks device-specific questions, shows or hides sections based on earlier answers, and flags required attachments before anything is sent.

The FDA built eSTAR to make submissions more complete and consistent, so reviewers spend less time chasing missing items. For sponsors, the practical benefit is that the template itself catches many gaps that would otherwise surface as a refuse-to-accept (RTA) decision or an early deficiency.

Who has to use it

eSTAR has been required for most 510(k) submissions since October 1, 2023, and for De Novo requests since October 1, 2025. Some other submission types, such as Pre-Submissions, can use it voluntarily. Completed eSTARs are sent to the FDA electronically through the CDRH Portal. Always download the current template from the FDA's website before starting, because the agency revises it regularly and older versions may no longer be accepted.

How eSTAR review differs from a traditional submission

Because eSTAR builds completeness checks into the template, the FDA runs a short technical screening on eSTAR submissions instead of the older RTA checklist review. If required content is missing, the submission can be placed on hold before substantive review begins. That is why cybersecurity content that is thin, mislabeled or scattered across unrelated attachments is costly: it stops the clock early, before a reviewer ever reads your threat model.

Where cybersecurity fits

For a device that meets the Section 524B definition of a cyber device, eSTAR asks whether the device has cybersecurity risks and then opens the Cybersecurity section. That section is where the documentation described in the FDA's February 3, 2026 final premarket cybersecurity guidance belongs: the security risk management report, threat model, architecture views, SBOM, testing evidence, labeling content and the postmarket vulnerability management plan. Other sections, such as software, labeling and risk analysis, should point back to it clearly.

Common eSTAR mistakes to avoid

• Answering the cyber device question "no" for a device with any connectivity, including USB or Bluetooth.
• Uploading one large combined PDF with no clear file names or bookmarks.
• Leaving the SBOM without support status and end-of-support dates for each component.
• Filing test reports that never reference the threat model they are meant to verify.

The rest of this guide shows how we package each cybersecurity deliverable so it lands in the right place the first time.

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: 18 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: several deliverables share an eSTAR field, so we organize related deliverables into 8 named groupings 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 grouping bundles four guidance items (auth, crypto, patch/update, logging) because they share an evaluation pattern.

The practical implication: build to the 18 deliverables, then package to the 8 groupings. If you build only to the 8 grouping 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

The 8 groupings above describe what goes into the Cybersecurity section. 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

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 (superseded by CISA's 2026 Minimum Elements for an SBOM, published July 29, 2026) 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

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

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: the underlying deliverables are the same, there is no separate VEX upload field, and AAMI SW96:2023 is not explicitly named in a template caption. For the full field list, including Cybersecurity Metrics and Architecture Views, see the deliverables and eSTAR v7.0 map.

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
• Current version: v7.1 (nIVD and IVD), released September 21, 2026, a minor update. The FDA says minor updates typically do not trigger additional information requests, so a package built on v7.0 does not need rework. Download the current template from the FDA eSTAR program page.
• What v7.1 changed: According to the version history inside the template, v7.1 tightens administrative data to match changes in the CDRH login process (extra checks and a US state dropdown), removes the optional Intended Population question from Indications for Use, adds a note on handling Human Factors in Special 510(k)s, fixes a Human Factors display issue in pre-2018 Adobe Acrobat, and makes minor EMC edits (EMC information covers the whole system, wireless power transfer is no longer listed as a common emitter, and RTCA DO-160 specs may be marked N/A). It makes no changes to the cybersecurity section, so the mapping in this guide applies to v7.0 and v7.1 alike.
• 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 18 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 18 deliverables, then package to the 8 groupings.

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 18-deliverable list and load it into the correct eSTAR v7.0 field 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)

Free tools for this

• eSTAR Cybersecurity Checklist - walk the cybersecurity attachment contents before you lock the eSTAR.