The Food and Drug Administration issued revised medical device cybersecurity guidance in 2023 that establishes specific expectations for both manufacturers and healthcare organizations that purchase, deploy or operate networked medical devices. Leadership in hospitals, health systems and ambulatory care settings now faces accountability for security outcomes that cross clinical engineering, IT, compliance and legal functions, often without a clear owner or measurement framework.

The guidance addresses two phases: premarket requirements for manufacturers designing new devices, and postmarket obligations for managing devices already in clinical use. Both create immediate responsibilities for healthcare organizations, even when the organization has no direct relationship with the manufacturer or lacks visibility into what the device actually does on the network.

What the Guidance Requires and Why It Matters Now

The FDA now expects device manufacturers to build cybersecurity into the product lifecycle, maintain a software bill of materials (SBOM), coordinate vulnerability disclosure, and provide timely security updates. For healthcare organizations, this shifts the purchasing decision from a purely clinical and financial evaluation to one that includes verifiable security capability.

Organizations cannot assume that an FDA-cleared device meets adequate cybersecurity standards. The guidance is not a binding regulation and manufacturers adopt its recommendations at different speeds. Leadership must verify that devices entering the environment include basic security capabilities: secure configuration, update mechanisms, vulnerability management processes and coordinated disclosure channels.

The business consequence is direct. A networked medical device without adequate security controls becomes a pathway to patient data, clinical systems and operational infrastructure. A breach originating from an unmanaged infusion pump or imaging system creates HIPAA exposure, operational disruption, patient safety risk and reputational damage that extends well beyond the device itself.

The Accountability Gap in Most Healthcare Organizations

The typical healthcare organization distributes medical device security across multiple functions without clear ownership. Clinical engineering manages device inventory and maintenance contracts. IT operates the network and may enforce segmentation policies. Information security handles vulnerability scanning and incident response. Compliance tracks regulatory obligations. Legal reviews vendor contracts.

Each function addresses part of the problem, but no single leader owns the security outcome. This creates predictable failures:

  • Devices are purchased based on clinical need without security review
  • Manufacturers are not required to provide SBOMs, vulnerability disclosure processes or update timelines
  • Clinical engineering lacks authority to reject devices that fail security requirements
  • IT discovers unsupported devices on the network after deployment
  • Security teams cannot patch devices without clinical engineering approval
  • Compliance cannot report the organization's position because no one has measured it

Leadership is accountable for a result that no one has been clearly assigned to produce. This is not a resourcing problem or a training problem. It is a governance problem.

What the FDA Expects from Device Manufacturers

The premarket guidance describes what manufacturers should build into new devices before they reach the market. Healthcare organizations should understand these expectations because they define what to verify during procurement and what to demand in vendor contracts.

Manufacturers should provide a software bill of materials that lists all software components in the device, including open-source libraries and third-party modules. This allows organizations to identify devices affected by newly disclosed vulnerabilities without waiting for the manufacturer to assess and communicate risk.

Devices should support secure configuration, including the ability to disable unnecessary services, enforce authentication and enable logging. The manufacturer should document a vulnerability management process that includes coordinated disclosure, timely communication and a defined update mechanism.

The postmarket guidance addresses devices already in use. Manufacturers should monitor for vulnerabilities, assess impact, communicate risk to customers and provide security updates within a reasonable timeframe. Healthcare organizations should establish a process to receive, evaluate and deploy these updates in coordination with clinical workflows.

What Healthcare Organizations Must Verify and Enforce

The FDA guidance does not impose direct obligations on healthcare organizations, but HIPAA, state breach notification laws and emerging federal requirements create enforced accountability. Organizations must demonstrate that they have implemented reasonable safeguards, which now includes verifying that networked medical devices meet basic security standards.

This means changing the procurement process. Clinical engineering, IT and security must evaluate devices before purchase. The evaluation should confirm that the manufacturer provides an SBOM, maintains a coordinated vulnerability disclosure process, commits to timely security updates and supports secure configuration.

Contracts must include security obligations. The manufacturer should commit to vulnerability notification timelines, update delivery windows and end-of-support transparency. The organization should establish the right to audit security practices and the ability to terminate agreements if the manufacturer fails to meet defined security standards.

Once deployed, devices require continuous management. The organization must maintain an accurate inventory, monitor for vulnerabilities, assess impact against clinical workflows, test updates in a controlled environment and deploy patches according to risk priority. This requires coordination between clinical engineering, IT and security that most organizations have not formalized.

How This Connects to Broader Regulatory and Framework Readiness

Medical device security sits within a larger regulatory and risk management structure. The NIST Cybersecurity Framework provides a common language for describing and managing cybersecurity risk across different domains, including healthcare. Organizations that adopt the framework can map medical device security controls to its five functions: Identify, Protect, Detect, Respond and Recover.

HIPAA requires covered entities and business associates to implement administrative, physical and technical safeguards to protect electronic protected health information. Medical devices that store, process or transmit patient data fall within this scope. The Security Rule requires regular risk assessments, which must now include evaluation of medical device cybersecurity posture.

State breach notification laws impose reporting obligations when unauthorized access to personal information occurs. A compromised medical device that exposes patient data triggers these requirements. Organizations must demonstrate that they implemented reasonable security measures, which increasingly means showing that they verified device security before purchase and managed vulnerabilities after deployment.

Effective [regulatory and framework readiness](/vciso/) requires governance that connects compliance obligations to operational execution. This includes defining who makes risk decisions, establishing measurement criteria, maintaining audit evidence and reporting position to leadership and regulators.

Who Owns the Outcome and What Adequate Governance Looks Like

Medical device security requires executive ownership at the intersection of clinical safety, information security and regulatory compliance. In most healthcare organizations, this does not map cleanly to a single role. The chief information security officer may lack authority over clinical engineering. The chief nursing officer or chief medical officer owns patient safety but may not have cybersecurity expertise. The compliance officer tracks regulatory obligations but cannot enforce technical controls.

Adequate governance establishes a decision-making structure that brings these functions together under clear executive accountability. This typically takes the form of a medical device security committee or working group with representation from clinical leadership, engineering, IT, security, compliance and legal. The committee operates under a charter that defines scope, authority, decision rights and escalation paths.

The committee needs an executive sponsor with budget authority and the ability to enforce decisions across departmental boundaries. This is often the chief operating officer, chief financial officer or chief risk officer, depending on organizational structure. The sponsor is accountable to the board for the security posture of medical devices and reports on risk position, incidents and regulatory compliance.

Day-to-day execution requires defined processes for procurement review, vulnerability management, incident response and vendor management. These processes must specify who evaluates security requirements, who approves exceptions, who coordinates updates and who communicates with regulators following an incident. Without these definitions, the committee produces recommendations that no one has authority to implement.

Practical Next Steps for Leadership

Healthcare leadership should begin by establishing accountability. Assign a single executive to own medical device security posture and report on it quarterly. That executive should convene clinical engineering, IT, security, compliance and legal to define current state, identify gaps and establish a timeline for closing them.

The first measurable objective is procurement governance. Revise the purchasing process to require security evaluation before clinical engineering can recommend a device for approval. Create a simple checklist based on the FDA guidance: Does the manufacturer provide an SBOM? Is there a coordinated vulnerability disclosure process? What is the committed timeline for security updates? Can the device support secure configuration?

The second objective is inventory accuracy. Clinical engineering and IT should reconcile device inventories to produce a single authoritative list of networked medical devices, including manufacturer, model, software version, network location and support status. This list becomes the foundation for vulnerability management and incident response.

The third objective is vulnerability management process. Define how the organization will learn about device vulnerabilities, who assesses impact, who coordinates with manufacturers, who tests updates and who approves deployment. Establish service level objectives for each step based on vulnerability severity.

The fourth objective is vendor accountability. Review existing device contracts to identify security obligations. For new purchases, include contractual requirements for vulnerability disclosure, update timelines, end-of-support notification and audit rights. Establish criteria for terminating relationships with manufacturers that fail to meet security commitments.

The fifth objective is regulatory reporting position. Compliance should be able to describe the organization's medical device security program in response to HIPAA audits, state examinations or breach investigations. This requires documented policies, evidence of execution and metrics that demonstrate continuous improvement.

Many healthcare organizations lack the internal expertise to design this governance structure, translate FDA guidance into operational requirements or establish measurement frameworks that satisfy regulators. [Virtual CISO leadership](/vciso/) provides the executive ownership that closes this gap, delivering strategy, governance design, risk decision-making and regulatory positioning without the cost or complexity of a permanent hire.

If your organization is accountable for medical device security but lacks clear ownership or a path to measurable progress, a confidential consultation can clarify what adequate governance looks like in your specific environment and how to build it in a way that boards, regulators and auditors will recognize as reasonable.

Sources

  1. Cybersecurity Framework | NIST , www.nist.gov
  2. Privacy and Security | Federal Trade Commission , www.ftc.gov
  3. Privacy Framework | NIST , www.nist.gov

Related service: Regulatory and Framework Readiness

Readiness for the frameworks and regulations that genuinely apply to you, NIST CSF, ISO 27001, SOC 2, CMMC, HIPAA, PCI DSS and SOX-related IT controls, with the evidence maintained between assessments.

Read about Regulatory and Framework Readiness