Ultimate Guide to FDA Cybersecurity Labeling 2025

Post Summary

What are the FDA's 2025 cybersecurity labeling requirements for medical devices?

The FDA's 2025 cybersecurity labeling requirements are legally enforceable obligations for medical device manufacturers under Section 524B of the FD&C Act that require disclosure of all communication interfaces, a Software Bill of Materials summary with instructions for accessing the full machine-readable SBOM, secure configuration and patching guidelines, disclosure of known unresolved vulnerabilities, and ongoing lifecycle labeling updates as threats and device configurations evolve.

What is a Software Bill of Materials and why does the FDA require it for medical devices?

A Software Bill of Materials is a machine-readable inventory of all third-party software components in a medical device including commercial, open-source, and off-the-shelf tools, required by the FDA under Section 524B in formats including SPDX or CycloneDX aligned with NTIA baseline attributes, enabling healthcare delivery organizations to assess the impact of newly discovered vulnerabilities on deployed devices and track software versions, support levels, end-of-support dates, and known CVEs.

Which medical devices are classified as cyber devices under FDA Section 524B?

Cyber devices are defined under Section 524B as medical devices incorporating software, connecting to the internet or other networks directly or indirectly, and possessing characteristics that make them vulnerable to cybersecurity threats, with the FDA implementing a refuse-to-accept policy for premarket submissions missing required cybersecurity information since October 1, 2023.

What additional FDA labeling requirements apply to AI-enabled medical devices?

AI-enabled medical devices must explicitly state the use of AI and define its role including inputs and outputs, disclose any authorized Predetermined Change Control Plan with update summaries explaining what changed and how to use the device safely, specify intended users and required training, describe the clinical workflow and how AI automation compares to standard care, and maintain an AI Bill of Materials tracking machine learning-specific dependencies.

When must cybersecurity labels be updated during a medical device's lifecycle?

Labeling must be updated upon discovery of new CVEs in third-party software or device code, release of security patches or firmware updates, changes in secure configuration practices, deprecation of older protocols or operating systems, adjustments to end-of-support timelines, and any cybersecurity-impacting modifications such as new communication interfaces, with the FDA guidance indicating updates should occur within 30 days of identifying a security issue.

What are the consequences of non-compliance with FDA cybersecurity labeling requirements?

Devices with outdated or incomplete cybersecurity labeling can be classified as misbranded under FD&C Act sections 502(f) and 502(j), resulting in enforcement actions, delayed market entry, costly recalls, and legal liabilities, with the 2017 FDA recall of 500,000 pacemakers for remotely exploitable vulnerabilities illustrating the patient safety and regulatory consequences of inadequate cybersecurity management.

The FDA's 2025 cybersecurity labeling rules are a game-changer for medical device manufacturers. These regulations require clear, standardized labeling to help healthcare organizations securely use and maintain devices. The focus is on transparency about device communication interfaces, third-party software, and security updates. Compliance is mandatory for devices with software or internet connectivity, with strict requirements like a Software Bill of Materials (SBOM) and clear patching instructions.

Key takeaways:

For AI-enabled devices and "cyber devices", additional rules apply, including managing AI-specific risks and disclosing unresolved vulnerabilities. Manufacturers must also keep labeling updated as threats evolve, ensuring healthcare providers can manage risks effectively. These rules are now legally enforceable and essential for protecting patients and maintaining regulatory compliance.

A Quick Primer on FDA's Final Guidance for Cybersecurity in Medical Devices

sbb-itb-535baee

Core Elements of FDA Cybersecurity Labeling Requirements

The FDA's 2025 guidance zeroes in on the technical aspects of cybersecurity labeling, aiming to help IT and security teams safely integrate and maintain medical devices. With research showing that 88% of healthcare cyberattacks involve an Internet of Medical Things (IoMT) device ^[3], these labeling requirements are a critical defense tool. Let’s break down the key areas manufacturers must address to meet compliance.

Communication Interfaces and Connectivity Transparency

Manufacturers are required to provide a detailed list of all communication pathways a device uses. This includes physical ports (like Ethernet and USB), wireless connections (such as Wi-Fi and Bluetooth), and logical interfaces (like APIs and cloud connections). Even interfaces that are disabled by default or planned for future use must be disclosed, giving healthcare organizations a complete view of the device's potential vulnerabilities.

Technical specifics - like protocols (e.g., TCP/IP, SNMP), necessary ports, and services - should be included to assist IT teams in setting up firewalls and segmenting networks effectively. A recent FBI report revealed that 53% of digital medical devices have exhibited critical vulnerabilities ^[3]. Using quick-reference tables for this information can streamline IT configuration processes.

"A failure to disclose all of the communication interfaces or third-party software could fail to convey potential sources of risks." – FDA Guidance

Software Bill of Materials (SBOM) Compliance

For devices regulated under Section 524B, manufacturers must include a clear summary of third-party software components and provide instructions for accessing the full, machine-readable Software Bill of Materials (SBOM). These SBOMs must follow industry standards like SPDX or CycloneDX, aligning with NTIA baseline attributes ^[4]^[5].

Modern medical devices often incorporate hundreds of third-party software components, with a 2025 audit finding that 64% of open-source components in commercial codebases are transitive dependencies - libraries pulled in automatically by other libraries ^[4]. The labeling must detail software versions, support levels, end-of-support dates, and known vulnerabilities (CVEs). This enables healthcare providers to quickly assess the impact of newly discovered vulnerabilities on their deployed devices. Starting October 1, 2025, the FDA will reject submissions that lack the required SBOM data ^[4].

Secure Configuration and Patching Guidelines

In addition to listing components, manufacturers must provide clear guidelines for securely configuring and maintaining devices. This includes deployment steps like setting up authentication (passwords, multi-factor authentication), role-based access control, and network configurations.

Patching instructions need to cover how updates are delivered (over-the-air or local), how to verify updates (e.g., digital signatures), expected downtime, and rollback procedures in case of issues. If any vulnerabilities cannot be fully mitigated, manufacturers must identify them and suggest practical compensating controls, such as enhanced monitoring or access restrictions, to manage risks. This level of transparency allows healthcare organizations to make informed decisions about device security and third-party risk management.

"Labeling that does not include sufficient information to explain how to securely configure or update the device may limit the ability of end users to appropriately manage and protect the medical device system." – FDA Guidance

Lifecycle Management and Ongoing Labeling Updates

Keeping device labeling up to date is a critical part of managing cybersecurity risks throughout a device's lifecycle. Unlike static manuals of the past, cybersecurity labeling must adapt to evolving threats, updates, and changes in devices. Manufacturers are shifting toward event-driven updates, supported by regular reviews, typically every quarter or six months ^[3]. Let’s break down the key triggers for updates, the responsibilities manufacturers bear, and the risks associated with outdated labeling.

When Labeling Needs an Update

Several events can trigger the need for labeling updates during a device's lifecycle. These include:

In short, any significant change that affects a device's security posture requires an update to its labeling.

Manufacturer Responsibilities

As of March 29, 2023, manufacturers are legally required to maintain accurate cybersecurity labeling under Section 524B of the FD&C Act ^[2]. This moves labeling from a "nice-to-have" recommendation to a legally enforceable obligation. Compliance must align with the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 standards ^[6].

Key responsibilities include:

This proactive approach ensures labeling remains a reliable source of information, helping users address real risks while avoiding unnecessary confusion.

Risks of Falling Behind on Labeling

Outdated labeling isn’t just a regulatory issue - it poses serious risks to patient safety. If healthcare IT teams rely on inaccurate labeling, they might deploy devices with insecure configurations or miss critical patches, leaving systems vulnerable. A stark example is the 2017 FDA recall of 500,000 pacemakers. Researchers exposed vulnerabilities that allowed attackers to remotely drain batteries or alter heartbeats, forcing in-person firmware updates ^[3].

From a regulatory perspective, outdated labeling can result in a device being deemed "misbranded" or even classified as "dangerous to health" ^[3]. This can lead to delayed market entry, costly recalls, and legal liabilities. For manufacturers, staying on top of labeling updates isn’t just about compliance - it’s a business necessity to avoid these costly pitfalls and protect both users and their reputation.

Additional Requirements for AI-Enabled and Cyber Devices

Building on the core elements of cybersecurity labeling, this section dives into the extra requirements for AI-enabled devices and those classified as cyber devices. These technologies come with unique risks, and as of 2025, the FDA has authorized over 1,000 AI-enabled medical devices. The regulatory framework has been adjusted to address these challenges, making it critical for manufacturers to understand the evolving compliance landscape ^[8]^[9].

AI and Machine Learning Security Documentation

For medical devices utilizing AI or machine learning, the labeling must explicitly state the use of AI and clearly define its role, including the inputs it processes and the outputs it generates ^[11]. Devices with an authorized Predetermined Change Control Plan (PCCP) introduce additional complexity. A PCCP allows manufacturers to implement pre-approved AI model updates without needing a new marketing application, but it also requires transparency. Users must be informed about the PCCP, and manufacturers are obligated to provide update summaries that outline the changes made, evidence supporting those changes, and updated usage instructions ^[8].

"Labeling should inform users the device has an authorized PCCP and, as updates are implemented, explain what changed and how to use the device safely." - Charley F. Brown and Gregory Szewczyk, Partners, Ballard Spahr

Labeling must also specify the intended users, their required training, the clinical workflow, and how the AI's automation compares to standard care practices ^[11]. These requirements are further emphasized for devices classified under Section 524B.

Cyber Devices Under Section 524B

Under Section 524B of the FD&C Act, "cyber devices" are defined as those incorporating software, connecting to the internet or other networks (directly or indirectly), and possessing characteristics that make them vulnerable to cybersecurity threats ^[13]^[14]. These devices must include a postmarket vulnerability management plan, cybersecurity assurance processes, and a complete Software Bill of Materials (SBOM) ^[13].

For AI-enabled devices, the SBOM expands into an AI Bill of Materials (AIBOM), which tracks machine learning-specific dependencies. The AIBOM must cover all software components, including commercial, open-source, and off-the-shelf tools ^[9]^[12]. Manufacturers are required to provide a summary of third-party components within the labeling and clear instructions for authorized users to access the full SBOM ^[3].

Additionally, cyber devices must disclose any known but unresolved vulnerabilities. This includes identifying specific Common Vulnerabilities and Exposures (CVEs) that remain unpatched, explaining their potential safety impact, and detailing mitigation plans ^[12]. Vulnerability Exploitability eXchange (VEX) documents help clarify which SBOM-listed vulnerabilities are exploitable, simplifying audits for hospital IT teams ^[12].

"AI-enabled medical devices present additional risks that must be considered, ranging from supply chain poisoning to susceptibility to adversarial manipulations." - Firefinch

Since October 1, 2023, the FDA has implemented a "refuse-to-accept" policy for premarket submissions missing the required cybersecurity information under Section 524B ^[3]^[13]. This marks a new level of regulatory scrutiny for cyber devices, signaling the growing importance of robust cybersecurity measures.

How to Implement FDA Cybersecurity Labeling

Meeting the FDA's 2025 cybersecurity labeling requirements involves aligning documentation, risk management, and operational practices. Manufacturers and healthcare delivery organizations (HDOs) must ensure cybersecurity transparency is embedded into their quality systems and device lifecycle management.

Compliance Checklist

To meet the requirements, follow this checklist to align your device documentation (like IFUs, manuals, and bulletins) with the FDA's June 2025 labeling expectations. Your labeling must clearly outline security controls in simple terms, covering areas such as authentication, access control, encryption, logging, malware protection, and configuration dependencies ^[16]^[10]^[6].

Additionally, include the security support lifetime - for instance, "security updates provided through December 31, 2031" - to help U.S. hospitals plan budgets and replacement cycles ^[15]. Provide configuration guidance with secure default settings and network requirements ^[10]^[17]. Finally, establish vulnerability reporting channels, such as a dedicated security email or web portal, in line with your coordinated vulnerability disclosure policy ^[15]^[12]^[10].

Integrating Labeling Into Risk Management Practices

Cybersecurity labeling must be closely tied to your risk management system. Labeling should trace back to the risk management file under ISO 14971 and ISO 13485. Design controls should map the journey from identified risks to implemented security measures and then to labeling instructions, ensuring HDOs understand how to operate the device securely ^[10]^[6].

For example, when new authentication features are added by your engineering team, update the labeling and IFU content immediately to prevent confusion for users and auditors ^[10]^[6]. Use postmarket processes like vulnerability monitoring and incident response to prompt labeling updates when new high-impact vulnerabilities emerge. These updates might include temporary workarounds or secure configuration recommendations, ensuring that operational controls - such as "requires firewall rules" or "requires regular log review" - are clearly communicated ^[12]^[6].

Using Censinet for Streamlined Compliance

A centralized platform can simplify these processes. Censinet RiskOps™ acts as a hub for managing FDA cybersecurity labeling compliance while transforming healthcare third-party risk management. HDOs can use the platform to incorporate SBOM data, connectivity details, support lifetimes, and configuration guidance directly into vendor risk assessments and device onboarding workflows.

As security support lifetimes approach expiration, RiskOps™ helps HDOs plan budgets in U.S. dollars for device replacement or extended support ^[15]. For vendors, Censinet RiskOps™ ensures security controls are traced throughout the device lifecycle, aligning with FDA quality system expectations. This reduces the risk of underspecified support lifetimes or misaligned security documentation - issues that can confuse both users and auditors ^[15]^[10]^[6]. By consolidating labeling data into real-time dashboards, the platform connects FDA compliance with medical device security programs and regulatory reporting, making it easier to meet both operational and regulatory demands.

Conclusion and Key Takeaways

The FDA's 2025 cybersecurity labeling requirements represent a significant shift in how medical device security is managed, with the ultimate goal of protecting patient safety. In an era of increasing cyber threats, these labeling standards are not just a formality - they are essential for safeguarding patients.

Summary of Core Elements

Effective cybersecurity labeling must address key security measures to counter evolving threats. This includes:

Additionally, manufacturers need to provide clear patch management procedures, outlining delivery methods, steps to verify update integrity, and rollback processes in case an update fails ^[3]^[1].

Labeling must also adapt to new vulnerabilities and configuration changes over time. Failing to meet these requirements could result in a device being classified as misbranded under the FD&C Act (§502(f) and §502(j)), leading to enforcement actions and heightened liability risks ^[3]^[1].

The Role of Risk Management in Cybersecurity Labeling

Cybersecurity labeling should be closely tied to a manufacturer’s risk management practices. Each security measure outlined in the labeling must directly address risks identified in the risk management file. This alignment ensures that labeling instructions are not just compliance-driven but also enhance device safety.

For healthcare delivery organizations, this means having the information needed to operate devices securely and apply compensating controls, like network segmentation, to manage residual risks. A strong connection between risk management and labeling is essential for building a reliable compliance framework ahead of 2025 ^[3].

Preparing for 2025 Compliance

To meet the upcoming requirements, manufacturers should focus on providing:

It’s also critical to disclose any remaining risks and establish patching workflows that minimize operational disruptions.

Tools like Censinet RiskOps™ can streamline compliance efforts by integrating SBOM data, connectivity details, support timelines, and configuration guidance into risk assessments and device onboarding processes. By taking proactive steps now, manufacturers and healthcare organizations can ensure that their cybersecurity strategies prioritize patient safety. Aligning labeling practices with robust risk management will help navigate the challenges of an ever-changing cybersecurity landscape effectively.

FAQs

Does my device fall under FDA Section 524B?

If your device is classified as a medical device and includes features like internet connectivity, updatable software, or network access, it may fall under FDA Section 524B. This section focuses on ensuring a reasonable assurance of cybersecurity for such devices.

To comply, manufacturers must address key requirements, including:

If your device involves software or connectivity that could impact cybersecurity, it's essential to confirm whether these regulations apply to you.

What should an SBOM include for FDA labeling in 2025?

An SBOM required for FDA labeling in 2025 must contain a machine-readable list of software components. This list should follow the NTIA’s Framing Software Component Transparency guidelines and include key lifecycle details like version, origin, and end-of-support date. These details play a crucial role in enhancing transparency and aiding risk management efforts in premarket submissions.

How often do cybersecurity labels need updating?

Cybersecurity labels need to be refreshed regularly throughout a device's lifecycle. According to the FDA’s 2025 guidance, this involves continuous threat monitoring, implementing updates based on risk, and promptly disclosing vulnerabilities. For instance, labels should be updated within 30 days of identifying a security issue. These regular updates help ensure devices stay secure and meet ever-changing cybersecurity requirements.

Key Points:

What are the FDA's 2025 cybersecurity labeling requirements and why are they legally enforceable?

FDA cybersecurity labeling requirements became legally enforceable as of March 29, 2023 under Section 524B of the FD&C Act, moving cybersecurity labeling from a recommended best practice to a mandatory compliance obligation with enforcement consequences for non-compliant devices
The refuse-to-accept policy implemented October 1, 2023 and extended to SBOM data starting October 1, 2025 means FDA will reject premarket submissions that lack required cybersecurity information, making labeling compliance a market access prerequisite rather than a post-market obligation
Research shows that 88% of healthcare cyberattacks involve an Internet of Medical Things device, and 53% of digital medical devices have exhibited critical vulnerabilities, establishing the patient safety justification for mandatory labeling requirements that give healthcare delivery organizations the information needed to assess and manage device risks
Compliance must align with the Quality Management System Regulation incorporating ISO 13485:2016 standards, meaning cybersecurity labeling is embedded in the device's quality management system rather than treated as a standalone documentation exercise
Devices with non-compliant labeling can be classified as misbranded under FD&C Act sections 502(f) and 502(j), resulting in enforcement actions, market withdrawal, and legal liability that far exceeds the cost of labeling compliance
The 2017 FDA recall of 500,000 pacemakers for vulnerabilities allowing remote battery drainage or heartbeat alteration illustrates the patient safety consequence of inadequate cybersecurity management and the regulatory consequences of failing to address known vulnerabilities transparently

What communication interface and connectivity disclosure is required under FDA cybersecurity labeling?

Manufacturers must provide a detailed list of all communication pathways including physical ports such as Ethernet and USB, wireless connections including Wi-Fi and Bluetooth, and logical interfaces including APIs and cloud connections, with disclosure required even for interfaces that are disabled by default or planned for future use
Technical specifications must include protocols such as TCP/IP and SNMP, necessary ports, and services to give healthcare IT teams the information required to configure firewalls, segment networks, and assess the attack surface the device introduces to the clinical environment
Quick-reference tables for interface and connectivity information streamline IT configuration processes and reduce the likelihood that healthcare delivery organizations deploy devices with insecure default network configurations that create exploitable exposure
The FDA guidance explicitly warns that failure to disclose all communication interfaces or third-party software could fail to convey potential sources of risks, making completeness of disclosure a specific regulatory standard rather than a general documentation expectation
All interfaces must be disclosed regardless of whether they are currently active, because disabled interfaces represent potential future attack vectors if re-enabled during device maintenance or configuration changes by healthcare IT staff who may not be aware of the security implications
Healthcare delivery organizations can use Censinet RiskOps to incorporate connectivity details from FDA labeling directly into vendor risk assessments and device onboarding workflows, ensuring that interface disclosures translate into actionable network segmentation and monitoring requirements

What are the SBOM requirements under FDA cybersecurity labeling and what must they include?

SBOMs must follow industry standards including SPDX or CycloneDX aligned with NTIA baseline attributes, providing machine-readable component inventories that healthcare delivery organizations and their security tools can process to assess vulnerability exposure across deployed device populations
Labeling must include a clear summary of third-party software components with instructions for authorized users to access the full SBOM, rather than embedding the complete SBOM in labeling documents that are not designed for machine processing
Component records must detail software versions, support levels, end-of-support dates, and known vulnerabilities expressed as CVEs, enabling healthcare organizations to quickly assess the impact of newly discovered vulnerabilities without waiting for manufacturer communication
64% of open-source components in commercial codebases are transitive dependencies automatically pulled in by other libraries, making comprehensive SBOM documentation essential for tracking vulnerabilities in components that manufacturers may not have explicitly chosen to include but bear responsibility for managing
Starting October 1, 2025, the FDA will reject submissions that lack required SBOM data, creating a hard deadline for manufacturers to implement SBOM generation and maintenance processes that meet the FDA's format and content requirements
For AI-enabled devices, the SBOM expands into an AI Bill of Materials tracking machine learning-specific dependencies including all software components covering commercial, open-source, and off-the-shelf tools used in AI model development and deployment

What secure configuration and patching guidelines must be included in FDA cybersecurity labeling?

Deployment steps for secure configuration must cover authentication setup including passwords and MFA, role-based access control implementation, and network configuration requirements that allow healthcare delivery organizations to deploy devices in a security-hardened state rather than relying on insecure defaults
Patching instructions must specify delivery method including over-the-air or local, update verification procedures such as digital signature validation, expected downtime, and rollback procedures for cases where updates cause unexpected device behavior in clinical environments
Unresolved vulnerabilities that cannot be fully mitigated must be identified with specific CVE identifiers, their potential safety impact, and practical compensating controls such as enhanced monitoring or access restrictions that healthcare organizations can implement while patches are developed
Vulnerability Exploitability eXchange documents help clarify which SBOM-listed vulnerabilities are actually exploitable in the device's specific configuration, simplifying the audit process for hospital IT teams who would otherwise need to assess every CVE in a device's SBOM regardless of actual exploitability
Labeling that does not include sufficient information to explain secure configuration or update procedures limits end users ability to manage and protect the medical device system', as stated in FDA guidance, making instruction completeness a specific regulatory standard
Manufacturers must update VEX documents when new CVEs are discovered to ensure healthcare providers are not pursuing remediation for vulnerabilities that are not actually exploitable in their deployed devices, reducing unnecessary security overhead while focusing attention on real risks

What additional requirements apply to AI-enabled medical devices under FDA cybersecurity labeling?

AI-enabled devices must explicitly state the use of AI and clearly define its role including the inputs it processes and the outputs it generates, providing healthcare clinicians and administrators with the transparency needed to understand how AI is influencing clinical workflows and decisions
Devices with an authorized Predetermined Change Control Plan must inform users of the PCCP and provide update summaries each time AI model updates are implemented, explaining what changed, what evidence supports the changes, and how to use the updated device safely
AI-specific risks including supply chain poisoning and susceptibility to adversarial manipulation must be considered in cybersecurity risk management, extending the scope of traditional device cybersecurity to the machine learning components and training data pipelines that define AI device behavior
Labeling must specify intended users and their required training, the clinical workflow, and how AI automation compares to standard care practices, ensuring that healthcare organizations deploying AI-enabled devices understand the appropriate clinical context and supervision requirements
The AI Bill of Materials tracks machine learning-specific dependencies including all software components used in AI model development and deployment, providing the transparency needed to assess vulnerabilities in the AI components of devices that may have distinct security characteristics from traditional device software
As of 2025 the FDA has authorized over 1,000 AI-enabled medical devices, making AI-specific labeling requirements an immediate compliance concern for a substantial and growing portion of the medical device market rather than a future-oriented regulatory consideration

How should healthcare delivery organizations use FDA cybersecurity labeling in device risk management?

FDA cybersecurity labeling data should be incorporated directly into vendor risk assessments and device onboarding workflows, translating SBOM component lists, connectivity disclosures, and support lifetime information into actionable security controls rather than treating labeling as a passive reference document
Security support lifetime information enables healthcare organizations to plan device replacement or extended support budgets aligned with the date through which security updates will be provided, preventing organizations from operating devices with known vulnerabilities after manufacturer support ends
SBOM data enables healthcare IT teams to assess exposure to newly discovered vulnerabilities across all deployed devices without waiting for manufacturer communication, because the component inventory provides the mapping between CVE disclosures and specific device deployments
VEX documents should be incorporated into vulnerability management workflows to focus remediation effort on exploitable vulnerabilities in specific device configurations rather than pursuing remediation for every CVE in an SBOM regardless of actual exploitability
Network segmentation and firewall configuration requirements derived from interface disclosure tables should be implemented as device deployment prerequisites, ensuring that newly onboarded devices enter the clinical network with appropriate isolation rather than requiring retroactive reconfiguration
Censinet RiskOps centralizes SBOM data, connectivity details, support lifetimes, and configuration guidance from FDA labeling into real-time dashboards that connect FDA compliance requirements with medical device security programs, enabling healthcare delivery organizations to manage device risk at scale across large device portfolios

How can we assist?