FDA Medical Device Cybersecurity: Section 524B, SBOM & QMSR

Connected medical devices are everywhere in modern healthcare. Infusion pumps that report dosing data to the EHR. Patient monitors that stream vitals to nursing stations. Imaging systems that push DICOM studies to PACS servers. Wearable sensors that transmit remote patient monitoring data to cloud platforms. Every one of these device-to-system data flows represents both a clinical capability and a cybersecurity attack surface — and as of 2023, a binding pre-market obligation under FDA cybersecurity guidance.

The FDA has responded with increasingly specific cybersecurity requirements for medical devices, culminating in Section 524B of the Food, Drug, and Cosmetic Act (added by the Consolidated Appropriations Act of 2023). These requirements fundamentally change what device manufacturers and healthcare organizations must do to secure connected medical devices throughout their lifecycle.

This guide covers the regulatory landscape, the technical requirements, and the practical implications for teams that build, integrate, and maintain connected medical devices.

Key takeaways:

• Section 524B took effect March 29, 2023 — cybersecurity is now a statutory premarket requirement.
• The FDA issued new final guidance on June 27, 2025, replacing the September 2023 version.
• Manufacturers of “cyber devices” must provide four required elements in any 510(k), PMA, De Novo, PDP, or HDE submission.
• The QMSR (21 CFR Part 820 update) took effect February 2, 2026 — cybersecurity is now embedded in design controls.
• An SBOM in CycloneDX or SPDX format is required for every cyber-device submission.

Section 524B of the FD&C Act: The Statutory Foundation

Section 524B of the FD&C Act took effect on March 29, 2023, establishing statutory cybersecurity requirements for medical devices. Prior to 524B, FDA’s cybersecurity expectations were communicated through guidance documents that were technically non-binding. Section 524B made cybersecurity a legal requirement for premarket submissions — and gave FDA explicit “refuse to accept” (RTA) authority over non-compliant submissions.

What Section 524B Requires

The law applies to “cyber devices” — devices that (1) include software validated, installed, or authorized by the sponsor, (2) have the ability to connect to the internet, and (3) contain any technological characteristics that could be vulnerable to cybersecurity threats. In practice, this covers virtually every connected medical device.

For premarket submissions — 510(k), PMA, De Novo, PDP, HDE, and their supplements — manufacturers must now provide:

1. A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure.
2. A plan for providing reasonable assurance of device cybersecurity, including updates and patches throughout the device’s total product lifecycle.
3. A Software Bill of Materials (SBOM) listing all commercial, open-source, and off-the-shelf software components in the device.
4. Evidence of compliance with other requirements the FDA may establish by regulation.

The FDA can refuse to accept a premarket submission that does not include these elements (the “RTA for cyber devices” policy). This is a significant enforcement mechanism: cybersecurity is no longer a post-approval afterthought but a gate to market access.

Premarket Cybersecurity Documentation

The FDA’s premarket cybersecurity guidance — finalized June 27, 2025 (replacing the September 2023 version) — details what the agency expects in a premarket submission. The June 2025 guidance added new Section VII explicitly mapping the 524B obligations, an enhanced 30-day customer notification requirement for newly discovered vulnerabilities, and tightened SBOM expectations. Key submission elements:

Threat Modeling. Manufacturers must identify and document cybersecurity threats relevant to the device, including threats to confidentiality, integrity, and availability of the device and the data it processes. The threat model should consider the device’s intended use environment, its connectivity interfaces, and the types of data it handles.

Security Architecture. The submission must describe the device’s security architecture, including authentication mechanisms, encryption implementations, network segmentation, and access controls. The architecture should demonstrate defense in depth — multiple layers of security controls so that the compromise of any single control does not result in complete device compromise.

Security Testing. FDA expects evidence of security testing appropriate to the device’s risk level. This includes static and dynamic code analysis, software composition analysis (identifying known vulnerabilities in third-party components), fuzz testing of network interfaces, and penetration testing of the device in its intended deployment configuration.

Cybersecurity Risk Assessment. The submission must include a risk assessment that evaluates cybersecurity risks alongside safety risks, using the risk management framework from ISO 14971. Cybersecurity risks should be traceable to specific threats, vulnerabilities, and mitigations.

Software Bill of Materials (SBOM) Requirements

The SBOM requirement in Section 524B is one of the most operationally significant provisions. An SBOM is a structured list of all software components in a device.

An SBOM must enumerate:

• Commercial software packages (with version numbers).
• Open-source libraries and frameworks (with version numbers and license information).
• Operating system components.
• Firmware and embedded software.

SBOM Format

FDA requires machine-readable SBOM formats — specifically SPDX (Software Package Data Exchange) or CycloneDX, in JSON or XML. These standardized formats enable automated vulnerability tracking: when a new CVE is published for a software component, organizations can quickly determine which devices in their environment contain the affected component.

Why SBOMs Matter for Integration

For healthcare organizations that integrate medical devices with their clinical systems, SBOMs provide critical visibility into the software supply chain. Consider a scenario where a critical vulnerability is discovered in a widely used open-source library like Log4j. With SBOMs for every connected device, your security team can quickly identify which devices are affected, prioritize patching or compensating controls, and communicate risk to clinical stakeholders.

Without SBOMs, the same scenario requires manually contacting every device manufacturer, waiting for their assessment, and hoping they respond promptly. During the Log4Shell crisis in December 2021, many healthcare organizations spent weeks trying to determine which medical devices in their environment were vulnerable. SBOMs eliminate that uncertainty.

SBOM for Integration Components

The SBOM requirement applies to the device itself, but the principle extends to integration infrastructure. If you are running an integration engine (Mirth Connect, OIE, Rhapsody) that processes data from medical devices, maintaining an SBOM for your integration stack enables the same rapid vulnerability assessment. This is not a regulatory requirement for the integration engine, but it is a security best practice that aligns with the spirit of 524B.

Postmarket Cybersecurity Management

Section 524B does not end at market clearance. Manufacturers must maintain cybersecurity throughout the device’s total product lifecycle.

Coordinated Vulnerability Disclosure

Manufacturers must establish and maintain a coordinated vulnerability disclosure (CVD) process. This means:

• Publishing a vulnerability disclosure policy that tells security researchers how to report vulnerabilities.
• Maintaining a dedicated channel for receiving vulnerability reports (typically a security@manufacturer.com email or a web form).
• Acknowledging reports within a defined timeframe.
• Providing a timeline for remediation.
• Publishing advisories when vulnerabilities are confirmed and patches are available.
• Notifying affected customers within 30 days of identifying a vulnerability that requires user action (new in the June 2025 guidance).

For integration teams, this means you should know where to find CVD information for every medical device in your environment. Bookmark the manufacturer’s security advisory page. Subscribe to their notification lists. Include device cybersecurity monitoring in your regular vulnerability management cadence.

Patch and Update Management

Manufacturers must provide security patches and updates in a timely manner. The FDA’s postmarket guidance recommends:

• Critical vulnerabilities: Remediation within a controlled (short) timeframe, with interim mitigations communicated immediately.
• High vulnerabilities: Remediation within the next planned update cycle or sooner.
• Moderate/Low vulnerabilities: Addressed in regular update releases.

Healthcare organizations must have processes to receive, test, and deploy these patches. This is where medical device integration and IT operations intersect: patching a device may require coordination with clinical engineering, biomedical teams, and the integration team to ensure that patches do not break device-to-EHR data flows.

QMSR and Cybersecurity (Effective February 2026)

On February 2, 2026, the FDA’s Quality Management System Regulation (QMSR) replaced the legacy Quality System Regulation (QSR) at 21 CFR Part 820. The QMSR incorporates ISO 13485:2016 by reference and integrates cybersecurity requirements directly into the design controls a manufacturer must follow.

For manufacturers, this matters because cybersecurity is no longer a parallel guidance regime — it’s embedded in the same design controls, CAPA processes, and configuration management procedures that are already audited as part of any quality-system inspection. The June 2025 cybersecurity guidance and the QMSR are explicitly aligned: design inputs include cybersecurity requirements, verification includes security testing, CAPA handles post-market vulnerabilities, and configuration management tracks SBOM contents.

If your team has been maintaining an ISO 13485 QMS, the QMSR transition is mostly mechanical. If you have been running a QSR-only QMS, this is the biggest documentation-system change in two decades and worth engaging external healthcare compliance consulting for the gap analysis.

IEC 62304: Software Lifecycle Standard

IEC 62304 (Medical Device Software — Software Lifecycle Processes) is the international standard for medical device software development. While not specific to cybersecurity, it establishes the software development lifecycle processes that underpin secure device software. For a developer-focused walkthrough, see our IEC 62304 compliance guide.

Software Safety Classification

IEC 62304 classifies software into three safety classes:

The safety classification determines the rigor of development, testing, and documentation requirements. Integration software that processes clinical data from medical devices may itself be classified as a medical device (depending on its intended use), in which case IEC 62304 applies.

Key IEC 62304 Processes

For cybersecurity-relevant processes, IEC 62304 requires:

• Software development planning that addresses security requirements.
• Software architecture design that separates safety-critical and non-safety-critical components (software of unknown provenance, or SOUP, must be identified and risk-assessed).
• Software unit verification including security-focused testing.
• Software integration testing that verifies security controls work correctly when components are combined.
• Software system testing in the intended deployment configuration.
• Problem resolution processes for addressing discovered vulnerabilities.
• Configuration management for all software assets, including third-party components.

IEC 81001-5-1: Health Software Security

IEC 81001-5-1 (Health Software and Health IT Systems Safety, Effectiveness and Security — Part 5-1: Security) is a newer standard that specifically addresses cybersecurity for health software. Published in 2021, it provides a security-focused lifecycle framework that complements IEC 62304.

The FDA added IEC 81001-5-1 to its list of recognized consensus standards in late December 2022. Demonstrating compliance with IEC 81001-5-1 is therefore a direct and well-trodden path to satisfying the security requirements expected in a premarket submission.

Key areas covered by IEC 81001-5-1 include:

• Security requirements analysis during the design phase.
• Secure design principles including least privilege, defense in depth, and fail-secure.
• Secure coding practices with specific attention to common vulnerability classes (injection, authentication bypass, improper input validation).
• Security verification and validation including threat modeling, security testing, and penetration testing.
• Security update management for the full product lifecycle.
• Security event handling including incident response and communication.

For organizations developing medical device software or integration software that may be classified as a medical device, adopting IEC 81001-5-1 provides a structured path to FDA compliance.

Integration Security: Device-to-EHR Data Flows

Medical device cybersecurity does not exist in isolation. Devices connect to clinical systems, and those connections create security considerations that span the device, the network, and the receiving system.

Authentication

Every device-to-system connection should be authenticated. Common patterns include:

• Certificate-based mutual TLS (mTLS): Both the device and the receiving system present certificates to authenticate each other. This is the strongest option for persistent device connections and is required for many DICOM and HL7 MLLP connections in security-conscious environments.
• API key authentication: For RESTful device APIs (increasingly common in IoMT and remote monitoring), API keys provide a simple authentication mechanism. Keys should be unique per device, rotated regularly, and transmitted only over encrypted connections.
• OAuth 2.0: For cloud-connected devices and modern IoMT platforms, OAuth 2.0 provides token-based authentication with scoped access and token expiration. The SMART on FHIR backend services specification is relevant for server-to-server device data flows.

Encryption

All device data in transit must be encrypted. TLS 1.2 is the minimum acceptable version; TLS 1.3 is preferred. For HL7 v2 messages over MLLP, this means configuring MLLP over TLS (sometimes called “secure MLLP” or “HL7 over TLS”). For DICOM, this means DICOM TLS. For FHIR APIs, HTTPS is mandatory. For the application-layer encryption story, see our HIPAA-compliant software development guide.

Data at rest on the integration engine should also be encrypted, particularly the message store (where Mirth Connect or OIE persists messages for retry and audit purposes). These messages often contain PHI extracted from medical devices.

Network Segmentation

Medical devices should reside on segmented network zones, separated from general-purpose IT networks and from each other where appropriate. Integration engines that receive data from medical devices should have network access limited to the specific ports and protocols needed for each device connection.

A common architecture places the integration engine in a DMZ-like position between the medical device network and the clinical systems network:

[Medical Device VLAN] → [Integration Engine] → [EHR/Clinical Systems]

The integration engine acts as a controlled gateway, receiving data from devices on one network interface and forwarding processed data to clinical systems on another. Firewall rules restrict traffic to the specific ports and protocols configured for each integration.

Clinical Alarm Systems

Clinical alarm integration (patient monitors, ventilators, infusion pumps) carries elevated cybersecurity risk because alarm data is time-critical. A cyberattack that delays or suppresses clinical alarms could directly harm patients.

For alarm system integrations, security measures should include:

• Redundant communication paths so that a single network failure does not silence alarms.
• Integrity checking on alarm messages to detect tampering.
• Availability monitoring that detects when alarm data stops flowing and alerts clinical staff through an independent channel.
• Separation from general network traffic to prevent congestion-related alarm delays.

Assessing Your Device Integration Security Posture

If you are responsible for medical device integrations at a healthcare organization, use the following checklist to assess your current security posture against FDA expectations and industry best practices.

Inventory and Documentation

• Do you maintain a complete inventory of connected medical devices, including software versions?
• Do you have SBOMs (or access to manufacturer SBOMs) for connected devices?
• Are device integration interfaces documented, including protocols, ports, authentication methods, and data elements?

Authentication and Encryption

• Are all device-to-system connections authenticated (not just IP-based filtering)?
• Is TLS 1.2 or higher used for all device data in transit (TLS 1.3 preferred)?
• Are certificates managed with a defined lifecycle (issuance, rotation, revocation)?
• Is data at rest encrypted on integration engines and message stores?

Network Security

• Are medical devices on segmented VLANs with firewall rules restricting traffic?
• Does your integration engine sit in a controlled network zone between devices and clinical systems?
• Are unused ports and protocols disabled on both devices and integration engines?

Vulnerability Management

• Are you subscribed to cybersecurity advisories from all device manufacturers in your environment?
• Do you have a process to receive, test, and deploy manufacturer security patches?
• Is your integration engine (Mirth Connect, OIE, etc.) patched and updated on a regular cadence?

Incident Response

• Does your incident response plan specifically address medical device cybersecurity incidents?
• Have you tested your response to a scenario where a device integration is compromised?
• Do you know who to contact at each device manufacturer for cybersecurity incidents?

Frequently Asked Questions

Medical device cybersecurity is not solely the manufacturer’s responsibility. Healthcare organizations that integrate devices with their clinical systems share accountability for the security of those data flows. The FDA’s 524B requirements set the floor for manufacturer obligations; your organization’s integration security practices build on that floor.

For help securing your medical device integrations or assessing your cybersecurity posture, explore our related services:

• Medical Device Integration — End-to-end device-to-EHR integration
• Healthcare Cybersecurity — Security assessment, hardening, and monitoring
• Healthcare Security — Defense-in-depth network architecture for clinical environments
• Healthcare Software Development — IEC 62304 / IEC 81001-5-1 compliant medical software
• Healthcare Compliance Consulting — FDA + HIPAA + QMSR readiness
• HL7 Integration — Secure MLLP-over-TLS for device data flows