Preparing Your 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).

If you're asking how to prepare cybersecurity documentation for an FDA eSTAR 510(k) submission, the answer starts with understanding what reviewers are actually screening for, artifact by artifact. Cybersecurity documentation deficiencies are among the most frequently cited causes of Refuse to Accept (RTA) determinations and Additional Information (AI) requests in 510(k) reviews, according to FDA's premarket cybersecurity guidance. That's not a technicality; it means submissions get stopped before a substantive review even begins and timelines slip by months. The frustrating part is that most manufacturers arrive at the eSTAR template with a general idea of what cybersecurity documentation means, but no clear picture of what FDA reviewers actually want to see. The template itself doesn't explain it.

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've produced 250+ FDA submissions with zero cyber-related rejections, backed by a 100% clearance guarantee. What follows is exactly what goes inside one of those packages.

Key Takeaways

• Cyber device classification dictates required documentation tiers.
• ESTAR Section Q structures eight cybersecurity categories.
• Core artifacts: Threat Model, Risk Assessment, SBOM, SPDF evidence.
• SBOMs must be complete, including open-source dependencies.
• Testing reports require scope, methodology, findings, and re-test evidence.
• Traceability matrix links risks, controls, and testing results.

Table of Contents

• Key Takeaways
• Does Your Device Qualify as a "Cyber Device" Under Section 524B?
• How the eSTAR Template Structures Cybersecurity Requirements
• Building Your Core Documentation: Threat Model, Risk Assessment, and SPDF Evidence
• SBOM Requirements: Format, Fields, and the Support Report
• Cybersecurity Test Reports: What Reviewers Actually Examine
• Assembling the Final Package: Traceability and Avoiding the Most Common Failures
• What a Complete eSTAR 510(k) Cybersecurity Submission Package Looks Like

Why this matters

Inadequate cybersecurity documentation is a primary reason for Refuse to Accept (RTA) determinations and additional information (AI) requests from the FDA for 510(k) submissions. Such delays can push product launches back by months, incurring significant financial penalties and lost market opportunities for medical device manufacturers. The FDA's 'Cybersecurity in Medical Devices' Final Guidance, dated February 3, 2026, explicitly outlines the necessity for a structured approach to premarket cybersecurity documentation, emphasizing clear evidence of risk management throughout the device lifecycle.

Failure to align with these guidelines and related standards such as IEC 81001-5-1, ISO 14971, and AAMI TIR57/TIR97 not only risks regulatory delays but also exposes devices to potential vulnerabilities once deployed. An RTA or AI request signifies that the submission does not even meet the administrative requirements for review, indicating a fundamental mismatch between the submitted documentation and the FDA's expectations. This highlights the critical importance of a precise and complete cybersecurity package from the outset.

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 contains software (including firmware), it has the ability to connect to the internet, and it contains technological characteristics that could be vulnerable to cybersecurity threats. The FDA interprets "ability to connect" broadly. A device with unintentional wireless exposure, such as one that could be connected through a service port or a hospital network it wasn't designed for, still qualifies. 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. Misclassifying a modification as non-security-impacting is one of the most common deficiency triggers. 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

Section Q of the non-IVD eSTAR template is the dedicated cybersecurity section. It's a structured set of fields, not a generic upload area, and the FDA's automated screening checks it for completeness before a human reviewer ever looks at your submission. Per the FDA's premarket cybersecurity guidance, the section is organized around eight security categories: device identification, authorization, data protection, system integrity, malware protection, secure communications, security monitoring, and configuration management. Your documentation must map to these categories either explicitly through labeled sections or through a traceability structure that connects every artifact to the relevant category.

For new submissions and security-impacting modifications, the required artifacts are non-negotiable. Omissions from Appendix 1 of the FDA's cybersecurity guidance are flagged as deficiencies during technical screening. 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, will 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

Per the FDA's premarket cybersecurity guidance and NTIA minimum elements requirements, the FDA accepts two machine-readable SBOM formats: SPDX and CycloneDX (JSON or XML). The agency doesn't mandate one over the other, but both must comply with NTIA minimum elements. Those elements include supplier name, component name, version, unique identifiers (CPE or PURL preferred for vulnerability lookup), dependency relationships, SBOM author, and timestamp.

Human-Readable Exports

See also: eSTAR v7.0 Cybersecurity for IVDs vs nIVD Submissions, Letter to File vs New 510(k) for Cybersecurity Changes, and Special vs Traditional 510(k) for Cybersecurity Changes.

FDA reviewers frequently request a human-readable export alongside the machine-readable file. 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 must be evaluated with CVSS scoring, remediation timelines, and documented risk acceptance rationale where patches were not applied. An SBOM that lists only first-party components and omits open-source dependencies is one of the most common deficiencies across 510(k) submissions. Every component in your software stack, including transitive dependencies, needs to be accounted for.

Cybersecurity Test Reports: What Reviewers Actually Examine

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 for Healthcare, or NIST SP 800-115, CVSS-scored findings, and remediation verification with re-test evidence. Third-party penetration testing is preferred; reviewer scrutiny increases when the manufacturer's own team conducted the tests.

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 eSTAR's Section Q requirements. Our 100% FDA clearance guarantee means that if a submission is rejected for cybersecurity reasons, we fix it at no additional cost, 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 element of eSTAR Section Q 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 cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our approach at Blue Goat Cyber's FDA Premarket Cybersecurity Services.

FAQ

What is a "cyber device" according to the FDA?

A cyber device contains software, can connect to the internet, and has characteristics vulnerable to cybersecurity threats. The FDA interprets connectivity broadly, including unintentional network access.

What core cybersecurity documents are needed for an eSTAR 510(k) submission?

Key documents include the Security Risk Management Plan, Threat Modeling and Security Architecture Report, Cybersecurity Risk Assessment Report, Software Bill of Materials (SBOM), and SBOM Support Report.

What is SPDF documentation?

SPDF (Security Plan, Design, and Future Process) documentation provides evidence that security was addressed throughout the device's development lifecycle, including QMS procedures, design controls, and traceability, rather than just post-development patching.

Does the FDA prefer SPDX or CycloneDX for SBOMs?

The FDA accepts both SPDX and CycloneDX formats (JSON or XML), provided they comply with NTIA minimum elements, which include supplier, component name, version, and unique identifiers like CPE or PURL.

What kind of cybersecurity testing does the FDA expect for medical devices?

The FDA expects a portfolio including penetration testing, fuzz testing, and SAST/DAST, with explicit scope, methodology, CVSS-scored findings, and remediation verification for each report.

Why is a traceability matrix important for eSTAR cybersecurity submissions?

A traceability matrix demonstrates that every identified cybersecurity risk is addressed by a specific control and verified through testing. It ensures reviewers can easily follow how security measures mitigate risks.

About the author

Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance. Read more about Christian.