What Healthcare Organizations Must Implement Under the FDA's January 2024 Refuse to Accept Policy for Medical Device Cybersecurity

The FDA's Refuse to Accept policy for medical device cybersecurity, effective October 1, 2024, requires manufacturers to demonstrate specific cybersecurity design controls in premarket submissions. Submissions for 510(k), De Novo, and PMA pathways that lack this documentation will not be accepted for substantive review. This policy addresses cybersecurity as a safety and effectiveness requirement, not an administrative preference.

The policy creates a distinct challenge for leadership: accountability for a security outcome without clear ownership, a defined sequence of work, or a way to measure progress against regulatory expectations. This article explains what the FDA will refuse to accept, what must be included in a software bill of materials, and how regulatory affairs, quality, and engineering leadership can establish adequate ownership.

What the FDA Will Refuse to Accept

Starting October 2024, the FDA will refuse to accept premarket submissions—510(k), De Novo, and PMA—that do not contain documentation demonstrating the manufacturer's adherence to specific cybersecurity design principles. This is not a discretionary review factor. Submissions without this content will be returned without substantive evaluation.

The policy applies to submissions for devices that contain software or that connect to another device, network, or system. It does not apply to submissions for devices already legally marketed before the effective date, but it does apply to subsequent submissions for those devices, including supplements.

Required Cybersecurity Design Documentation

Manufacturers must document how the device design addresses four cybersecurity objectives specified by the FDA:

• The device and related systems can identify and protect against reasonably anticipated cybersecurity threats.
• The device and related systems can detect cybersecurity incidents in a timely manner.
• The device and related systems can respond to and contain the impact of cybersecurity incidents.
• The device and related systems can recover capabilities or services compromised by a cybersecurity incident.

These objectives correspond to the NIST Cybersecurity Framework functions: Identify, Protect, Detect, Respond, and Recover. The submission must show how design controls incorporate these objectives throughout the device lifecycle, including how the manufacturer plans to address vulnerabilities discovered after market release.

Software Bill of Materials Requirements

The policy requires a Software Bill of Materials (SBOM) for devices that contain software, including firmware. The SBOM must identify commercial, off-the-shelf software and open-source software components. This requirement addresses the FDA's position that manufacturers must know what software is in their devices to manage vulnerabilities and provide timely updates.

The SBOM must include:

• The name of each software component.
• The version of each component.
• Supplier or author information for each component.
• Unique identifiers for each component, where applicable.
• Dependencies and relationships between components.

The SBOM is not merely an inventory. It must be maintained in a machine-readable format that supports automated vulnerability scanning and lifecycle management. The manufacturer must describe how the SBOM will be kept current as the device software is updated post-market.

Demonstrating Cybersecurity Design Controls

Manufacturers must demonstrate that cybersecurity was designed into the device, not added as an afterthought. This requires evidence of threat modeling, risk analysis specific to cybersecurity, and verification and validation activities that test security controls.

Design documentation must address:

• Threat modeling that identifies reasonably foreseeable cybersecurity risks based on the device's intended use environment.
• Security architecture and design decisions that mitigate identified threats.
• Testing and validation evidence showing that security controls function as intended.
• A plan for monitoring, identifying, and addressing cybersecurity vulnerabilities throughout the device lifecycle.
• Procedures for timely deployment of security updates and patches.

The FDA expects manufacturers to follow a structured approach consistent with recognized standards, such as IEC 62304 for medical device software lifecycle processes and IEC 81001-5-1 for health software and health IT systems security. Submissions should reference these standards and explain how the manufacturer's design controls align with them.

Who Is Accountable Inside the Organization

The Refuse to Accept policy creates a cross-functional accountability problem. Regulatory affairs owns the submission. Quality owns design controls and validation. Engineering owns the technical implementation. None of these functions traditionally owns enterprise cybersecurity risk decisions.

Adequate ownership requires:

• A single executive accountable for the organization's cybersecurity posture across all device submissions, not just individual products.
• Authority to make risk decisions that affect design, development timelines, and post-market support obligations.
• Direct reporting to executive leadership or the board on regulatory cybersecurity readiness.
• Responsibility for maintaining and updating the organization's threat modeling framework, security architecture standards, and vulnerability management processes.
• Oversight of cross-functional coordination between regulatory affairs, quality, engineering, and IT.

Many medical device manufacturers do not have this role established. IT security teams focus on corporate networks. Engineering teams focus on product functionality. Quality teams focus on validation. The strategic cybersecurity leadership required to satisfy the FDA policy often has no owner.

The Business Consequence of Inadequate Ownership

The consequence of inadequate ownership is not merely a refused submission. It is delay in market entry, revenue impact from postponed product launches, and competitive disadvantage as peers with established cybersecurity governance clear the FDA more efficiently.

More broadly, the policy signals that cybersecurity is now a design control subject to the same rigor as mechanical safety, biocompatibility, and electrical safety. Organizations that treat it as a checklist exercise rather than a governance discipline will face escalating regulatory friction as the FDA refines its expectations and enforcement posture.

How This Relates to Regulatory and Framework Readiness

The FDA's Refuse to Accept policy is not isolated. It reflects a broader regulatory pattern: cybersecurity requirements that assume organizations have mature governance, documented risk decisions, and executive accountability. The NIST Cybersecurity Framework, referenced explicitly in FDA guidance, provides a common structure for this governance.

Regulatory and framework readiness means an organization can demonstrate, at any time, how it identifies cybersecurity risk, what decisions have been made to address that risk, who made those decisions, and how those decisions are reflected in design controls, policies, and incident response capabilities. This readiness is not product-specific. It is an enterprise capability that supports all submissions and all regulatory interactions.

For medical device manufacturers, this readiness increasingly determines the pace at which new products can reach market and the cost of maintaining regulatory compliance across a portfolio.

Practical Next Steps for Leadership

Leadership should take four immediate actions:

First, audit current and planned submissions against the Refuse to Accept criteria. Identify which submissions lack documented cybersecurity design controls, threat modeling, or an SBOM. Determine the timeline impact of completing this documentation.

Second, identify the current owner of cybersecurity risk decisions at the enterprise level. If no single executive has this accountability, decide whether to assign it to an existing role or establish new leadership. This decision cannot be delegated to working groups or committees.

Third, establish a baseline cybersecurity governance framework that aligns with the NIST Cybersecurity Framework and FDA expectations. This framework should define how threats are modeled, how risk decisions are documented, how security architecture is standardized across products, and how vulnerabilities are managed post-market.

Fourth, create a repeatable process for generating and maintaining SBOMs. This process must integrate with product development workflows, not operate as a manual documentation exercise after the fact.

When to Consider Virtual CISO Leadership

Medical device manufacturers face a timing problem: they need executive cybersecurity leadership now to meet the October 2024 enforcement date, but they may not have the volume of submissions or the enterprise scale to justify a full-time Chief Information Security Officer with regulatory expertise.

This is the scenario where [virtual CISO (vCISO) leadership](/vciso/) provides the most value. A vCISO establishes the governance framework, makes the risk decisions, provides regulatory positioning, and ensures submissions meet FDA expectations without requiring the organization to hire, onboard, and support a full-time executive.

The vCISO role is not consulting. It is accountable executive leadership delivered on a fractional basis. The vCISO owns the cybersecurity program, reports to the CEO or board, and serves as the single point of accountability the FDA policy assumes exists.

If your organization has submissions planned for the remainder of 2024 or early 2025 and does not yet have a clear owner of cybersecurity risk at the executive level, a confidential consultation can clarify whether vCISO leadership addresses the gap. Heights Consulting Group offers this consultation without obligation to organizations facing this decision.