What Goes in the Cybersecurity Section of a 510(k)?

FDA's technical screening of a 510(k) eSTAR is anticipated within 15 days of receipt, and FDA states plainly that an eSTAR "will be put on a Technical Screening hold if it does not contain accurate responses and relevant attachments in the Cybersecurity section of eSTAR" (FDA, Cybersecurity in Medical Devices FAQs). A held file is not a slow file. The review clock starts on the day a submission that passes screening was received, and if a complete replacement eSTAR does not reach FDA within 180 days of the technical screening deficiency notification, FDA considers the 510(k) withdrawn and closes it (Electronic Submission Template for Medical Device 510(k) Submissions, issued October 2, 2023). What belongs in that section is enumerated in Table 1 of the current premarket cybersecurity guidance, issued February 3, 2026 under docket FDA-2021-D-1158: six top-level documentation types, fourteen rows once the sub-elements are counted (FDA guidance page). The part nobody plans for: every page of that guidance is stamped "Contains Nonbinding Recommendations", and screening checks only that an attachment exists, so the gate you can clear in a weekend is not the gate that decides your submission.

Below: what screening verifies, what Table 1 lists, and which artifacts consume most of the calendar.

Key takeaways

• Technical screening is anticipated within 15 days of FDA receiving the eSTAR, and only begins once the user fee has been paid.
• Screening checks that responses and attachments are present and accurate, not that the work behind them is any good.
• Table 1 of the February 3, 2026 guidance lists six documentation types: cybersecurity risk management report, measures and metrics, architecture views, testing, labeling, and cybersecurity management plans.
• FDA names four security architecture views, and how many you need scales with connectivity rather than with company size.
• Beside the SBOM, FDA asks for each component's level of support and its end-of-support date, the field teams most often find they cannot fill.

Screening is a presence check, and that is the trap

The eSTAR mechanism was designed so incomplete submissions would be rare. Because a properly prepared electronic submission should represent a complete submission, eSTAR files are not anticipated to undergo the older refuse-to-accept process, and the CDRH Portal verifies automatically that the eSTAR is complete. What replaces that process is a virus scan plus technical screening, described in the October 2, 2023 eSTAR guidance as verifying two things: that the eSTAR responses accurately describe the device, and that there is at least one relevant attachment for each applicable attachment-type question.

Read that second clause carefully, because it sets the bar for what screening can catch. A threat model that is three diagrams with no explanatory text is an attachment. A penetration test report that names no testers is an attachment. Screening asks whether the file is there; the reviewer asks whether it is any good later, with the clock running.

All 510(k) submissions have had to arrive as eSTAR since October 1, 2023, unless exempted (FDA, How to Prepare a Traditional 510(k)), so there is no paper path around this gate. Screening time does not count against the review clock for files that pass, which sounds generous until the corollary lands: a file on hold is not being reviewed at all.

Table 1, and what FDA says it is not

Appendix 4 carries Table 1, "Recommended Premarket Submission Documentation". Six entries sit at the top level:

• Cybersecurity risk management report, which breaks into six sub-elements: threat model, cybersecurity risk assessment, SBOM, vulnerability assessment and software support, unresolved anomalies assessment, and traceability
• Measures and metrics
• Architecture views, with requirements and the views themselves listed beneath
• Testing
• Labeling
• Cybersecurity management plans

FDA attaches a caution to its own table that is easy to skim past: "This table is not intended to serve as merely a deliverable checklist, as the processes outlined throughout the guidance are intended to help align generation of these documents and their resultant content with FDA's recommendations." The table describes outputs of a development process FDA expects you to be running. A team that reverse-engineers the documents at the end is producing the artifacts of a program it does not have.

The table also carries an IDE column that doubles as a signal of priority: for investigational device exemption submissions FDA specifically recommends the SBOM, the architecture views with their requirements, and labeling, while everything else is "could be helpful to submit, but not specifically recommended".

Documentation scales with the risk of the device, most visibly in the breadth of threat modeling and architecture views. The guidance contrasts a device with a single hardware connection, which it says will likely need only one view per category, against one with networking, wireless, cloud, or a commercial operating system, where it says many security use case views will likely be needed. Scope by connectivity, not by headcount.

The four architecture views are where the calendar goes

FDA recommends providing at minimum four types of view: a Global System View, a Multi-Patient Harm View, an Updateability/Patchability View, and Security Use Case View or views. Each should include diagrams and explanatory text with enough detail to show how the assets in the medical device system function holistically.

They are not four drawings of the same thing. The global system view describes the whole system, and for networked devices should identify software update infrastructure, healthcare facility network impacts, intermediary devices, cloud connections, and patient home network impacts. The multi-patient harm view asks what a manufacturer rarely asks in design review: what path exists by which one compromise reaches many patients. The updateability and patchability view forces you to draw how a patch travels to a fielded device, which is exactly the mechanism a rushed program leaves undesigned.

FDA gives two forms of relief that teams underuse. If one view sufficiently captures the risks of another, or if threat modeling documentation already captures the view, FDA does not expect duplicated documentation. And if one of the four is genuinely not appropriate, the instruction is not to omit it silently but to explain why. An explained absence is defensible; a missing view with no sentence about it reads as an oversight.

The SBOM is famous; the two fields beside it are the ones that hurt

Section 524B(b)(3) of the FD&C Act requires a software bill of materials including commercial, open-source, and off-the-shelf software components for cyber devices (21 U.S.C. 360n-2), and has applied to submissions since March 29, 2023. Most device teams know this. The February 3, 2026 guidance then asks for more than the inventory.

FDA recommends machine-readable SBOMs consistent with the minimum elements identified in the October 2021 NTIA software component transparency work, then adds two per-component fields: the level of support provided through monitoring and maintenance by the component's manufacturer, with FDA's examples being actively maintained, no longer maintained, or abandoned, and the component's end-of-support date. Generating a dependency list is a build-pipeline task an engineer finishes in a sprint; establishing support status and end-of-support dates for every third-party component in a four-year-old codebase is supplier management. That is the one that slips.

FDA also asks manufacturers to identify all known vulnerabilities in the device and its software components, including those in CISA's Known Exploited Vulnerabilities Catalog, to describe how they were discovered so FDA can judge whether the method was robust, and for each to provide a safety and security risk assessment plus the applicable risk controls. If you also ship into Europe, the vulnerability-handling half of this work overlaps heavily with the Cyber Resilience Act, covered in EU CRA SBOM requirements.

Testing: FDA reads who tested, not only what passed

Section V.C names four categories of testing FDA recommends considering for inclusion: security requirements, threat mitigation, vulnerability testing as described in ANSI/ISA 62443-4-1, and penetration testing. The vulnerability testing bullet is itself a list, running from malformed inputs and fuzz testing through attack surface analysis, vulnerability chaining, software composition analysis of binaries, and static and dynamic code analysis including testing for hardcoded and default credentials.

The penetration testing paragraph specifies the report, not just the test. FDA states that penetration test reports should include the independence and technical expertise of the testers, the scope of testing, the duration of testing, the testing methods employed, and the test results, findings and observations. Manufacturers are asked to indicate how independent those testers were from the developers who designed the device, and to provide the original report for third-party testing.

A report covering three days of scanning by the engineer who wrote the firmware satisfies none of those five elements, and no remediation afterwards retroactively creates independence. That is why device teams buy penetration testing rather than run it internally, and the questions worth asking a firm before signing are in how to choose a penetration testing company.

One detail carries a deadline: for findings you intend to fix in a future release, the submission should contain plans for those releases, including which vulnerabilities each addresses, anticipated timelines, and how long an update takes to reach fielded devices. Deferral is allowed. Undocumented deferral is not.

Labeling is a cybersecurity deliverable, and it is misbranding law

The section teams treat as a formality has the clearest statutory hook. FDA's guidance points at section 502(f) of the FD&C Act, which requires labeling to bear adequate directions for use, and 502(a)(1), under which a device is misbranded if its labeling is false or misleading in any particular.

FDA's examples of security information that may belong in labeling are concrete enough to work from: specifications for the cybersecurity controls recommended in the intended use environment, a list of network ports and interfaces with their functionality, traffic direction and approved destination endpoints, an SBOM made available to users on a continuous basis in machine-readable format, how users obtain version-identifiable manufacturer-authorized software, and how the device responds to anomalous conditions.

Note "on a continuous basis" in the SBOM item. That is a commitment to a process after clearance, not a document you attach once, and if you satisfy it through a portal FDA expects the links your users hold to stay current.

Check which edition you are working from

As of August 2026 the operative document is the February 3, 2026 guidance, whose cover states that it supersedes the June 27, 2025 edition of nearly the same name. The title changed with it, from Quality System Considerations to Quality Management System Considerations. If your regulatory memo cites the June 2025 edition, it is citing a superseded document. That is not automatically a substantive error, but it does tell you the material has not been refreshed this year, which is why we keep a regulatory radar rather than undated summaries.

When you should not hire a firm like ours

Four cases, against our own interest.

You have run the cyber device test and the answer is no. The definition turns on software, the ability to connect to the internet, and characteristics that could be vulnerable. That is a conversation with your regulatory lead, not an engagement.

Your architecture is not settled. An assessment of an undecided update mechanism prices a decision you have not made. Choose how patches reach the device, get the SBOM out of your build pipeline rather than a spreadsheet, then have someone review a design that exists.

You already produce threat models and architecture views internally. What you need from outside is the testing independence FDA asks you to characterize, not a second author for documents you can write.

Anyone promises acceptance or clearance. FDA has never offered that to anybody, and a firm implying its template guarantees a pass is telling you something useful about its other claims.

Where Top Floor fits

Our FDA cybersecurity practice covers the documentation set above and the process behind it: threat modeling, security architecture views, SBOM generation with the component support and end-of-support fields, the cybersecurity management plan, and coordinated vulnerability disclosure procedures. The device, firmware, API and cloud testing that produces the evidence sits under penetration testing, including the independence statement FDA asks for. When a manufacturer needs someone accountable for the security program between submissions rather than a team for one filing, that is vCISO work.

We do not clear devices and we do not speak for FDA, and we would rather name an architecture decision as the blocker than sell documentation around it.

How to decide this week

Open your draft eSTAR and check one thing: is there a real attachment behind every applicable cybersecurity question, and would a reviewer learn anything from it that a screener would not. That difference is your gap.

Then pull your SBOM and try to fill two columns for every third-party component, support status and end-of-support date. However long that takes is the honest estimate for the rest of this work, because it uses the same supplier-management muscle.

Then check your most recent security test report against FDA's five elements: testers and their independence, scope, duration, methods, results. If it cannot answer the first, book the independent test now. It is the longest lead time here and the one thing you cannot backdate.

Frequently asked questions

What happens if the cybersecurity section of my 510(k) eSTAR is incomplete?

FDA states that an eSTAR will be put on a Technical Screening hold if it does not contain accurate responses and relevant attachments in the Cybersecurity section. Screening is anticipated within 15 days of FDA receiving the eSTAR and begins only once the user fee has been paid. FDA notifies the submitter by email, identifies the incomplete information, and the 510(k) stays on hold until a complete replacement eSTAR is submitted. If that replacement is not received within 180 days of the deficiency notification, FDA considers the 510(k) withdrawn and closes it. For submissions that pass, the review clock starts on the day FDA received the submission.

What cybersecurity documents does FDA expect in a premarket submission?

Table 1 of FDA's February 3, 2026 premarket cybersecurity guidance lists six top-level documentation types: a cybersecurity risk management report, measures and metrics, architecture views, testing, labeling, and cybersecurity management plans. The risk management report breaks into a threat model, a cybersecurity risk assessment, an SBOM, a vulnerability assessment and software support documentation, an assessment of unresolved anomalies, and traceability. FDA notes that the table is not meant to be merely a deliverable checklist, and that documentation scales with the risk of the device.

Does FDA require penetration testing for a medical device submission?

The premarket cybersecurity guidance is nonbinding, so the accurate phrasing is that FDA recommends penetration testing among the types of testing to consider for inclusion, alongside security requirements, threat mitigation and vulnerability testing. What the guidance is specific about is the report: it should state the independence and technical expertise of the testers, the scope, the duration, the methods employed, and the results, findings and observations. Manufacturers are also asked to say how independent those testers were from the developers, and to provide the original report for any third-party testing.

Do I have to submit all four security architecture views?

FDA recommends providing at minimum a Global System View, a Multi-Patient Harm View, an Updateability/Patchability View, and Security Use Case Views, each with diagrams and explanatory text. The guidance gives two forms of relief: if one view sufficiently captures the risks of another, or if threat modeling documentation already captures a view, FDA does not expect duplicated documentation. If a view is not appropriate for a device, manufacturers are asked to explain why it is not included rather than leave it out silently. How many views you need scales with the architecture, so a device with only a USB interface needs fewer security use case views than one with cloud access.