Medical Device Cybersecurity Guidance — September 26, 2023

The U.S. Food and Drug Administration (FDA) issued its final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, on 26 September 2023. The document supersedes earlier drafts and aligns with statutory changes enacted in the Consolidated Appropriations Act, 2023, which added Section 524B to the Federal Food, Drug, and Cosmetic Act. Starting 1 October 2023, most “cyber devices” seeking FDA clearance must include plans for monitoring, identifying, and addressing vulnerabilities; design secure product life-cycle processes; and provide a software bill of materials (SBOM). Governance, risk, and compliance teams across device manufacturers now need to orchestrate enterprise-wide programmes that satisfy FDA reviewers, protect patient safety, and preserve the evidentiary records necessary for HIPAA and state privacy DSAR responses.

The guidance emphasises that cybersecurity is a quality system issue. Manufacturers must integrate security risk management into their quality management systems (QMS), linking it to 21 CFR Part 820 (or the forthcoming Quality Management System Regulation) processes for design controls, corrective and preventive action (CAPA), and production. Boards should oversee whether management has assigned clear accountability for cybersecurity throughout the product life cycle, including secure product development, vulnerability disclosure, update deployment, and incident response. Governance charters should mandate regular reporting to directors or risk committees on threat trends, vulnerability backlogs, and remediation status. Those reports should also capture DSAR metrics, because patient and provider requests for cybersecurity documentation or logs may surge after a vulnerability disclosure or adverse event.

FDA expects device sponsors to submit a cybersecurity risk management report alongside traditional design documentation. The report should demonstrate how manufacturers identify assets, threats, and vulnerabilities; assess exploitability and potential patient harm; and implement controls commensurate with risk. It references consensus standards such as AAMI TIR57 for threat modeling and ISO/IEC 81001-5-1 for secure product development. Implementation teams should establish risk assessment templates, maintain traceability matrices linking hazards to mitigations, and ensure independent reviewers validate findings. Because these analyses may rely on patient usage data, clinical workflow observations, or connectivity logs that contain personal information, privacy officers must evaluate how data is collected, anonymised, and retained so DSAR requests can be fulfilled without exposing proprietary security information.

The guidance requires a Secure Product Development Framework (SPDF) that covers the entire device life cycle. FDA highlights core practices: security risk management, security architecture, secure coding and verification, vulnerability management, and security documentation. Manufacturers should create governance forums that integrate engineering, regulatory affairs, quality, clinical, and privacy teams to oversee SPDF execution. Implementation can progress through phased milestones—first documenting existing practices, then filling gaps in secure coding standards, automated testing, and penetration testing, and finally institutionalising continuous monitoring and incident response. SPDF artefacts, including test reports, threat models, and patch plans, should be catalogued in document control systems with metadata that allows DSAR teams to confirm whether specific patient data was used during development or validation.

SBOMs receive explicit attention. FDA expects machine-readable SBOMs that list commercial, open-source, and off-the-shelf software components, including supplier names, versions, and known vulnerabilities. Governance teams should assign ownership for SBOM maintenance, integrate it into supplier management programmes, and automate updates when components change. SBOM repositories should interface with vulnerability intelligence tools to flag emerging risks. Because SBOMs can reveal sensitive information about third-party components, manufacturers must protect distribution channels and ensure that any DSAR responses referencing SBOM data respect intellectual property restrictions while still meeting legal obligations. For example, patient requests may focus on whether vulnerable libraries were present when a device captured their data, requiring privacy teams to coordinate with product security experts to craft accurate responses.

Section 524B compels manufacturers to develop vulnerability handling and post-market monitoring plans. FDA expects sponsors to describe how they will receive, assess, and communicate vulnerability reports; how they will coordinate with Information Sharing and Analysis Organizations (ISAOs); and how they will deploy updates throughout the device life cycle. Implementation teams should establish incident response runbooks that align with FDA’s Postmarket Cybersecurity Guidance, coordinate with Coordinated Vulnerability Disclosure (CVD) programmes, and map triggers that necessitate Medical Device Reporting (MDR) or Safety Communications. These processes generate logs, correspondence, and investigative files that may be subject to DSARs from providers, hospitals, or patients seeking to understand if their data or treatments were impacted. Maintaining structured repositories with access controls and retention schedules enables organisations to respond promptly while preserving evidence for FDA inspections.

The guidance underscores the need for secure configuration and logging. Devices should provide configurable authentication, role-based access controls, cryptographic protections, and logging capabilities that support forensic analysis. Manufacturers must define how logs are protected, transmitted, and retained, and they should include mechanisms for customers to export logs during investigations. Privacy offices should collaborate with product teams to ensure log data minimises personal information while remaining useful for safety monitoring. DSAR procedures should account for log access, providing redacted copies to patients or caregivers when legally required and documenting any exemptions (such as when releasing certain security details could create significant risk).

FDA recommends that sponsors supply a plan for cyber incident response and recovery, including business continuity, disaster recovery, and communication strategies. Boards should verify that these plans integrate with enterprise crisis management, HIPAA breach notification, and regulatory reporting obligations. Implementation exercises should test decision-making under simultaneous regulatory reporting, DSAR intake, and public communications. For example, a coordinated exercise might simulate a ransomware attack on a connected infusion pump fleet, requiring teams to notify FDA, alert hospitals, manage patient DSARs requesting treatment logs, and deploy patches across geographies.

The final guidance clarifies reviewer expectations for premarket submissions. 510(k) summaries, De Novo requests, and PMA submissions should include cybersecurity design details, residual risk rationales, testing evidence, and labeling that informs users about security controls and responsibilities. Sponsors must detail customer roles in managing passwords, installing updates, and monitoring logs. Implementation teams should prepare customer education materials, service agreements, and field service procedures that reinforce these obligations. Privacy officers should ensure that customer guidance includes instructions for handling patient data when sharing logs with manufacturers, including consent requirements, redaction procedures, and DSAR escalation paths.

Finally, the guidance encourages collaboration with healthcare delivery organisations and third-party service providers. Manufacturers should build governance mechanisms for sharing vulnerability information, distributing updates, and collecting feedback from hospitals and clinics. Contracts should delineate responsibilities for protecting patient data during support activities, and they should specify how DSAR requests received by providers will be coordinated with manufacturers. By embedding cybersecurity expectations into QMS processes, implementation roadmaps, and privacy programmes, device makers can meet FDA’s enhanced scrutiny, safeguard patient safety, and maintain trust with regulators and care providers.