eSTAR 510(k) Cybersecurity Documentation

Part of our FDA 2026 medical device cybersecurity submission series. For the full overview, start with FDA Cybersecurity Requirements for Medical Devices (2026).

Prepare the package against the applicable eSTAR prompts, statutory requirements, and device-specific evidence recommendations. Technical screening checks completeness; substantive review assesses evidence adequacy. The cybersecurity guidance does not establish a ranking of deficiency causes or a guaranteed review delay.

This guide walks through every cybersecurity artifact the FDA expects for a new 510(k) submission, section by section, so you can build a complete package the first time. At Blue Goat Cyber, we have supported 275+ devices with zero cyber-related rejections, backed by our FDA cybersecurity deficiency-response commitment. What follows is exactly what goes inside one of those packages.

Why this matters

Missing or inconsistent cybersecurity evidence can lead to technical-screening questions or substantive deficiencies. The February 3, 2026 guidance recommends a structured, lifecycle-based approach; Section 524B supplies applicable statutory duties for cyber devices.

Distinguish technical screening from substantive review. An Additional Information request is not an administrative completeness determination. Map each applicable prompt to evidence and identify gaps before submission.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); CISA Software Bill of Materials resources; FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B).

Does Your Device Qualify as a "Cyber Device" Under Section 524B?

Section 524B of the FD&C Act defines a cyber device as one that meets all three of the following criteria: it includes software validated, installed, or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. The FDA interprets "ability to connect" broadly. Assess direct and indirect internet capability in the device configuration. A service port or wireless interface alone does not establish that all three statutory criteria are satisfied. This determination is the first decision point in your submission strategy.

If your device qualifies as a cyber device, the documentation tier you need depends on whether you're submitting a new device or a modification. New submissions and security-impacting modifications require the full artifact set described throughout this guide. Non-security-impacting modifications require a lighter package focused on the SBOM, a Software Component Risk Management Report, and supporting risk documentation. Document the impact analysis supporting a modification classification. Reviewers will look for explicit justification, for example, a documented impact analysis tracing the change through your risk assessment, and "we didn't change any security features" is not sufficient without that supporting analysis.

How the eSTAR Template Structures Cybersecurity Requirements

eSTAR v7.1 (used for both the non-IVD and IVD templates) has a Cybersecurity section with its own fields, such as the threat model, risk assessment, SBOM, metrics, testing, and management plan. Several deliverables share a field (all testing artifacts go under Cybersecurity Testing, for example), so how you name and split attachments is up to the sponsor: one clearly named attachment per artifact. Blue Goat Cyber uses an 18-item organizational checklist; the FDA does not require exactly 18 separate documents. The packaging we use groups them as: management plan, security risk management, threat model with architecture views, risk assessment, SBOM, security controls, testing, and metrics. Labeling content goes in the Labeling fields. See our deliverables and eSTAR v7.1 map for the field-by-field list, and our eSTAR v7.1 cybersecurity mapping guide for the packaging.

For new submissions and security-impacting modifications, statutory information and applicable recommended evidence should be addressed. Technical screening checks eSTAR completeness; substantive review assesses the adequacy of the device-specific evidence. The core artifact set includes:

• Security Risk Management Plan
• Threat Modeling and Security Architecture Report
• Cybersecurity Risk Assessment Report
• Software Bill of Materials (SBOM)
• SBOM Support Report

Those five documents form the foundation. Each one must be device-specific, not adapted from a template without substantive modification, and not written to describe what you plan to do rather than what you did. Reviewers are trained to spot documentation that reads like a generic framework, and it frequently generates AI requests.

Building Your Core Documentation: Threat Model, Risk Assessment, and SPDF Evidence

The Threat Modeling and Security Architecture Report is the backbone document the rest of your package references. It must identify your device's attack surface, document threat scenarios using STRIDE or an equivalent methodology, map threats to device assets, and include architectural diagrams showing trust boundaries and data flows. FDA reviewers expect to see how the threat model drove design decisions. A threat model that exists as a standalone enumeration exercise, with no visible connection to the controls you implemented or the tests you ran, may generate an AI request.

The Cybersecurity Risk Assessment Report must capture identified vulnerabilities, including any relevant entries from CISA's Known Exploited Vulnerabilities Catalog, with likelihood and impact scoring, applied mitigations, and residual risk justification aligned to ISO 14971. The direct link between risks in this report and controls verified in your test reports is what reviewers look for first. A risk assessment that doesn't trace forward to testing is treated as incomplete, regardless of how thorough the analysis itself is.

SPDF documentation is where many submissions fall short. Reviewers aren't looking for a policy document that describes what your security process looks like in theory. They're looking for evidence that security was addressed throughout the development lifecycle: QMS procedures for security, design controls tied to cybersecurity requirements, and traceability showing that security was built in rather than added at submission time.

Labeling is part of the SPDF record, not an afterthought. It must include a vulnerability reporting contact, expected software support duration, and connectivity disclosures, all consistent with the FDA's premarket cybersecurity guidance expectations for transparency and post-market support.

SBOM Requirements: Format, Fields, and the Support Report

SPDX vs. CycloneDX: Choosing Your Format

The FDA recommends a machine-readable SBOM in an industry-accepted format; it does not name a format or version. SPDX and CycloneDX are common implementation choices, not exclusive FDA-approved options. CISA's July 29, 2026 SBOM minimum elements supersede the NTIA 2021 version. Include supporting component support-level and end-of-support information recommended by the FDA.

Human-Readable Exports

A human-readable export can help readers inspect the machine-readable data; it is not a universal separate statutory requirement. Include both a PDF or Excel version and the machine-readable artifact in your submission package.

The SBOM does not stand alone. The SBOM Support Report documents how the SBOM was generated, what tooling was used, and how vulnerabilities within listed components were assessed for device-level impact. Known vulnerabilities in SBOM components should be assessed with a documented severity method and device-specific impact analysis, remediation timelines, and documented risk acceptance rationale where patches were not applied. An SBOM must cover the commercial, open-source, and off-the-shelf software components specified by Section 524B when applicable. Every component in your software stack, including transitive dependencies, needs to be accounted for.

Cybersecurity Test Reports: What Reviewers Actually Examine

See also: PreSTAR vs eSTAR: What Each FDA Template Is For, eSTAR v7.1 Cybersecurity for IVDs vs nIVD Submissions, and Indications for Use, Predicates, and Cybersecurity Scope.

The FDA expects a complete testing portfolio, not a single penetration test report. The portfolio should include penetration testing covering the full attack surface (network, firmware, APIs, wireless interfaces), fuzz testing for input handling and protocol robustness, and SAST/DAST for code-level and runtime vulnerabilities. Each report must include scope definition, methodology referencing frameworks like OWASP, MITRE ATT&CK, or NIST SP 800-115, CVSS-scored findings, and remediation verification with re-test evidence. The FDA recommends independent penetration testers, who may be qualified internal staff independent of development; an outside provider is not mandatory.

For penetration testing specifically, reviewers look for a complete package of evidence:

• Signed rules of engagement and tester credentials
• A complete findings table mapping each finding to its severity, the affected SBOM component, exploit method, and threat model risk trace
• Remediation status for every finding
• Documented risk acceptance rationale and compensating controls for any unresolved high or critical findings

Unresolved high or critical findings without that documentation will stop a review. The Cybersecurity Testing Summary serves as the master document in eSTAR, referencing all individual test reports as appendices. Vague summaries with no raw evidence attached are one of the most reliable ways to generate a late-cycle AI request, which resets your review timeline entirely.

Assembling the Final Package: Traceability and Avoiding the Most Common Failures

The traceability matrix is the document that ties the entire package together, and it's the one most manufacturers underinvest in. It should map Threat ID (from the threat model) to Security Control to Test Case to Verification Evidence to eSTAR Section. Bidirectional traceability is the strongest approach: every risk traces forward to a verified control, and every test case traces back to a risk. Without this document, reviewers must manually reconstruct relationships across separate artifacts, and the gaps they find become deficiency letters.

The most common submission failures follow a predictable pattern: vague test report summaries without raw evidence, SBOMs that omit open-source dependencies, threat models that don't reflect the actual device architecture, and SPDF documentation that reads like an industry template with the device name swapped in. Each of these failures has a direct fix within the artifact structure above. Cybersecurity deficiencies often arrive late in the review cycle as AI requests rather than being caught at acceptance screening, which means manufacturers are weeks or months into the process before they learn there's a problem.

At Blue Goat Cyber, we build submission-ready eSTAR cybersecurity packages that map to every artifact above, aligned with the FDA's current premarket cybersecurity guidance and verified against the eSTAR v7.1 Cybersecurity attachment area. Our FDA cybersecurity deficiency commitment means that if the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed, removing the most expensive risk in the submission process for manufacturers who can't afford a cybersecurity-related delay at the end of a 510(k) review cycle.

What a Complete eSTAR 510(k) Cybersecurity Submission Package Looks Like

Preparing cybersecurity documentation for an FDA eSTAR 510(k) submission means assembling a specific set of artifacts and connecting them through a traceability structure that reviewers can follow end to end. The complete artifact set includes the Security Risk Management Plan, Threat Modeling and Security Architecture Report, Cybersecurity Risk Assessment, SBOM with Support Report, SPDF documentation, and a full testing portfolio, all tied together by a traceability matrix that maps every risk to a verified control.

Get the traceability right. Keep the SBOM complete and current, covering every component including open-source dependencies. Make sure every test finding links back to your threat model. Those three things, done well, are what separates a clean clearance from a deficiency letter that resets your timeline. If you're building your first cybersecurity package or responding to a deficiency on an existing submission, the artifact list above is your starting point. Every item on it needs to be there before you submit.

How Blue Goat approaches this

Our methodology for eSTAR 510(k) cybersecurity documentation focuses on precision and alignment with FDA expectations. We integrate all required artifacts, including detailed threat models, risk assessments, and complete SBOMs, ensuring they are interlinked via a rigorous traceability matrix.

Our team, including CISSP-certified professionals and ex-military red team operators, systematically addresses each cybersecurity deliverable in the eSTAR v7.1 Cybersecurity attachment area and the February 3, 2026 FDA guidance. We proactively identify potential gaps and ensure all controls are supported by verifiable testing evidence. This structured method minimizes the likelihood of deficiencies and accelerates time to market. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Learn more about our approach at Blue Goat Cyber's FDA Premarket Cybersecurity Services.

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.

Need a senior advisor to keep your eSTAR cybersecurity files current for the next submission? See our medical device security advisory.

FAQ

More on this topic

• Unresolved Anomalies in FDA Cybersecurity