eSTAR Submission Documentation

This chapter details the specific cybersecurity documentation required for FDA's enhanced Security and Technology Architecture Review (eSTAR) process.

This chapter covers how to turn the security work you did during development into the documentation package FDA actually reviews. It starts by separating what's legally required from what's expected. Under Section 524B of the FD&C Act, cyber devices must include a cybersecurity management plan, a software bill of materials, and evidence of security controls. Beyond that, FDA expects every device with software to submit security architecture views, a threat model, a security risk assessment, security controls documentation, a safety and security risk integration analysis, security test reports, and cybersecurity labeling. Skip any of these and you can expect a deficiency letter.

The recurring theme across sections 6.3 through 6.11 is evolution, not recreation. Each artifact you need for eSTAR should grow out of a document you already built during development: architecture views from Chapter 3.5, the threat model from Chapter 3.6, the risk assessment from Chapter 3.7, controls and testing from Chapter 4, and the postmarket management plan from Chapter 5. What changes for submission is the audience. You add clinical impact analysis to every significant threat and risk, expand explanatory text so a reviewer who has never seen your device can follow it, and build traceability that links threat IDs to risk IDs to control IDs to test cases across every document.

The closing sections deal with the review itself. Section 6.12 walks through the ten most common submission pitfalls, things like inconsistent cross-references, generic boilerplate, and missing clinical context, all of which delay clearance even when the underlying security work is solid. Section 6.13 covers organizing the package for efficient reviewer navigation and using the Q-Submission program to get FDA feedback on novel approaches before you file. The chapter ends with the success factors that separate smooth clearances from multi-cycle reviews: early integration of documentation planning, consistent IDs, and writing for the reviewer rather than for your own team.