A cyber device submission carries a specific set of cybersecurity documents through eSTAR. Here is the list, what each one has to contain, and the one property reviewers check first: whether they agree with each other.

The FDA's final cybersecurity guidance is in full effect and the QMSR, aligned to ISO 13485, took hold on February 2, 2026. A cyber device submission now carries the most demanding cybersecurity documentation set to date, and eSTAR walks you through it attachment by attachment. If your device is a cyber device under Section 524B, none of it is optional.

The nine deliverables

Counted deliverable by deliverable, the cybersecurity section of a 2026 submission asks for nine things. Each maps to a section of the FDA guidance.

  • Cybersecurity Management Plan. How you will monitor, identify and address vulnerabilities after release, including coordinated vulnerability disclosure. Guidance Section VI.B; required for cyber devices by Section 524B(b)(1).
  • Security Architecture Views. Diagrams plus text: the global system view, the multi-patient harm view, the updatability and patchability view, and a security use case view for every function where a compromise could touch safety. Section V.B.2 and Appendix 2.
  • Threat Model. The analysis of assets, interfaces, threats and mitigations across the whole medical device system, with the rationale for the method you picked. Section V.A.1.
  • Cybersecurity Risk Assessment. The risks and controls from the threat model, scored pre- and post-mitigation on exploitability, with acceptance criteria and the method for carrying security risks into the safety risk file. Section V.A.2.
  • Assessment of Unresolved Anomalies. Every open software anomaly evaluated for security impact, including any CWE categories present. Section V.A.5.
  • Cybersecurity Metrics. At minimum the three FDA names: the share of identified vulnerabilities patched, the time from identification to patch, and the time from patch availability to field deployment. Section V.A.6.
  • Cybersecurity Controls. Requirements and acceptance criteria across the eight control categories, with evidence the controls were implemented and tested. Section V.B.1 and Appendix 1.
  • Software Interoperability V&V. The security risks and controls on every electronic interface, verified interface by interface. Section V.A.3, read alongside the interoperability guidance.
  • Vulnerability and Patch Management. The regular update cycle for known unacceptable vulnerabilities, the out-of-cycle path for critical ones, and the SBOM that makes both possible. Sections V.A.4 and VII.C.

eSTAR also carries the SBOM itself (Section 524B(b)(3)), the cybersecurity labeling, and the testing reports. Treat the nine as the spine and those as the attachments that hang off it.

The trap is consistency, not weakness

A submission rarely fails because one document is thin. It fails because the documents disagree. The threat model describes an interface the architecture views never show. The risk assessment scores a component the SBOM does not list. The controls table claims encryption the testing report never exercised. Reviewers cross-examine, and the seams are where deficiency questions come from.

A submission does not fail because one document is weak. It fails because the documents disagree.

The guidance says this in its own language. The security risk management report should "provide traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation." Traceability is the deliverable that ties the other nine together, and it is the one most teams write last.

How to keep nine documents telling one story

Pick one description of the device, its components and its interfaces, and generate every deliverable from it. The architecture views come from that model. The threat model sits on the same components. Every vulnerability in the SBOM traces to a component in the views and a control in the table. Testing evidence lands against the same interfaces.

Practically, for a small team, that means one owner for the system description, a single component inventory that feeds both the SBOM and the architecture views, and a traceability matrix started on day one rather than assembled before filing. Documents produced from one model cannot contradict each other. Documents assembled by hand across three consultants and a spreadsheet almost always do.