Preparing Your eSTAR 510(k) Cybersecurity Documentation

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

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

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.