FDA Cybersecurity Documentation: Legal Duties and Guidance Recommendations

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

Cybersecurity documentation should connect the threat model, risk assessment, SBOM, architecture, testing, and lifecycle plans. Section 524B requires an SBOM for cyber-device submissions. The FDA recommends a machine-readable, industry-accepted format, but specifies no format or version and does not mention VEX. VEX is an optional way to communicate vulnerability assessments.

Below are illustrative risk rows, optional VEX examples, and an evidence organization table. The table is a planning aid, not an exact reproduction of eSTAR fields or a required reviewer sequence. Use the current eSTAR template and its instructions when preparing attachments.

Why this matters

Incomplete cybersecurity evidence can delay a submission. Section 524B establishes statutory obligations for cyber devices, while the FDA guidance supplies nonbinding recommendations. For eSTAR submissions, technical screening precedes substantive review; the traditional RTA checklist is not used.

Standards anchor the package. Useful references, selected according to the device and regulatory strategy, include AAMI SW96:2023 for security risk management, AAMI TIR57:2016/(R)2023 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 (superseded by CISA's 2026 Minimum Elements for an SBOM, published July 29, 2026) 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

Section 524B requires a postmarket monitoring and coordinated vulnerability disclosure plan, processes and procedures providing reasonable assurance of cybersecurity, updates and patches, and an SBOM submitted to the FDA. The guidance recommends an SPDF to organize lifecycle security evidence; it does not mandate one named development methodology.

The February 3, 2026 final supersedes the June 27, 2025 final; the 2023 version is also superseded. The 2026 revision primarily aligns the guidance with the QMSR. It does not add a VEX requirement, prescribe eight eSTAR slots, or make PCCPs mandatory.

The eight eSTAR v7.1 cybersecurity attachment slots

The following eight evidence groups are an illustrative organization scheme, not official eSTAR slot names or prescribed attachment formats. eSTAR fields depend on the submission and responses in the template.

Traceability helps reviewers connect threats to controls, risk decisions, architecture, and testing. A vulnerability assessment should explain applicability and mitigations; a separate VEX statement is optional.

What an SW96-aligned risk row actually looks like

A possible SW96 implementation 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. An illustrative row carries enough columns to trace from the threat model into the test report without leaving the spreadsheet:

This illustrative format links threat IDs and test evidence and records residual-risk reasoning. The example ratings are placeholders that require device-specific clinical and security assessment; no table format guarantees screening acceptance.

What a working VEX statement looks like

VEX is optional and is not mentioned in the FDA guidance. The following fictional OpenVEX-style excerpt illustrates two assessments, not CycloneDX syntax or real CVE applicability. CISA's April 2023 VEX minimum requirements use four statuses and five justifications: a not_affected statement needs a justification or impact statement, and an affected statement needs an action statement. A complete document must also satisfy its chosen schema and document-level requirements.

{
  "statements": [
    {
      "vulnerability": { "name": "EXAMPLE-VULN-001" },
      "products": [{ "@id": "urn:example:device:firmware-4.2" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "Illustrative only: affected code is excluded from this build, supported by build and binary inspection records."
    },
    {
      "vulnerability": { "name": "EXAMPLE-VULN-002" },
      "products": [{ "@id": "urn:example:device:firmware-4.2" }],
      "status": "affected",
      "action_statement": "Illustrative only: apply the validated vendor patch when released and follow the interim network isolation advisory."
    }
  ]
}

Use evidence-backed status decisions and the vocabulary of the chosen VEX format. OpenVEX status and justification values are not interchangeable with CycloneDX analysis enums; validate the complete document against the appropriate schema before distribution.

How reviewers actually read the package

Use this internal consistency check, not an asserted FDA reviewer sequence or official eSTAR slot map:

1. Compare the threat model with relevant interfaces and update paths.
2. Link threats to controls and documented residual-risk decisions.
3. Link controls to test results and explain scope exclusions.
4. Compare the SBOM with the released software and vulnerability assessment. VEX is optional; do not invent an affected vulnerability to fill an example.
5. Include applicable recommended architecture views: global system, multi-patient harm, updateability/patchability, and security use case views.
6. Reconcile labeling, coordinated vulnerability disclosure, monitoring, and patch processes with the design and risk records.

No sequence or checklist guarantees screening acceptance.

SBOM, VEX, and vulnerability management evidence

See also: SPDF and IEC 62304 Mapping: FDA Cyber, Medical Device Incident Response Plan, and Home Use vs Hospital Device Cybersecurity Requirements.

Section 524B requires an SBOM submitted to the FDA, including commercial, open-source, and off-the-shelf software components. The FDA recommends machine-readable, industry-accepted formats and support-level and end-of-support information, but names no format or version. CISA's July 29, 2026 minimum elements supersede the NTIA 2021 baseline and are a useful reference, not an automatically incorporated FDA mandate. Keep the inventory consistent with released software.

The required monitoring and coordinated vulnerability disclosure plan should identify intake, assessment, ownership, escalation, and communication processes. Name relevant information sources and set risk-based internal targets. Section 524B requires regular-cycle updates for known unacceptable vulnerabilities and out-of-cycle patches as soon as possible for critical vulnerabilities that could cause uncontrolled risks; it sets no numeric SLAs.

Testing evidence FDA guidance recommends for moderate-to-high risk devices

The FDA recommends security requirements testing, threat mitigation testing, vulnerability testing, and penetration testing. Select methods such as SAST, DAST, and fuzzing based on device-specific risks. Document scope, methods, results, and limitations, and link findings and remediation evidence to the risk assessment.

Independent testers may be internal or external. Document their qualifications and organizational independence from development, and select interface, parser, hardware, and AI-specific tests based on the threat model.

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.

Section 524B requires processes for cybersecurity updates and patches. Explain secure distribution, integrity verification, deployment, and recovery as applicable. A service-visit update mechanism is not categorically prohibited; justify its timeliness and feasibility for the device and its deployment environment.

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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

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 applicable eSTAR v7.1 cybersecurity sections. 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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. For teams that want to validate their own work, our SPDF cybersecurity documentation playbook walks through the same checklist reviewers use.

Related reading: Conducting a Medical Device Security Audit, VxWorks Vulnerabilities in Medical Devices: Triage, SBOM & §524B Evidence, Medical Device Penetration Testing Post Exploitation Explained.

For a step-by-step list, see the eSTAR 7.1 submission checklist. It covers the template, the cybersecurity attachments, the user fee, and the CDRH Portal upload.

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.1 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 evidence gaps can cause cybersecurity review questions?

Inconsistent threat models, risk assessments, and test evidence can prompt questions. The FDA does not publish a universal reviewer sequence or establish this as the leading cause of holds. eSTAR uses technical screening, not the traditional RTA checklist, and substantive review can result in an AI request.

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?

The February 3, 2026 final supersedes the June 27, 2025 final, and primarily aligns the guidance with the QMSR. The 2023 version is also superseded. The revision does not mandate VEX, PCCPs, eight eSTAR cybersecurity slots, or a named SBOM format. Review the current guidance and template for applicable recommendations.

Ready to file with confidence?

Book a submission readiness review with our senior team. We will walk your eSTAR v7.1 cybersecurity sections, flag the artifacts most likely to draw an AI request, and scope the work to close the gaps. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

---

About the author. Christian Espinosa is Founder of Blue Goat Cyber, a cybersecurity leader and former U.S. Air Force officer with two decades of experience leading red-team and medical-device security engagements. Blue Goat Cyber has supported 275+ submissions.