Cybersecurity

Almost certainly. Section 524B(c) defines a cyber device as one that "(1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats." FDA reads all three broadly (Section VII.B): firmware and programmable logic are software; the ability to connect counts "whether intentionally or unintentionally, through any means"; and the illustrative list of connecting features includes network, server and cloud connections, Wi-Fi, cellular, Bluetooth and BLE, magnetic inductive links, and hardware connectors such as USB, ethernet and serial ports.

If you file a 510(k), PMA, PDP, De Novo or HDE for a cyber device, Section 524B(a) requires the cybersecurity information in the submission. Devices with cybersecurity risk that fall outside the definition still get the same documentation recommendations (Section IV.D); the difference is that for cyber devices the three obligations in 524B(b) are statute, not guidance.

Section 524B(b) requires the manufacturer of a cyber device to:

• Submit "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures" (524B(b)(1)).
• "Design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure," and make updates and patches available on a reasonably justified regular cycle for known unacceptable vulnerabilities and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks (524B(b)(2)).
• Provide a software bill of materials "including commercial, open-source, and off-the-shelf software components" (524B(b)(3)).

Failure to comply with 524B(b)(2) is a prohibited act under section 301(q) of the FD&C Act (Section IV.D). That is the sentence to show whoever is deciding whether cybersecurity is optional this quarter.

Strip the guidance down and the submission asks for four things you build and one thing you assemble: a threat model, a cybersecurity risk assessment, a software bill of materials with its vulnerability assessment, and a cybersecurity management plan for the postmarket years. The security risk management report (Section V.A) wraps the first three together with the unresolved anomaly assessment and, crucially, "traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation." Security architecture views and the test reports are the evidence that the four documents describe a real device.

Documentation "is expected to scale with the cybersecurity risk of that device" (Section IV.D). A single-USB-port instrument needs one global view and a handful of use cases. A networked, cloud-connected system with a commercial operating system needs several views and many use cases (Appendix 4). Nobody gets to skip a document type; the depth is what scales.

Three people, minimum, even in a company of ten. The engineer who knows every interface and every third-party component, because the SBOM and the architecture views come from them. The person who owns the risk file, because the guidance wants a separate security risk assessment that feeds the safety risk assessment, not a security column bolted onto the FMEA (Section V.A). And whoever will still be answering for the device in year three, because the management plan names "personnel responsible" and the metrics are reported in PMA annual reports (Sections V.A.6 and VI.B). If no one on the team has run a threat model or a penetration test, that is the gap to close before stage 01, not after.

The guidance recommends that "device manufacturers utilize the FDA Q-submission process to discuss design considerations for cybersecurity risk management throughout the device lifecycle with the agency" (Section V.B.1). Cybersecurity is one of the example review topics named in the Q-Sub guidance, alongside biocompatibility and bench testing. A Pre-Sub carries no user fee and FDA's goal is written feedback within 70 days, with a meeting around day 70 to 75 if you ask for one.

Feedback is most useful "prior to execution of planned testing." For cybersecurity that means before you commission the penetration test and before the architecture is frozen, because the two findings that most often send teams back to redesign are an interface with no security control beneath the protocol (Section V.A.3) and an update path that crosses technology you do not control (Section V.B.2.c).

Keep cybersecurity to one substantial topic with two or three questions, inside a Pre-Sub of no more than three or four topics and seven to ten questions total. Give FDA enough to answer: a draft global system view showing every interface, the list of third-party components you already know about, the security controls you plan across the eight categories, and your proposed testing scope. Then ask directed questions.

Questions worth asking:

• Is the proposed set of security architecture views (global, multi-patient harm, updatability, and the listed use cases) sufficient for this device, or does FDA expect additional views?
• Does FDA agree that the planned security controls beneath the Bluetooth Low Energy interface are appropriate, given the assumption that the network is hostile?
• Is the planned scope of penetration testing (interfaces, duration, tester independence) adequate to support the submission?
• For components with no published end-of-support date, is the proposed justification and monitoring approach acceptable?

FDA's written feedback is not binding on you, but a later submission that departs from it should say why. Read the answer for three signals: the views FDA asks for beyond your list, any interface it names specifically, and any phrase about lifecycle expectations such as periodic testing or update timelines. Those are the sections the reviewer will open first when the 510(k) lands. You draft the meeting minutes and file them within 15 days; the FDA-edited version is the official record, so make sure the cybersecurity commitments are captured in the words you can live with.

Threat modeling should run "throughout the design process and be inclusive of all medical device system elements" (Section V.A.1). The model has to do three things: identify system risks and mitigations and inform the pre- and post-mitigation risks in the risk assessment; state its assumptions about the environment, with FDA's own example being that "hospital networks are inherently hostile, therefore manufacturers are recommended to assume that an adversary controls the network with the ability to alter, drop, and replay packets"; and capture risks introduced through the supply chain, manufacturing, deployment, interoperation, maintenance and update, and decommission.

Submit the documentation plus the rationale for the methodology you chose. FDA does not prescribe one; the MDIC/MITRE Playbook for Threat Modeling Medical Devices is the resource it points to. The architecture views in Section V.B.2 are the natural place to present the model, and FDA says it does not expect you to duplicate documentation when a view already captures it.

This is a separate document from the ISO 14971 safety risk assessment, and the guidance spends a page explaining why (Section V.A.2). Security risk is assessed on exploitability, "or the ability to exploit vulnerabilities present within a device and/or system," not on probabilistic likelihood. The assessment captures the risks and controls from the threat model, the scoring method pre- and post-mitigation, the acceptance criteria, and the method for transferring security risks into the safety risk assessment.

Two hard lines. Vulnerabilities in CISA's Known Exploited Vulnerabilities Catalog "should be designed out of the device." And if a penetration tester could exploit something, assume a threat actor's ability to do so "is likely to increase over the device lifecycle," which is why deferring pentest findings draws deficiencies. FDA points to AAMI TIR57 and ANSI/AAMI SW96 for the plan and report.

Interoperability gets its own paragraph (Section V.A.3): for every interface to other devices, other functions, healthcare infrastructure or general computing platforms, assess whether "added security controls beneath such communication are needed," with Bluetooth Low Energy as the worked example.

All software, proprietary and third-party, should be assessed for cybersecurity risk, and you should keep custodial control of source code through escrow or backups (Section V.A.4). The SBOM should be machine-readable and consistent with the NTIA minimum elements, cover upstream dependencies, and add two things per component: the level of support ("actively maintained, no longer maintained, abandoned") and the end-of-support date. If you cannot provide something, provide the justification.

Then the part teams skip: identify all known vulnerabilities in the device and its components, including any in CISA's KEV catalog, describe how you found them, and for each one provide a safety and security risk assessment with device and system impacts, and the controls that address it, with compensating controls described in detail. Include plans for how components could be updated or replaced if support ends. Section VII.C.3 confirms that for cyber devices the SBOM is a statutory requirement.

Unresolved software anomalies get a security assessment too (Section V.A.5), including any CWE categories present, because "a threat might seek out these types of anomalies, and identify means to exploit them."

"Effective cybersecurity relies upon security being 'built in' to a device, and not 'bolted on' after the device is designed" (Section V.B.1). FDA expects controls from eight categories, each with requirements and acceptance criteria in the submission and evidence that they were implemented and tested: authentication; authorization; cryptography; code, data and execution integrity; confidentiality; event detection and logging; resiliency and recovery; and updatability and patchability. Appendix 1 details each one.

Present the architecture as views, diagrams plus explanatory text (Section V.B.2 and Appendix 2). At minimum: a global system view with every internal and external connection including update infrastructure and cloud; a multi-patient harm view showing how the system defends against and responds to attacks that could harm many patients at once; an updatability and patchability view describing "the end-to-end process that permits software updates and patches to be provided" to the device, including the parts of that path you do not control; and security use case views for every function where a compromise could touch safety, across operational and clinical states. If a view does not apply, explain why rather than omitting it.

"Cybersecurity controls require testing beyond standard software verification and validation activities" (Section V.C). Submit the security testing documentation and reports across four types: security requirements testing, with evidence each design input was implemented and your boundary analysis; threat mitigation testing, showing each risk control works against the threat model in the views; vulnerability testing, including abuse and misuse cases, fuzzing, attack surface analysis, vulnerability chaining, closed-box scanning, software composition analysis of binaries, and static and dynamic analysis including hunting for hardcoded or default credentials; and penetration testing.

The penetration test report must state the independence and technical expertise of the testers, the scope, the duration, the methods, and the results, findings and observations. Provide the original third-party report, not a summary, plus your own assessment of every finding and the rationale for anything deferred. Deferred items need a plan: which release fixes them, when, whether interim devices get the update, and how long deployment takes.

Testing "should occur throughout the SPDF," and after release "at regular intervals commensurate with the risk (e.g., annually)."

The cybersecurity management plan (Section VI.B) is what satisfies 524B(b)(1), and FDA recommends submitting it with the premarket submission. It should include: personnel responsible; sources, methods and frequency for monitoring and identifying vulnerabilities, such as researchers, NIST NVD and third-party software manufacturers; how you identify and address CISA KEV entries; periodic security testing; the timeline to develop and release patches; update processes; patching capability, meaning the rate at which an update can reach devices; the coordinated vulnerability disclosure process; and how you will communicate forthcoming remediations, patches and updates to customers.

Section VII.C.1 adds the timelines with justification: a "reasonably justified regular cycle" for known unacceptable vulnerabilities, and out-of-cycle updates "as soon as possible" for critical vulnerabilities that could cause uncontrolled risks. The length of the regular cycle depends on risk; the justification belongs in the plan.

Metrics come with it (Section V.A.6). At minimum track and report the percentage of identified vulnerabilities patched, the time from identification to patch, and the time from patch availability to field implementation, with averages over time. If you have no marketed version yet, write the metrics into the plan anyway.

eSTAR walks the cybersecurity content attachment by attachment. Appendix 4 of the guidance is the map: a cybersecurity risk management report (Sections V and VI.B) containing the threat model with architecture views, the cybersecurity risk assessment, the SBOM, the vulnerability assessment and software support information, the unresolved anomalies assessment, and traceability; measures and metrics; architecture views with requirements; testing; labeling; and the cybersecurity management plan. FDA says the table "is not intended to serve as merely a deliverable checklist," but it is the most reliable list of what a reviewer expects to find.

The nine cybersecurity deliverables counted in the eSTAR guide below are the same set from the other side of the form. The property reviewers check first is agreement: the interfaces in the threat model are the interfaces in the views are the interfaces in the test report.

Cybersecurity labeling is part of the submission and, for cyber devices, part of demonstrating reasonable assurance (Section VI.A). FDA's examples of what to include: recommended cybersecurity controls for the use environment; diagrams users need to implement them; a list of network ports and interfaces with direction and approved endpoints; infrastructure requirements and instructions for secure deployment and for responding to an incident; the SBOM, provided to users on a continuous basis in machine-readable form; how users obtain version-identifiable manufacturer-authorized software; how the device responds to and logs security events; features that protect critical functionality; backup and restore; the secure configuration as shipped and which user changes raise risk; how forensic evidence is captured; end of support and end of life, if known; and secure decommissioning.

Instructions have to be "understandable to the intended audience, which might include patients or caregivers with limited technical knowledge," and any risk you transfer to the user should show up as a task in human factors testing. An MDS2 form and the JSP2 customer security documentation can cover a good part of this list.

Inadequate cybersecurity information in labeling can make a device misbranded under section 502(f) or 502(j) (Section IV.D), and for cyber devices FDA can find that a submission lacks a reasonable assurance of cybersecurity, which it treats as part of safety and effectiveness (Section VII.E). In a 510(k), FDA considers changes in the environment of use and new risks in the technological characteristics compared with the predicate, and its own example ends in a not substantially equivalent determination for a device without the encryption to meet a recently identified threat.

Before you file: the SBOM opens and is machine-readable; every view is present or explicitly justified as inapplicable; the penetration test report is the original and carries tester independence, scope, duration and methods; deferred findings have a plan; the management plan names people, sources, cadence and timelines; and the labeling list above has an answer for every item.

Answer every deficiency in the order it was asked, quote the deficiency, state what changed, and attach the evidence. The recurring cybersecurity deficiencies map to specific sections of the guidance: a threat model without assets, interfaces or attack vectors (V.A.1); a risk assessment that never ties vulnerabilities to patient safety (V.A.2); a summary instead of a full penetration test report (V.C); missing views (V.B.2); an SBOM with no vulnerability assessment behind it (V.A.4); a management plan with no periodic testing or patch timelines (VI.B, VII.C.1). Respond with the artifact the section describes, not a narrative about it.

If the letter reads as unclear, duplicative, or contrary to earlier feedback, file a Submission Issue Request through the Q-Sub program. FDA's goal is feedback within 21 days when the SIR arrives within 60 days of the letter, and 70 days after that. A SIR discusses your planned approach; it does not pre-review your response and it does not pause the 180 days.

The most common deficiency language, and what closes each item, is collected in the guide below. Read it before you file, not after the letter arrives. The pattern is the same every time: reviewers cross-examine documents against each other, and the seams are where the questions come from.

"Cybersecurity risks may continue to be identified throughout the device's TPLC. Manufacturers should ensure they have appropriate resources to identify, assess, and mitigate cybersecurity vulnerabilities as they are identified throughout the supported device lifecycle" (Section V.A.6). Keep the threat model and risk assessment updated as new threats, vulnerabilities and assets appear, so a new CVE can be assessed against the architecture in hours instead of weeks. If updates are not applied automatically, every fielded version has its own risk profile and vulnerabilities have to be assessed against each of them.

Testing continues "at regular intervals commensurate with the risk (e.g., annually)" (Section V.C), and the three metrics in Section V.A.6 are reported in PMA annual reports and in the next premarket submission.

The 524B(b)(2) timelines are now live: known unacceptable vulnerabilities patched on the reasonably justified regular cycle you wrote into the plan, critical vulnerabilities that could cause uncontrolled risks patched out of cycle as soon as possible (Section VII.C.1). FDA's Postmarket Cybersecurity Guidance governs whether a vulnerability is controlled or uncontrolled and when 21 CFR Part 806 reporting applies. Coordinated vulnerability disclosure covers external reports from researchers and suppliers, vulnerabilities you find yourself, and the procedures for telling users, customers and patients.

Modifications bring you back under 524B (Section VII.D). Changes to authentication or encryption, new connectivity, or a changed update mechanism need the full documentation. Changes unlikely to affect cybersecurity, such as materials or sterilization, still need the plan (or a reference to it and a summary of changes), a statement of whether any critical vulnerabilities exist and whether any uncontrolled risks were remediated since the last authorization, and the SBOM.