FDA Cybersecurity Documentation

Most FDA cybersecurity write-ups answer "what's required." This one answers a different question: what does each artifact actually look like on the page? Reviewers do not fail submissions because the manufacturer did not know an SBOM was expected. They fail submissions because the SBOM ships without VEX statements in a syntax their tooling can parse, because the threat model uses identifiers the risk file does not, or because the eSTAR slot is filled with a PDF when reviewers expect machine-readable JSON.

Below you will find example SW96 risk rows, working CycloneDX VEX snippets, a slot-by-slot eSTAR v7.0 reference table, and a walkthrough of the exact order reviewers open the package. If you want the upstream "is this required?" view, our premarket submission checklist and RTA prevention checklist cover that ground. This post is the artifact-anatomy companion.

Table of Contents

• What the FDA's 2026 premarket cybersecurity guidance actually requires
• The eight eSTAR v7.0 cybersecurity attachment slots
• What an SW96-aligned risk row actually looks like
• What a working VEX statement looks like
• How reviewers actually read the package
• SBOM, VEX, and vulnerability management evidence
• Testing evidence reviewers expect for moderate-to-high risk devices
• Cybersecurity labeling, postmarket plan, and patchability
• How Blue Goat Cyber approaches FDA cybersecurity documentation
• FAQ

Why this matters

A cybersecurity hold inside the 15-day RTA window is not a polite request for more information. It restarts the submission clock and resets every downstream commercial milestone. Under Section 524B of the FD&C Act, the FDA has explicit statutory authority to refuse to accept a cyber-device submission that lacks the required evidence, and reviewers are exercising that authority routinely in 2026. The final premarket cybersecurity guidance issued February 3, 2026, the FDA's recognition of AAMI SW96:2023 (recognition number 13-122), and eSTAR v7.0's eight cybersecurity attachment slots together define what "adequate" looks like.

Standards anchor the package. The 2026 guidance expects evidence consistent with AAMI SW96:2023 for security risk management, AAMI TIR57:2016 (R2023) as the implementation guide, AAMI TIR97:2019 for postmarket security risk management, IEC 81001-5-1 for secure software lifecycle activities, IEC 62304 for software lifecycle processes, NIST SP 800-218 (SSDF) for secure development practices, and the NTIA minimum elements (now stewarded by CISA) for SBOM content. Citing the wrong standard, or citing a superseded version, signals to reviewers that the underlying work is also out of date.

What the FDA's 2026 premarket cybersecurity guidance actually requires

The 2026 guidance operationalizes the three Section 524B obligations, patchability, vulnerability management, and SBOM, and embeds them in a Secure Product Development Framework. SPDF is not an optional methodology; it is the structure the guidance expects every cyber-device manufacturer to use to produce premarket evidence. FDA cybersecurity documentation development means producing SPDF outputs as an engineering byproduct: threat models updated when the architecture changes, SBOMs regenerated on every build, vulnerability assessments tied to the SBOM, and security testing evidence linked to specific threats. A submission written after the device is feature-complete cannot fake this lineage.

The 2026 final supersedes the September 2023 final. The most consequential deltas are: AAMI SW96:2023 is now the FDA-recognized security risk-management standard; VEX statements are expected alongside the SBOM; PCCPs must cover security-relevant changes, not just performance retraining; and the cybersecurity submission collapses into eight eSTAR v7.0 attachment slots that reviewers screen in order. Teams that prepared evidence against the 2023 final need to walk through each delta before filing, not assume the prior structure will pass.

The eight eSTAR v7.0 cybersecurity attachment slots

eSTAR v7.0 organizes cybersecurity evidence into eight discrete attachment slots, and a missing slot is the fastest path to an RTA. The table below is the exact reference our team uses when assembling a package. Each row names the slot the way it appears in eSTAR, the file format reviewers expect, and the single most common reason that slot fails screening.

#	eSTAR v7.0 slot	Expected format	Most common screening failure
1	Security Risk Management Report	PDF, SW96-aligned	Built to ISO 14971 only, no SW96 mapping
2	Threat Model	PDF + DFDs	STRIDE applied to the application only, not to interfaces or update channels
3	Cybersecurity Risk Assessment	PDF	Threats not keyed to the same identifiers used in the threat model
4	SBOM	CycloneDX 1.5+ or SPDX 2.3+ (JSON/XML)	Generated from build manifest, not the shipped binary
5	Vulnerability Management Plan	PDF	Names "industry sources" instead of specific feeds, owners, and SLAs
6	Coordinated Vulnerability Disclosure policy	Public URL + PDF	No named coordinator, no response-time commitment
7	Security Architecture documentation	PDF (global, multi-patient harm, updateability views)	Missing one of the three required views from the 2026 guidance
8	Cybersecurity Testing evidence	PDF (pen test, SAST, DAST, fuzz)	Findings carry CVSS but no threat-model ID link

Traceability across slots is what reviewers verify first. The threat model (Slot 2) must enumerate threats by component. The risk assessment (Slot 3) must map each threat to a control and a residual-risk decision using the same threat IDs. The architecture documentation (Slot 7) must show where each control lives. The testing evidence (Slot 8) must demonstrate that each high-severity threat was actively exercised. The SBOM (Slot 4) must enumerate the components those controls protect. Any break in that chain - a threat with no mapped test, a control with no architecture home, a CVE with no VEX statement - is a deficiency trigger.

What an SW96-aligned risk row actually looks like

The most common SW96 mistake is treating the security risk file as a copy of the ISO 14971 hazard analysis. SW96 expects threat-driven rows, not hazard-driven rows, and reviewers can spot a relabeled 14971 file immediately. A passing row carries enough columns to trace from the threat model into the test report without leaving the spreadsheet:

Threat ID	Threat (STRIDE)	Asset	Control	Residual likelihood	Residual harm	Test ID
TM-014	Spoofing of update server	OTA channel	Mutual TLS + signed manifest, root pinned in secure element	Low	Negligible	PT-2026-014, FUZZ-OTA-03
TM-027	Tampering with telemetry payload	Cloud ingestion API	HMAC over payload + replay window, server-side schema validation	Low	Minor	PT-2026-027
TM-041	Information disclosure via debug UART	Service interface	Fuse-disabled in production, physical tamper-evident seal	Very low	Negligible	HW-INSP-04

Three things make this format pass screening: (1) the Threat ID column is the same identifier used in the threat model, so the reviewer can cross-reference in one click; (2) every row has a Test ID that exists in the Slot 8 testing evidence; (3) residual likelihood and harm use the device's documented risk-acceptability matrix rather than a generic high/medium/low scale.

What a working VEX statement looks like

VEX statements are new as an explicit 2026 expectation, and they are where most SBOMs fail substantive review. A VEX statement tells the reviewer which CVEs in your SBOM are actually exploitable in your device - a bare not_affected assertion does not satisfy this. Both examples below are valid CycloneDX 1.5 VEX entries; the first claims the device is unaffected, the second commits to a fix.

{
  "vulnerabilities": [
    {
      "id": "CVE-2024-12345",
      "source": { "name": "NVD" },
      "ratings": [{ "severity": "high", "method": "CVSSv31", "score": 7.5 }],
      "affects": [{ "ref": "pkg:generic/openssl@3.0.7" }],
      "analysis": {
        "state": "not_affected",
        "justification": "vulnerable_code_not_present",
        "detail": "Affected TLS renegotiation path is disabled at build time via OPENSSL_NO_RENEGOTIATION; verified by SAST rule SR-014 and confirmed in shipped binary hash 4f3a..."
      }
    },
    {
      "id": "CVE-2025-67890",
      "source": { "name": "NVD" },
      "ratings": [{ "severity": "critical", "method": "CVSSv31", "score": 9.8 }],
      "affects": [{ "ref": "pkg:generic/libxml2@2.10.4" }],
      "analysis": {
        "state": "affected",
        "response": ["update"],
        "detail": "XML parser reachable from network interface IF-02. Mitigation: scheduled patch in firmware 4.2.1, target release 2026-08-15; interim DAST monitoring per VMP section 5.3."
      }
    }
  ]
}

What reviewers look for: a justification value drawn from the CycloneDX-recognized list (vulnerable_code_not_present, vulnerable_code_not_in_execute_path, inline_mitigations_already_exist, and similar), a detail field that names the specific configuration or test that proves the claim, and a response plan for anything left affected. A VEX file with a hundred not_affected rows and no detail fields will be rejected as boilerplate.

How reviewers actually read the package

The order matters. Reviewers do not read top-to-bottom; they screen for traceability breaks. Knowing the sequence lets you stage the package the way it will be consumed:

1. Open Slot 2 (Threat Model). Count threats per interface. If a network or update interface has zero threats, the package fails here.
2. Cross-check Slot 3 (Risk Assessment). Every threat ID from Slot 2 must appear with a control and a residual-risk decision.
3. Spot-check Slot 8 (Testing). Pick three high-severity threats from Slot 2 and confirm each has a matching test ID with a result, not just a scope statement.
4. Open Slot 4 (SBOM) and Slot 5 (VMP). Confirm the VEX is present, that at least one affected CVE has a response plan, and that the VMP names the same feeds the VEX cites.
5. Open Slot 7 (Architecture). Verify the three required views are present (global system, multi-patient harm, updateability) and that controls cited in Slot 3 appear in the diagrams.
6. Open Slot 1 (Security Risk Management Report). Confirm SW96 alignment and that the report references - does not duplicate - the Slot 3 risk assessment.

See also: SPDF and IEC 62304 Mapping: FDA Cyber, Medical Device Incident Response Plan, and Medical Device Pen Testing: FDA vs EU MDR 2026.

Slot 6 (CVD) and Slot 8 labeling cross-checks happen last, almost as a formality. If the package survives steps 1-5, it almost always clears screening.

SBOM, VEX, and vulnerability management evidence

Beyond the VEX example above, the SBOM itself must meet the NTIA minimum elements and ship machine-readable in CycloneDX or SPDX. Each component requires supplier, name, version, unique identifier (PURL or CPE), dependency relationship, author, and timestamp. Hash-only "manifests" do not satisfy the requirement. For devices with substantial third-party content, expect reviewers to spot-check that the SBOM matches the shipped binary, not the build manifest.

The Vulnerability Management Plan must describe how new CVEs are ingested, triaged against the SBOM, assessed under the device's risk framework, and either patched or risk-accepted with documented rationale - and it must name the specific feeds (NVD, ICS-CERT, vendor advisories) and the SLA for each severity tier. The Coordinated Vulnerability Disclosure policy must be public, must name a coordinator, and must commit to a response timeline.

Testing evidence reviewers expect for moderate-to-high risk devices

For moderate and high-risk devices, independent penetration testing is no longer optional. The 2026 guidance expects pen test scope to cover every interface in the threat model, every protocol in the architecture diagram, and every wireless or network surface the device exposes in clinical use. SAST and DAST evidence is expected alongside the pen test, not as a substitute. A pen test report that lists CVSS scores without tying each finding back to a threat-model ID (as in the risk-row example above) will not survive substantive review.

Independence matters. Reviewers increasingly question pen tests run by the same internal team that wrote the security requirements. Use a third party, or document a credible separation-of-duties arrangement. For middleware-heavy or AI-enabled devices, fuzz testing of network-exposed parsers and adversarial input testing of model inference paths are now within the expected scope.

Cybersecurity labeling, postmarket plan, and patchability

Cybersecurity labeling addresses what the operator needs to maintain a secure configuration: software version, supported configurations, network port and protocol disclosures, cryptographic strength of communications, update mechanism, end-of-support timeline, and contact information for vulnerability reports. The MDS² form covers most of this for hospital procurement and should be referenced in the submission.

Patchability under Section 524B is a design obligation, not a postmarket promise. The submission must show how patches are authored, signed, distributed, verified, and rolled back, and the postmarket plan must commit to a cadence. A patch mechanism that requires a service visit for every fielded device will draw a deficiency on patchability adequacy, regardless of how thorough the rest of the package is.

Mid-article CTA: If you want a second set of eyes on your eSTAR cybersecurity package before you file, book a 30-minute submission review with Blue Goat Cyber. If the FDA raises cybersecurity deficiencies after our submission support, we resolve them at no additional cost.

How Blue Goat Cyber approaches FDA cybersecurity documentation

We run the SPDF as a workstream alongside engineering, not as a documentation sprint before filing. Our senior team holds CISSP and OSCP credentials and includes ex-military red team operators, and every engagement produces evidence keyed directly to the eight eSTAR v7.0 cybersecurity slots. We start with the threat model in week one, build the SBOM and VEX pipeline into your CI, and have the security risk file under SW96 evolving in parallel with the design history file. By the time the submission is assembled, the artifacts already trace to each other.

When you engage us for full premarket support through our FDA premarket cybersecurity services, we stand behind the package: if the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. For teams that want to validate their own work, our SPDF cybersecurity documentation playbook walks through the same checklist reviewers use.

FAQ

What does FDA cybersecurity documentation development actually look like in practice?

It is a continuous engineering output, not a pre-submission writing project. Threat models update when the architecture changes, the SBOM regenerates on every build, vulnerability triage runs against the SBOM weekly, and security testing evidence accumulates against threat-model identifiers. By filing time, the package already traces end-to-end because each artifact was produced from the work, not summarized after the fact.

How long does it take to produce a complete premarket cybersecurity package?

For a moderate-risk connected device with a clean SPDF in place, six to twelve weeks of dedicated effort is typical to produce the full eSTAR v7.0 package. For teams starting from a documentation-light position, expect three to five months because the underlying engineering artifacts (threat model, security architecture, traceability) have to be built before the submission documents have anything to summarize.

What is the single most common cause of an RTA cybersecurity hold?

A threat model that does not match the risk file and the test report. Reviewers open the threat model first, then check whether each high-severity threat appears in the risk assessment with a control, and whether that control appears in the test report with a result. A break anywhere in that chain produces an immediate hold, regardless of how thorough each individual document is.

Can we reuse cybersecurity documentation across a product family?

Yes, if you build it that way from the start. A platform-level threat model, security architecture, and SBOM baseline can be inherited by each variant submission, with variant-specific deltas documented as addenda. Reviewers accept this pattern as long as the inheritance is explicit and the variant-specific risk assessment is genuinely variant-specific, not a copy-paste of the platform document.

Does the 2026 guidance change what we needed under the 2023 final?

Yes. The biggest deltas are AAMI SW96:2023 as the FDA-recognized security risk standard, explicit VEX statement expectations alongside the SBOM, PCCP coverage of security-relevant changes, and the eight-slot eSTAR v7.0 structure. Packages built to the 2023 final should be walked against each delta before filing, not assumed to pass.

Ready to file with confidence?

Book a submission readiness review with our senior team. We will walk your eSTAR v7.0 cybersecurity slots, flag the artifacts most likely to draw an AI request, and scope the work to close the gaps. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

---

About the author. Christian Espinosa is Founder of Blue Goat Cyber, a CISSP- and OSCP-credentialed cybersecurity leader and former U.S. Air Force officer with two decades of experience leading red-team and medical-device security engagements. He has guided more than 200 connected-device submissions through FDA premarket cybersecurity review.