Secure by Design:
Meeting FDA Interoperability Requirements for Connected Medical Devices
The number of connected medical devices in active clinical use has grown substantially. Infusion pumps communicate with pharmacy management systems. Patient monitors stream vitals to electronic health records. Diagnostic imaging devices transmit across hospital networks. These connections improve care coordination -- and they expand the attack surface.
FDA has made its position clear: cybersecurity in connected medical devices is an engineering problem that must be solved during design, not patched after deployment. For manufacturers building devices that communicate with other devices, systems, or networks, understanding how FDA's cybersecurity and interoperability frameworks intersect is now a premarket requirement.
What Changed: Section 524B of the FD&C Act
The Consolidated Appropriations Act, 2023, signed into law on December 29, 2022, amended the Federal Food, Drug, and Cosmetic Act by adding section 524B, titled "Ensuring Cybersecurity of Devices." The provision took effect on March 29, 2023.
Under section 524B, any person submitting a 510(k), premarket approval (PMA), De Novo, product development protocol (PDP), or humanitarian device exemption (HDE) for a "cyber device" must include specific cybersecurity information in that submission. A cyber device is broadly defined as a device that includes software and is capable of connecting to the internet or to another device or system.
Section 524B(b) establishes three core requirements:
-
A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits
-
Processes designed to provide reasonable assurance that the device and related systems are cybersecure, including a process for postmarket updates and patches
-
A software bill of materials (SBOM) covering commercial, open-source, and off-the-shelf software components
FDA issued final guidance on September 27, 2023, titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions." The agency issued a critical update to the guidance on June 27, 2025, adding a dedicated section addressing FDA's recommendations for section 524B compliance for cyber devices. This was followed by another substantial revision on February 3, 2026, which explicitly integrated these requirements with the newly effective Quality Management System Regulation (QMSR) and ISO 13485. Manufacturers preparing premarket submissions for connected devices should work from the February 2026 guidance.
FDA also published a "refuse to accept" policy for cyber devices, making clear that premarket submissions missing required cybersecurity elements will not be accepted for substantive review.
What Secure by Design Means In Practice
Secure-by-design is a development philosophy: security requirements are established early in design and are traceable through the development lifecycle, rather than added as a corrective measure after testing. For connected medical devices, this means cybersecurity is a design input -- governed by the same design controls process that governs functional requirements.
Practically, secure-by-design for a connected device involves three activities during design:
Threat modeling as a design control activity. Before interface specifications are finalized, manufacturers should model the threats each connection creates. What data moves across this interface? Who is authorized to initiate or receive that data? What is the consequence if this interface is compromised or behaves unexpectedly? Furthermore, does the model capture risks introduced through the software supply chain, maintenance activities, and eventual device decommissioning? Threat modeling done during design controls generates testable requirements -- not a checklist completed at submission.
Cybersecurity requirements as formal design inputs. Under FDA's Quality Management System Regulation (QMSR), which took effect in February 2026 and incorporates ISO 13485, design and development inputs must address all risk sources including cybersecurity. Authentication protocols, encryption standards, access controls, and audit logging belong in the design input specification, documented before design outputs are generated.
Defense-in-depth architecture. No single control should be treated as sufficient for a connected device. Manufacturers should design layered defenses: assume individual controls may fail, and verify that a single failure does not produce an unacceptable safety or security outcome.
Interoperability and Secure Interface Specification
Interoperability -- the ability of a device to safely, securely, and effectively exchange and use information with another device or system -- raises cybersecurity questions that are specific to interface design.
In 2017, FDA issued "Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices." This guidance frames the key design questions manufacturers should address for each electronic interface: the type of data exchanged, the intended behavior, and the security controls that govern that exchange.
For each interface in a connected device, the specification should address:
-
What data is exchanged and under what conditions
-
Who the anticipated users are (e.g., IT professionals, clinical user, patients) and what specific labeling or instructions they need to safety connect and configure the interface
-
Who or what is authorized to initiate, receive, or modify data across the interface
-
What authentication or verification is required at the connection point
-
What the device does when the connection is interrupted, degraded, or behaves unexpectedly
-
How the device handles unexpected or malformed data from a connected system
The design question is not only "can this device exchange data?" It is: "under what security conditions, with what authorization checks, and with what failure behavior?"
FDA recognizes several consensus standards relevant to interoperable device communication, including ANSI/AAMI 2700-1 (2019) for wireless medical telemetry and ISO/IEEE 11073 device communication standards. For imaging devices, NEMA PS 3.1-3.20 DICOM standards govern communication and management of medical imaging information.
The SBOM: What Design Teams Need to Build
Section 524B's software bill of materials requirement has practical implications for how engineering and quality teams manage components in connected devices.
An SBOM is only operationally useful if it is accurate, complete, and maintained over the product lifecycle. This requires:
-
Tracking software components during development, not reconstructing the list at submission
-
Generating a machine-readable SBOM that meets NTIA minimum elements. This includes precise version information sufficient to identify whether a component is affected by a known vulnerability (using Common Vulnerabilities and Exposures, or CVE, identifiers), while explicitly documenting each component’s current level of support (e.g., actively maintained, abandoned) and its official end-of-support date.
-
Maintaining processes to update the SBOM when components change after clearance or approval
FDA's postmarket expectation is that manufacturers can identify vulnerabilities in fielded devices and push security updates when needed. Gaps in SBOM completeness translate directly into gaps in the manufacturer's ability to respond to a postmarket cybersecurity event.
What To Do Now
If your organization is developing a connected medical device or approaching a premarket submission, here are the practical priorities:
Review your design controls process for cybersecurity. Threat modeling and security requirements should be traceable design inputs, not supplemental documents produced late in development.
Audit your interface specifications. For each electronic interface in your device, confirm that the specification addresses data type, authorization, authentication, and failure behavior.
Build your SBOM process early. Document every commercial, open-source, and off-the-shelf software component from the start of development and build a process to maintain that inventory.
Map your postmarket surveillance to cybersecurity. Your vulnerability monitoring and response plan should be device-specific, tied to your actual software components and connectivity profile.
Confirm your premarket submission covers section 524B. Verify that your submission addresses all required elements and that you are working from the June 2025 final guidance.
Closing Thought
The connected medical device ecosystem will continue to expand. Cybersecurity requirements will continue to evolve with it. Manufacturers that integrate secure-by-design thinking into their development process -- from threat modeling through interface specification through SBOM tracking -- are better positioned for premarket review and for the long-term security performance of their devices in the field.
Rook works with medical device manufacturers to assess design controls, support premarket submission preparation, and review cybersecurity program readiness. If your organization is building a connected device and wants an independent perspective, reach out to start the conversation.