Since October 1, 2023, the FDA has required most 510(k) submissions to use the eSTAR electronic submission template, and the CDRH Portal automatically checks every section for completeness before a human reviewer ever opens the file. The cybersecurity section is where submissions stall most often. Section Q is not a generic upload field where you drop in whatever documentation you have assembled. It maps to specific artifacts, formatted in specific ways, cross-referenced against the February 2026 premarket cybersecurity guidance that supersedes every earlier version.
Teams that treat Section Q as a formality discover the problem weeks into review, sometimes in the form of a deficiency letter, sometimes through a Refuse to Accept determination that restarts the clock entirely. Neither outcome is acceptable when you are racing to market. This guide walks through the electronic submission template for medical device cybersecurity section by section, explains what documentation goes where, and closes with a checklist you can run before submission day.
How the FDA eSTAR template is organized and where cybersecurity lives
The eSTAR template is a structured PDF-based form with labeled sections covering submission type, applicant information, device classification, predicate comparisons, software and firmware documentation, safety testing results, and cybersecurity. The sections are sequential in the document, but FDA reviewers navigate directly to the areas relevant to their discipline. The cybersecurity reviewer goes straight to Section Q, which means that section has to stand on its own. You cannot assume the reviewer has read the software section or the safety testing section before arriving at your cybersecurity content.
The Software/Firmware section earlier in the template does intersect with Section Q, specifically around software architecture and device functionality. The safest approach is to keep detailed cybersecurity-specific content in Section Q and use brief cross-references in the software section rather than duplicating content. Contradictions between the two sections are a fast path to a deficiency request, and reviewers do check for consistency.
Section Q references the FDA’s premarket cybersecurity guidance by name, and the most current version is dated February 3, 2026. Any documentation you prepare must align with that version. Submissions built against the 2023 guidance are not automatically noncompliant, but gaps introduced by the 2025 updates will surface during review.
What Section Q requires: mapping cybersecurity artifacts to eSTAR template fields
Section Q opens with a security architecture description. This field requires documented network interfaces, data flows, trust boundaries, and attack surface diagrams. Reviewers expect structured visual documentation here, not prose summaries. A narrative paragraph describing the device’s connectivity is not a substitute for a labeled architecture diagram showing where data enters and exits the device, which components communicate externally, and where trust boundaries are enforced.
Threat modeling requirements
Threat modeling documentation lives in Section Q alongside the architecture content. The FDA expects a structured framework such as STRIDE, with explicit mapping from identified threats to mitigations. A threat model is a forward-looking analysis that asks what an attacker could do at each interface and what design decisions prevent or reduce that harm, not a risk register cataloging past findings. Tables work better than paragraphs here, both for reviewer navigation and for demonstrating completeness.
SBOM requirements
The SBOM is mandatory for any device with software components and attaches directly to Section Q. The FDA references the NTIA Minimum Elements as its baseline, which means your SBOM needs supplier name, component name, version, unique identifier (such as a Package URL or CPE), dependency relationships, SBOM author, and timestamp for every component. Machine-readable formats like SPDX or CycloneDX satisfy the format requirement, but a human-readable version should accompany it.
For practical guidance on SBOM format and content expectations, see this resource on Medical Device SBOM: FDA Requirements and Submission Guide. The SBOM connects directly to the vulnerability management plan. Reviewers check whether the vulnerability status of each component listed in the SBOM is reflected accurately in the plan, a mismatch between the two is a reliable deficiency trigger.
Vulnerability management plan
The vulnerability management plan belongs in Section Q as well. The FDA expects a formal coordinated vulnerability disclosure (CVD) policy and a documented secure update mechanism, not a general statement about your commitment to patching. How will you receive vulnerability reports? How will you assess their severity? What is your update deployment process, and how is that process cryptographically verified? Those specifics belong in this plan.
SPDF documentation and secure design evidence in eSTAR
The Secure Product Development Framework document demonstrates that cybersecurity was built into the device from the earliest design phase, not assembled at submission time. Reviewers can usually tell the difference. An SPDF document that appears weeks before a submission deadline and references no design history file artifacts, no design control checkpoints, and no evidence of iterative security testing reads as a document written to check a box.
A complete SPDF submission covers risk identification processes, design controls under 21 CFR Part 820, lifecycle vulnerability management procedures, and concrete evidence of secure-by-design implementation. That last category includes cryptographically signed software updates, role-based access control specifications tied to actual user roles in the device’s clinical context, and event logging mechanisms with tamper-resistant storage. These are design features that should trace back to the device’s requirements documentation, not theoretical commitments added late in development.
SPDF documentation is submitted as an attachment to Section Q with a cross-reference in the field. Structure the document so reviewers can verify each element without navigating a large unstructured PDF. Section headings that mirror the eight security categories from the June 2025 guidance, device identification, authorization, data protection, system integrity, malware protection, secure communications, security monitoring, and configuration management, make the reviewer’s job straightforward and reduce the likelihood of a follow-up question about missing content.
For cyber devices under section 524B of the FD&C Act, the SPDF is not optional. The statute requires manufacturers to establish and maintain a cybersecurity risk management program, and the SPDF documentation is the primary evidence that such a program exists and functions as designed.
Penetration testing and file formatting: what FDA reviewers actually check
The FDA expects a full-scope penetration test report, not an executive summary and a list of findings. Full scope means the report covers abuse and misuse cases, fuzz testing, static and dynamic code analysis, vulnerability chaining, and attack surface analysis. The test methodology section needs enough detail that a reviewer could assess whether the test was thorough and repeatable. Vague methodology descriptions are a deficiency trigger.
Every finding in the report needs a disposition. This point deserves emphasis because it is the most common formatting mistake. A finding labeled “Low” or “Medium” severity with no documented rationale for acceptance, no mitigation evidence, and no remediation timeline is treated by reviewers as an unresolved vulnerability, regardless of its severity rating. The remediation status column in your findings table should show one of three things: the finding was remediated (with evidence), the finding was mitigated to acceptable residual risk (with the rationale), or the finding was accepted (with documented justification tied to the device’s clinical context and patient safety impact).
File formatting requirements for all cybersecurity attachments are specific and enforced by the eSTAR system. PDF is the required format. PDFs must use embedded fonts, conform to PDF 1.4, 1.7, or PDF/A-1a standards, and have no security restrictions on printing or content extraction. File names must be alphanumeric only, with no spaces or special characters, and must stay within the directory path length limits enforced by the template. Internal bookmarks and hyperlinks within PDFs are expected so reviewers can navigate directly from a Section Q field cross-reference to the relevant section of an attached document without scrolling through hundreds of pages.
Common cybersecurity deficiencies and how to prevent them
Incomplete threat modeling is the most frequently cited deficiency in cybersecurity reviews. The failure mode is usually scope: manufacturers model threats against the primary use case and ignore edge cases, maintenance interfaces, third-party integrations, and physical access scenarios. A threat model that addresses only remote network attacks on a device that also has a USB port, a Bluetooth interface, and a service technician mode will draw a deficiency letter.
Missing or weak authentication controls appear regularly in deficiency letters. Reviewers flag the absence of role-based access differentiation where different user classes, clinician, administrator, service technician, have equivalent system access. The June 2025 guidance is explicit about this expectation, and Appendix 1 of the guidance functions as a mandatory checklist in practice. Treating any item in Appendix 1 as optional, particularly event detection and logging or cryptographic implementation, without a documented technical justification for the omission will trigger a flag. For more context on why deficiency letters matter and how they are being issued, see this analysis on [deficiency letters and their implications](https://www.medcrypt.com/blog/fda-is-issuing-deficiency-letters, why-you-should-care-part-1-4).
The Refuse to Accept policy, in effect since October 1, 2023, adds a layer of risk that didn’t exist before. The FDA turns away submissions with an incomplete or inaccurate cybersecurity section before substantive review begins. “Inaccurate” includes checkbox responses in Section Q that don’t match the attached documentation. A submission that checks “yes” to having a vulnerability management plan but attaches a document that omits a CVD policy or a secure update mechanism description is an inaccurate response. A technical screening hold restarts the review clock, and in a competitive market, that delay is measured in millions.
Your electronic submission template medical device cybersecurity checklist
Use this list as a pre-submission verification tool before the file goes to the CDRH Portal. It covers the minimum expected content for Section Q. It does not guarantee clearance, but it materially lowers the risk of a technical screening hold or early deficiency request.
- Security architecture diagram with labeled network interfaces, data flows, and trust boundaries
- Threat model document using a structured framework (STRIDE or equivalent) with explicit mitigation mapping for each identified threat
- SBOM listing all software components with supplier, version, unique identifier, dependency relationships, and known vulnerability status at time of submission
- Penetration test report with full methodology, findings table, and documented remediation disposition for every finding at every severity level
- SPDF documentation covering the full device development lifecycle with traceability to design controls
- Vulnerability management plan including a formal CVD policy and a secure update mechanism description
- Postmarket monitoring and patching plan with defined timelines and escalation procedures
- Cybersecurity labeling section addressing user configuration responsibilities and security maintenance
- All attachments in PDF format, alphanumeric file names only, internal bookmarks for all cross-referenced sections
Blue Goat Cyber builds complete cybersecurity documentation packages mapped field by field to the eSTAR electronic submission template, from threat model to SBOM to penetration test report. Every deliverable is structured to align with what reviewers verify against the A Guide to FDA’s Cybersecurity Documentation Requirements. Documentation structured this way correlates with fewer deficiency letters and faster review cycles. For manufacturers preparing their first 510(k) or responding to a cybersecurity deficiency, that kind of precision at the field level is what keeps the review moving on schedule.
The electronic submission template for medical device cybersecurity: building a submission that moves through review
The FDA eSTAR electronic submission template is not a generic upload portal, and Section Q is not a place to drop a collection of cybersecurity documents assembled the week before submission. Each field maps to a specific artifact with a specific expected format, and reviewers verify those artifacts against the current guidance before substantive review even begins. For an overview of the current electronic submission template and how fields are organized for 510(k) submissions, see this guide to FDA electronic submissions for 510(k).
Missing a field, submitting a penetration test report without remediation dispositions, or attaching an SBOM that doesn’t address known vulnerability status invites a deficiency letter or a refuse-to-accept determination. The checklist above gives you a baseline. The real protection comes from building medical device cybersecurity documentation that maps precisely to each eSTAR template field from the start. Firms like Blue Goat Cyber do exactly that for medical device manufacturers who cannot afford delays eating into their launch timeline. For guidance on vendor selection, see How to Choose a Cybersecurity Firm for FDA Submissions.