Section VII \u2013 Cyber Devices – new chapter describing FD&C Act 524B<\/strong><\/strong><\/h2>\n\n\n\nThis is the most significant and extensive change. The 2023 version of guidance introduced FD&C Act 524B as being covered under its scope. Current guidance continued that path by devoting a completely new section VII, “Cyber Devices,” <\/strong>to describe it.It contains structured compliance documentation steps for each part of 524B. Below is an overview of what it says.<\/p>\n\n\n\nClarifying the “cyber device” definition<\/strong><\/strong><\/h3>\n\n\n\nThe guidance outlines that devices regulated under 524B now have their own definition and scope. The term “cyber device” has become a legally binding designation used by the FDA to define which medical devices are subject to enhanced cybersecurity requirements.<\/p>\n\n\n\n
So, anyone submitting a premarket application (510(k), PMA, PDP, De Novo, or HDE) for a “cyber device”<\/strong> must include the cybersecurity information required by the FDA. There was no formal definition before, so it should dispel doubts about whether a given manufacturer’s device is subject to these rules.<\/p>\n\n\n\n![\"Cyber](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/08\/Przechwytywanie.jpg\")
Fig. 1 “Cyber device”<\/figcaption><\/figure>\n\n\n\nPicking apart requirements for cyber devices<\/strong><\/strong><\/h3>\n\n\n\nBased on FDA requirements on Cybersecurity Documentation for Premarket Submissions, since March 29, 2023, the FDA may reject any submission for a cyber device if it does not include complete cybersecurity data.<\/strong><\/p>\n\n\n\nThe required data includes, in a nutshell:<\/p>\n\n\n\n
\n- Plans and Procedures <\/strong>on post-market vulnerability management – <\/strong>including vulnerability monitoring, response, and disclosure procedures.<\/li>\n\n\n\n
- Design, Development, and Maintenance Processes and Procedures<\/strong> on control of security updates and patches,including post-market surveillance.<\/li>\n\n\n\n
- SBOM <\/strong>\u2013Software Bill of Materials – a detailed software inventory.<\/li>\n\n\n\n
- Compliance with other FDA-regulated<\/strong> requirements.<\/li>\n<\/ol>\n\n\n\n
The FD&C Act 524B requirements are broadly worded, leaving a large space for interpretation, which often results in confusion and uncertainty.<\/p>\n\n\n\n
The newly issued guidance aims to bridge these gaps by offering a clear, structured approach to the specific documentation expected in premarket submissions<\/strong> for a cyber device. Key recommendations include:<\/p>\n\n\n\n\n- Plans and Procedures:<\/strong><\/strong>\n
\n- for disclosure procedures:\n
\n- to provide a plan based on the Cybersecurity Management Plan described in section VI.B of the guidance,<\/li>\n\n\n\n
- to include both internal and external\/third party (e.g., researchers, suppliers) sources for disclosures of the vulnerabilities and exploits, when applying disclosure procedures, like Coordinated Vulnerability Disclosure (CVD),<\/li>\n\n\n\n
- to take responsibility for disclosure procedures as a manufacturer.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for updates and patches \u2013 to adapt the release schedule to the type of vulnerability:\n
\n- regular schedule of release for “known unacceptable vulnerability”, which can be “a vulnerability that could not cause uncontrolled risks; a vulnerability that is not currently known to cause uncontrolled risks; or a vulnerability that could present controlled risk”,<\/li>\n\n\n\n
- as soon as possible, release for “critical vulnerabilities with uncontrolled risk”. Examples of these types of vulnerabilities can be found in Postmarket Security Guidance \u2013 “Postmarket Management of Cybersecurity in Medical Devices, 2016”.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for arising risks, threats, vulnerabilities, and other adverse factors:\n
\n- to keep up-to-date documentation throughout the total product lifecycle (TPLC),<\/li>\n\n\n\n
- to tailor actions to different risk profiles, i.e., actively marketed and older, still-used devices, to ensure an accurate assessment of patient risk for each available device version.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Design, Development, and Maintenance Processes and Procedures<\/strong><\/strong>: guidance underlines that:\n
\n- providing and maintaining required cybersecurity processes affects not only the device itself, but also its related systems<\/strong>, like servers for software\/firmware updates or healthcare network connections. That means it is essential to assess cybersecurity risks and apply proper security controls across all related systems, documenting everything as outlined in FDA guidance to demonstrate compliance.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- SBOM<\/strong>: the required SBOMs are recommended to contain supporting documentation described in detail in the guidance (section V.A.4.b).<\/li>\n<\/ol>\n\n\n\n
Submitting device modifications \u2013 what is required?<\/strong><\/strong><\/h3>\n\n\n\nCompliance with FD&C Act \u00a7524B also applies when submitting device modifications under the already mentioned FDA pathways. In that case, the required cybersecurity information depends on the type of change and its impact. Guidance explains what exactly is required for each case:<\/p>\n\n\n\n
\n- If the change may affect cybersecurity, full cybersecurity documentation described in section VII.C is required.<\/li>\n\n\n\n
- If the change is unlikely to impact cybersecurity, manufacturers still need to:\n
\n- submit or reference a cybersecurity plan,<\/li>\n\n\n\n
- state whether critical vulnerabilities exist or were fixed,<\/li>\n\n\n\n
- provide an up-to-date SBOM (Software Bill of Materials).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Cybersecurity as a determinant of FDA approval<\/strong><\/strong><\/h3>\n\n\n\nAs devices become more interconnected, ensuring cybersecurity is now essential to protect public health. Guidance states that FDA treats “Reasonable assurance of cybersecurity”<\/strong> as a key component in ensuring a medical device’s safety and effectiveness<\/strong>. According to the 2022 FDORA law, the new cybersecurity rules (Section 524B) do not<\/strong> limit the FDA’s power to review cybersecurity when evaluating a medical device. This means that cybersecurity can directly influence the FDA’s approval decisions for devices submitted under the <\/strong>aforementioned pathways.<\/p>\n\n\n\nIn 510(k) reviews, the FDA considers how new risks or technological changes (e.g., added connectivity) affect cybersecurity and whether the device has proper protection. The FDA may request additional data if the device lacks protection against known threats (e.g., a nursing station alarm system without proper encryption). If it’s inadequate, the FDA may declare the device not substantially equivalent (NSE)<\/strong> to its predicate due to potential safety risks.<\/p>\n\n\n\nAdding “Controlled Risk” definition<\/strong><\/h2>\n\n\n\nNew guidance has been enriched with a ‘Controlled Risk’ definition.<\/p>\n\n\n\n![\"controlled](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/08\/2.jpg\")
Fig. 2 Controlled risk<\/figcaption><\/figure>\n\n\n\nIt has been used to describe the type of vulnerability “that could present controlled risk” (types of vulnerabilities have already been addressed in the previous chapter).<\/p>\n\n\n\n
Updates in references<\/strong><\/strong><\/h2>\n\n\n\nGuidance adds the following references:<\/p>\n\n\n\n
\n- Section 3305 of FDORA<\/strong> (Food and Drug Omnibus Reform Act of 2022<\/em>) as an act implementing the already mentioned section 524B to the FD&C Act.<\/li>\n\n\n\n
- ANSI\/AAMI SW96:2023<\/strong>, Standard for medical device security – Security risk management for device manufacturers<\/em>, recently identified by FDA as a recognized consensus standard – it has been referred to as AAMI TIR 57, as an industry standard that aids in managing cybersecurity risks<\/strong> of the device, including:\n
\n- providing information on how to manage safety and security processes interaction to ensure that all risks are adequately assessed -ensuring that risk control measures for one type of risk assessment do not inadvertently introduce new risks in the other (Section V.A of guidance),<\/li>\n\n\n\n
- providing requirements and expectations for the Risk Management Plan and Report,<\/li>\n\n\n\n
- performing authorization checks based on benefit\/risk assessment,<\/li>\n\n\n\n
- determining if reacting to a security event is worth it, and how to do it safely when implementing event detection and logging.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- 21 CFR Part 806<\/strong> \u2013 it provides rules on handling and reporting corrections and removals of a device in case of post-market emerging vulnerabilities. Together with 21 CFR 820.100, it is referred as a supporting mechanism on establishing Cybersecurity Management Plans.<\/li>\n<\/ul>\n\n\n\n
Updates also include changes in already existing references:<\/p>\n\n\n\n
\n- Quality System (QS) Regulation<\/strong> 21 CFR Part 820(g) <\/strong>\u2013 the new guidance informs about the final rule taking effect on February 2, 2026, addressing risk management activities under QS Regulation. The rule is to be similar to the requirements of the Quality Management System of ISO 13485. The 2023 version of the risk management concept was based on a rule that was not yet in force.<\/li>\n\n\n\n
- JSP2<\/strong> \u2013 the new guidance updates the reference to the “Medical Device and Health IT Joint Security Plan (JSP) to its new version – JSP2. Although not-binding, the JSP is a FDA-recognized roadmap for building cybersecurity into medical devices. It is identified as a possible Secure Product Development Framework (SPDF) to meet FDA requirements and expectations.<\/li>\n<\/ul>\n\n\n\n
What is new in JSP2?<\/strong> Generally speaking, the main change is that JSP2 is now directly aligned with goals #6 and #7 from the 2024 Health Industry Cybersecurity Strategic Plan (HIC-SP):<\/p>\n\n\n\n\n- Goal 6<\/strong> promotes secure-by-design<\/em> and secure-by-default<\/em> approaches to technologies that aim to reduce the cybersecurity burden on end users.<\/li>\n\n\n\n
- Goal 7<\/strong> fosters a trusted healthcare ecosystem by collaborating with technology partners, suppliers, and service providers to strengthen long-term cybersecurity readiness.<\/li>\n<\/ul>\n\n\n\n
The updated 2025 FDA guidance on cybersecurity no longer directly refers to:<\/p>\n\n\n\n
\n- Machine Learning (ML)-based devices<\/strong>, but it doesn’t mean ML-based devices are not within its scope. FDA still recalls devices that “include artificial intelligence (AI) and cloud-based services”. Without a specific focus on ML, the FDA seems to emphasize that cybersecurity expectations apply based on risk and connectivity, <\/strong>not just the use of specific technologies like ML. <\/li>\n\n\n\n
- OTS-specific guidance on cybersecurity for MD <\/strong>(“Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” \u2013 taking new 2022 FDORA law and section 524B into account, the older OTS-specific guidance predates these rules and no longer reflects the FDA’s updated legal framework. The 2025 guidance seems to consolidate FDA cybersecurity expectations and absorb OTS software into its broadened scope.<\/li>\n\n\n\n
- NIST Suite B<\/strong> \u2013 as guidance aligns with current NIST recommended standards for cryptography, it removes already outdated NIST Suite B from the list.<\/li>\n<\/ul>\n\n\n\n
![\"job](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2025\/08\/praca-EN-k.jpg\")
<\/a><\/figure>\n\n\n\nSummary<\/strong><\/h2>\n\n\n\nThe 2025 guidance<\/strong> builds upon the 2023 version by fully incorporating the legally binding requirements of Section 524B of the FD&C Act<\/strong>. While the 2023 edition introduced these requirements, the 2025 version explains required documentation for cyber devices in detail.<\/p>\n\n\n\nA key feature is new Section VII<\/strong>, which clearly outlines the documentation FDA expects in premarket submissions, helping manufacturers align with approval expectations.<\/p>\n\n\n\nThe 2025 update reinforces that cybersecurity is a core element of device safety and effectiveness<\/strong>, not just a technical add-on. It underscores cybersecurity as a total product lifecycle (TPLC)<\/strong> responsibility, emphasizing the need for Secure Product Development Framework (SPDF) integration, proactive risk management and threat modeling, timely identification and disclosure of vulnerabilities, and well-structured, comprehensive documentation.<\/p>\n\n\n\nOverall, the 2025 guidance provides clearer expectations and stronger alignment with regulatory requirements compared to its 2023 predecessor, raising the bar for how cybersecurity is addressed in both premarket and postmarket phases.<\/p>\n\n\n
Clarifying the “cyber device” definition<\/strong><\/strong><\/h3>\n\n\n\nThe guidance outlines that devices regulated under 524B now have their own definition and scope. The term “cyber device” has become a legally binding designation used by the FDA to define which medical devices are subject to enhanced cybersecurity requirements.<\/p>\n\n\n\n
So, anyone submitting a premarket application (510(k), PMA, PDP, De Novo, or HDE) for a “cyber device”<\/strong> must include the cybersecurity information required by the FDA. There was no formal definition before, so it should dispel doubts about whether a given manufacturer’s device is subject to these rules.<\/p>\n\n\n\nFig. 1 “Cyber device”<\/figcaption><\/figure>\n\n\n\nPicking apart requirements for cyber devices<\/strong><\/strong><\/h3>\n\n\n\nBased on FDA requirements on Cybersecurity Documentation for Premarket Submissions, since March 29, 2023, the FDA may reject any submission for a cyber device if it does not include complete cybersecurity data.<\/strong><\/p>\n\n\n\nThe required data includes, in a nutshell:<\/p>\n\n\n\n
\n- Plans and Procedures <\/strong>on post-market vulnerability management – <\/strong>including vulnerability monitoring, response, and disclosure procedures.<\/li>\n\n\n\n
- Design, Development, and Maintenance Processes and Procedures<\/strong> on control of security updates and patches,including post-market surveillance.<\/li>\n\n\n\n
- SBOM <\/strong>\u2013Software Bill of Materials – a detailed software inventory.<\/li>\n\n\n\n
- Compliance with other FDA-regulated<\/strong> requirements.<\/li>\n<\/ol>\n\n\n\n
The FD&C Act 524B requirements are broadly worded, leaving a large space for interpretation, which often results in confusion and uncertainty.<\/p>\n\n\n\n
The newly issued guidance aims to bridge these gaps by offering a clear, structured approach to the specific documentation expected in premarket submissions<\/strong> for a cyber device. Key recommendations include:<\/p>\n\n\n\n\n- Plans and Procedures:<\/strong><\/strong>\n
\n- for disclosure procedures:\n
\n- to provide a plan based on the Cybersecurity Management Plan described in section VI.B of the guidance,<\/li>\n\n\n\n
- to include both internal and external\/third party (e.g., researchers, suppliers) sources for disclosures of the vulnerabilities and exploits, when applying disclosure procedures, like Coordinated Vulnerability Disclosure (CVD),<\/li>\n\n\n\n
- to take responsibility for disclosure procedures as a manufacturer.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for updates and patches \u2013 to adapt the release schedule to the type of vulnerability:\n
\n- regular schedule of release for “known unacceptable vulnerability”, which can be “a vulnerability that could not cause uncontrolled risks; a vulnerability that is not currently known to cause uncontrolled risks; or a vulnerability that could present controlled risk”,<\/li>\n\n\n\n
- as soon as possible, release for “critical vulnerabilities with uncontrolled risk”. Examples of these types of vulnerabilities can be found in Postmarket Security Guidance \u2013 “Postmarket Management of Cybersecurity in Medical Devices, 2016”.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for arising risks, threats, vulnerabilities, and other adverse factors:\n
\n- to keep up-to-date documentation throughout the total product lifecycle (TPLC),<\/li>\n\n\n\n
- to tailor actions to different risk profiles, i.e., actively marketed and older, still-used devices, to ensure an accurate assessment of patient risk for each available device version.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Design, Development, and Maintenance Processes and Procedures<\/strong><\/strong>: guidance underlines that:\n
\n- providing and maintaining required cybersecurity processes affects not only the device itself, but also its related systems<\/strong>, like servers for software\/firmware updates or healthcare network connections. That means it is essential to assess cybersecurity risks and apply proper security controls across all related systems, documenting everything as outlined in FDA guidance to demonstrate compliance.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- SBOM<\/strong>: the required SBOMs are recommended to contain supporting documentation described in detail in the guidance (section V.A.4.b).<\/li>\n<\/ol>\n\n\n\n
Submitting device modifications \u2013 what is required?<\/strong><\/strong><\/h3>\n\n\n\nCompliance with FD&C Act \u00a7524B also applies when submitting device modifications under the already mentioned FDA pathways. In that case, the required cybersecurity information depends on the type of change and its impact. Guidance explains what exactly is required for each case:<\/p>\n\n\n\n
\n- If the change may affect cybersecurity, full cybersecurity documentation described in section VII.C is required.<\/li>\n\n\n\n
- If the change is unlikely to impact cybersecurity, manufacturers still need to:\n
\n- submit or reference a cybersecurity plan,<\/li>\n\n\n\n
- state whether critical vulnerabilities exist or were fixed,<\/li>\n\n\n\n
- provide an up-to-date SBOM (Software Bill of Materials).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Cybersecurity as a determinant of FDA approval<\/strong><\/strong><\/h3>\n\n\n\nAs devices become more interconnected, ensuring cybersecurity is now essential to protect public health. Guidance states that FDA treats “Reasonable assurance of cybersecurity”<\/strong> as a key component in ensuring a medical device’s safety and effectiveness<\/strong>. According to the 2022 FDORA law, the new cybersecurity rules (Section 524B) do not<\/strong> limit the FDA’s power to review cybersecurity when evaluating a medical device. This means that cybersecurity can directly influence the FDA’s approval decisions for devices submitted under the <\/strong>aforementioned pathways.<\/p>\n\n\n\nIn 510(k) reviews, the FDA considers how new risks or technological changes (e.g., added connectivity) affect cybersecurity and whether the device has proper protection. The FDA may request additional data if the device lacks protection against known threats (e.g., a nursing station alarm system without proper encryption). If it’s inadequate, the FDA may declare the device not substantially equivalent (NSE)<\/strong> to its predicate due to potential safety risks.<\/p>\n\n\n\nAdding “Controlled Risk” definition<\/strong><\/h2>\n\n\n\nNew guidance has been enriched with a ‘Controlled Risk’ definition.<\/p>\n\n\n\nFig. 2 Controlled risk<\/figcaption><\/figure>\n\n\n\nIt has been used to describe the type of vulnerability “that could present controlled risk” (types of vulnerabilities have already been addressed in the previous chapter).<\/p>\n\n\n\n
Updates in references<\/strong><\/strong><\/h2>\n\n\n\nGuidance adds the following references:<\/p>\n\n\n\n
\n- Section 3305 of FDORA<\/strong> (Food and Drug Omnibus Reform Act of 2022<\/em>) as an act implementing the already mentioned section 524B to the FD&C Act.<\/li>\n\n\n\n
- ANSI\/AAMI SW96:2023<\/strong>, Standard for medical device security – Security risk management for device manufacturers<\/em>, recently identified by FDA as a recognized consensus standard – it has been referred to as AAMI TIR 57, as an industry standard that aids in managing cybersecurity risks<\/strong> of the device, including:\n
\n- providing information on how to manage safety and security processes interaction to ensure that all risks are adequately assessed -ensuring that risk control measures for one type of risk assessment do not inadvertently introduce new risks in the other (Section V.A of guidance),<\/li>\n\n\n\n
- providing requirements and expectations for the Risk Management Plan and Report,<\/li>\n\n\n\n
- performing authorization checks based on benefit\/risk assessment,<\/li>\n\n\n\n
- determining if reacting to a security event is worth it, and how to do it safely when implementing event detection and logging.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- 21 CFR Part 806<\/strong> \u2013 it provides rules on handling and reporting corrections and removals of a device in case of post-market emerging vulnerabilities. Together with 21 CFR 820.100, it is referred as a supporting mechanism on establishing Cybersecurity Management Plans.<\/li>\n<\/ul>\n\n\n\n
Updates also include changes in already existing references:<\/p>\n\n\n\n
\n- Quality System (QS) Regulation<\/strong> 21 CFR Part 820(g) <\/strong>\u2013 the new guidance informs about the final rule taking effect on February 2, 2026, addressing risk management activities under QS Regulation. The rule is to be similar to the requirements of the Quality Management System of ISO 13485. The 2023 version of the risk management concept was based on a rule that was not yet in force.<\/li>\n\n\n\n
- JSP2<\/strong> \u2013 the new guidance updates the reference to the “Medical Device and Health IT Joint Security Plan (JSP) to its new version – JSP2. Although not-binding, the JSP is a FDA-recognized roadmap for building cybersecurity into medical devices. It is identified as a possible Secure Product Development Framework (SPDF) to meet FDA requirements and expectations.<\/li>\n<\/ul>\n\n\n\n
What is new in JSP2?<\/strong> Generally speaking, the main change is that JSP2 is now directly aligned with goals #6 and #7 from the 2024 Health Industry Cybersecurity Strategic Plan (HIC-SP):<\/p>\n\n\n\n\n- Goal 6<\/strong> promotes secure-by-design<\/em> and secure-by-default<\/em> approaches to technologies that aim to reduce the cybersecurity burden on end users.<\/li>\n\n\n\n
- Goal 7<\/strong> fosters a trusted healthcare ecosystem by collaborating with technology partners, suppliers, and service providers to strengthen long-term cybersecurity readiness.<\/li>\n<\/ul>\n\n\n\n
The updated 2025 FDA guidance on cybersecurity no longer directly refers to:<\/p>\n\n\n\n
\n- Machine Learning (ML)-based devices<\/strong>, but it doesn’t mean ML-based devices are not within its scope. FDA still recalls devices that “include artificial intelligence (AI) and cloud-based services”. Without a specific focus on ML, the FDA seems to emphasize that cybersecurity expectations apply based on risk and connectivity, <\/strong>not just the use of specific technologies like ML. <\/li>\n\n\n\n
- OTS-specific guidance on cybersecurity for MD <\/strong>(“Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” \u2013 taking new 2022 FDORA law and section 524B into account, the older OTS-specific guidance predates these rules and no longer reflects the FDA’s updated legal framework. The 2025 guidance seems to consolidate FDA cybersecurity expectations and absorb OTS software into its broadened scope.<\/li>\n\n\n\n
- NIST Suite B<\/strong> \u2013 as guidance aligns with current NIST recommended standards for cryptography, it removes already outdated NIST Suite B from the list.<\/li>\n<\/ul>\n\n\n\n
<\/a><\/figure>\n\n\n\nSummary<\/strong><\/h2>\n\n\n\nThe 2025 guidance<\/strong> builds upon the 2023 version by fully incorporating the legally binding requirements of Section 524B of the FD&C Act<\/strong>. While the 2023 edition introduced these requirements, the 2025 version explains required documentation for cyber devices in detail.<\/p>\n\n\n\nA key feature is new Section VII<\/strong>, which clearly outlines the documentation FDA expects in premarket submissions, helping manufacturers align with approval expectations.<\/p>\n\n\n\nThe 2025 update reinforces that cybersecurity is a core element of device safety and effectiveness<\/strong>, not just a technical add-on. It underscores cybersecurity as a total product lifecycle (TPLC)<\/strong> responsibility, emphasizing the need for Secure Product Development Framework (SPDF) integration, proactive risk management and threat modeling, timely identification and disclosure of vulnerabilities, and well-structured, comprehensive documentation.<\/p>\n\n\n\nOverall, the 2025 guidance provides clearer expectations and stronger alignment with regulatory requirements compared to its 2023 predecessor, raising the bar for how cybersecurity is addressed in both premarket and postmarket phases.<\/p>\n\n\n
Picking apart requirements for cyber devices<\/strong><\/strong><\/h3>\n\n\n\nBased on FDA requirements on Cybersecurity Documentation for Premarket Submissions, since March 29, 2023, the FDA may reject any submission for a cyber device if it does not include complete cybersecurity data.<\/strong><\/p>\n\n\n\nThe required data includes, in a nutshell:<\/p>\n\n\n\n
\n- Plans and Procedures <\/strong>on post-market vulnerability management – <\/strong>including vulnerability monitoring, response, and disclosure procedures.<\/li>\n\n\n\n
- Design, Development, and Maintenance Processes and Procedures<\/strong> on control of security updates and patches,including post-market surveillance.<\/li>\n\n\n\n
- SBOM <\/strong>\u2013Software Bill of Materials – a detailed software inventory.<\/li>\n\n\n\n
- Compliance with other FDA-regulated<\/strong> requirements.<\/li>\n<\/ol>\n\n\n\n
The FD&C Act 524B requirements are broadly worded, leaving a large space for interpretation, which often results in confusion and uncertainty.<\/p>\n\n\n\n
The newly issued guidance aims to bridge these gaps by offering a clear, structured approach to the specific documentation expected in premarket submissions<\/strong> for a cyber device. Key recommendations include:<\/p>\n\n\n\n\n- Plans and Procedures:<\/strong><\/strong>\n
\n- for disclosure procedures:\n
\n- to provide a plan based on the Cybersecurity Management Plan described in section VI.B of the guidance,<\/li>\n\n\n\n
- to include both internal and external\/third party (e.g., researchers, suppliers) sources for disclosures of the vulnerabilities and exploits, when applying disclosure procedures, like Coordinated Vulnerability Disclosure (CVD),<\/li>\n\n\n\n
- to take responsibility for disclosure procedures as a manufacturer.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for updates and patches \u2013 to adapt the release schedule to the type of vulnerability:\n
\n- regular schedule of release for “known unacceptable vulnerability”, which can be “a vulnerability that could not cause uncontrolled risks; a vulnerability that is not currently known to cause uncontrolled risks; or a vulnerability that could present controlled risk”,<\/li>\n\n\n\n
- as soon as possible, release for “critical vulnerabilities with uncontrolled risk”. Examples of these types of vulnerabilities can be found in Postmarket Security Guidance \u2013 “Postmarket Management of Cybersecurity in Medical Devices, 2016”.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for arising risks, threats, vulnerabilities, and other adverse factors:\n
\n- to keep up-to-date documentation throughout the total product lifecycle (TPLC),<\/li>\n\n\n\n
- to tailor actions to different risk profiles, i.e., actively marketed and older, still-used devices, to ensure an accurate assessment of patient risk for each available device version.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Design, Development, and Maintenance Processes and Procedures<\/strong><\/strong>: guidance underlines that:\n
\n- providing and maintaining required cybersecurity processes affects not only the device itself, but also its related systems<\/strong>, like servers for software\/firmware updates or healthcare network connections. That means it is essential to assess cybersecurity risks and apply proper security controls across all related systems, documenting everything as outlined in FDA guidance to demonstrate compliance.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- SBOM<\/strong>: the required SBOMs are recommended to contain supporting documentation described in detail in the guidance (section V.A.4.b).<\/li>\n<\/ol>\n\n\n\n
Submitting device modifications \u2013 what is required?<\/strong><\/strong><\/h3>\n\n\n\nCompliance with FD&C Act \u00a7524B also applies when submitting device modifications under the already mentioned FDA pathways. In that case, the required cybersecurity information depends on the type of change and its impact. Guidance explains what exactly is required for each case:<\/p>\n\n\n\n
\n- If the change may affect cybersecurity, full cybersecurity documentation described in section VII.C is required.<\/li>\n\n\n\n
- If the change is unlikely to impact cybersecurity, manufacturers still need to:\n
\n- submit or reference a cybersecurity plan,<\/li>\n\n\n\n
- state whether critical vulnerabilities exist or were fixed,<\/li>\n\n\n\n
- provide an up-to-date SBOM (Software Bill of Materials).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Cybersecurity as a determinant of FDA approval<\/strong><\/strong><\/h3>\n\n\n\nAs devices become more interconnected, ensuring cybersecurity is now essential to protect public health. Guidance states that FDA treats “Reasonable assurance of cybersecurity”<\/strong> as a key component in ensuring a medical device’s safety and effectiveness<\/strong>. According to the 2022 FDORA law, the new cybersecurity rules (Section 524B) do not<\/strong> limit the FDA’s power to review cybersecurity when evaluating a medical device. This means that cybersecurity can directly influence the FDA’s approval decisions for devices submitted under the <\/strong>aforementioned pathways.<\/p>\n\n\n\nIn 510(k) reviews, the FDA considers how new risks or technological changes (e.g., added connectivity) affect cybersecurity and whether the device has proper protection. The FDA may request additional data if the device lacks protection against known threats (e.g., a nursing station alarm system without proper encryption). If it’s inadequate, the FDA may declare the device not substantially equivalent (NSE)<\/strong> to its predicate due to potential safety risks.<\/p>\n\n\n\nAdding “Controlled Risk” definition<\/strong><\/h2>\n\n\n\nNew guidance has been enriched with a ‘Controlled Risk’ definition.<\/p>\n\n\n\nFig. 2 Controlled risk<\/figcaption><\/figure>\n\n\n\nIt has been used to describe the type of vulnerability “that could present controlled risk” (types of vulnerabilities have already been addressed in the previous chapter).<\/p>\n\n\n\n
Updates in references<\/strong><\/strong><\/h2>\n\n\n\nGuidance adds the following references:<\/p>\n\n\n\n
\n- Section 3305 of FDORA<\/strong> (Food and Drug Omnibus Reform Act of 2022<\/em>) as an act implementing the already mentioned section 524B to the FD&C Act.<\/li>\n\n\n\n
- ANSI\/AAMI SW96:2023<\/strong>, Standard for medical device security – Security risk management for device manufacturers<\/em>, recently identified by FDA as a recognized consensus standard – it has been referred to as AAMI TIR 57, as an industry standard that aids in managing cybersecurity risks<\/strong> of the device, including:\n
\n- providing information on how to manage safety and security processes interaction to ensure that all risks are adequately assessed -ensuring that risk control measures for one type of risk assessment do not inadvertently introduce new risks in the other (Section V.A of guidance),<\/li>\n\n\n\n
- providing requirements and expectations for the Risk Management Plan and Report,<\/li>\n\n\n\n
- performing authorization checks based on benefit\/risk assessment,<\/li>\n\n\n\n
- determining if reacting to a security event is worth it, and how to do it safely when implementing event detection and logging.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- 21 CFR Part 806<\/strong> \u2013 it provides rules on handling and reporting corrections and removals of a device in case of post-market emerging vulnerabilities. Together with 21 CFR 820.100, it is referred as a supporting mechanism on establishing Cybersecurity Management Plans.<\/li>\n<\/ul>\n\n\n\n
Updates also include changes in already existing references:<\/p>\n\n\n\n
\n- Quality System (QS) Regulation<\/strong> 21 CFR Part 820(g) <\/strong>\u2013 the new guidance informs about the final rule taking effect on February 2, 2026, addressing risk management activities under QS Regulation. The rule is to be similar to the requirements of the Quality Management System of ISO 13485. The 2023 version of the risk management concept was based on a rule that was not yet in force.<\/li>\n\n\n\n
- JSP2<\/strong> \u2013 the new guidance updates the reference to the “Medical Device and Health IT Joint Security Plan (JSP) to its new version – JSP2. Although not-binding, the JSP is a FDA-recognized roadmap for building cybersecurity into medical devices. It is identified as a possible Secure Product Development Framework (SPDF) to meet FDA requirements and expectations.<\/li>\n<\/ul>\n\n\n\n
What is new in JSP2?<\/strong> Generally speaking, the main change is that JSP2 is now directly aligned with goals #6 and #7 from the 2024 Health Industry Cybersecurity Strategic Plan (HIC-SP):<\/p>\n\n\n\n\n- Goal 6<\/strong> promotes secure-by-design<\/em> and secure-by-default<\/em> approaches to technologies that aim to reduce the cybersecurity burden on end users.<\/li>\n\n\n\n
- Goal 7<\/strong> fosters a trusted healthcare ecosystem by collaborating with technology partners, suppliers, and service providers to strengthen long-term cybersecurity readiness.<\/li>\n<\/ul>\n\n\n\n
The updated 2025 FDA guidance on cybersecurity no longer directly refers to:<\/p>\n\n\n\n
\n- Machine Learning (ML)-based devices<\/strong>, but it doesn’t mean ML-based devices are not within its scope. FDA still recalls devices that “include artificial intelligence (AI) and cloud-based services”. Without a specific focus on ML, the FDA seems to emphasize that cybersecurity expectations apply based on risk and connectivity, <\/strong>not just the use of specific technologies like ML. <\/li>\n\n\n\n
- OTS-specific guidance on cybersecurity for MD <\/strong>(“Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” \u2013 taking new 2022 FDORA law and section 524B into account, the older OTS-specific guidance predates these rules and no longer reflects the FDA’s updated legal framework. The 2025 guidance seems to consolidate FDA cybersecurity expectations and absorb OTS software into its broadened scope.<\/li>\n\n\n\n
- NIST Suite B<\/strong> \u2013 as guidance aligns with current NIST recommended standards for cryptography, it removes already outdated NIST Suite B from the list.<\/li>\n<\/ul>\n\n\n\n
<\/a><\/figure>\n\n\n\nSummary<\/strong><\/h2>\n\n\n\nThe 2025 guidance<\/strong> builds upon the 2023 version by fully incorporating the legally binding requirements of Section 524B of the FD&C Act<\/strong>. While the 2023 edition introduced these requirements, the 2025 version explains required documentation for cyber devices in detail.<\/p>\n\n\n\nA key feature is new Section VII<\/strong>, which clearly outlines the documentation FDA expects in premarket submissions, helping manufacturers align with approval expectations.<\/p>\n\n\n\nThe 2025 update reinforces that cybersecurity is a core element of device safety and effectiveness<\/strong>, not just a technical add-on. It underscores cybersecurity as a total product lifecycle (TPLC)<\/strong> responsibility, emphasizing the need for Secure Product Development Framework (SPDF) integration, proactive risk management and threat modeling, timely identification and disclosure of vulnerabilities, and well-structured, comprehensive documentation.<\/p>\n\n\n\nOverall, the 2025 guidance provides clearer expectations and stronger alignment with regulatory requirements compared to its 2023 predecessor, raising the bar for how cybersecurity is addressed in both premarket and postmarket phases.<\/p>\n\n\n
The required data includes, in a nutshell:<\/p>\n\n\n\n
- \n
- Plans and Procedures <\/strong>on post-market vulnerability management – <\/strong>including vulnerability monitoring, response, and disclosure procedures.<\/li>\n\n\n\n
- Design, Development, and Maintenance Processes and Procedures<\/strong> on control of security updates and patches,including post-market surveillance.<\/li>\n\n\n\n
- SBOM <\/strong>\u2013Software Bill of Materials – a detailed software inventory.<\/li>\n\n\n\n
- Compliance with other FDA-regulated<\/strong> requirements.<\/li>\n<\/ol>\n\n\n\n
The FD&C Act 524B requirements are broadly worded, leaving a large space for interpretation, which often results in confusion and uncertainty.<\/p>\n\n\n\n
The newly issued guidance aims to bridge these gaps by offering a clear, structured approach to the specific documentation expected in premarket submissions<\/strong> for a cyber device. Key recommendations include:<\/p>\n\n\n\n
- \n
- Plans and Procedures:<\/strong><\/strong>\n
- \n
- for disclosure procedures:\n
- \n
- to provide a plan based on the Cybersecurity Management Plan described in section VI.B of the guidance,<\/li>\n\n\n\n
- to include both internal and external\/third party (e.g., researchers, suppliers) sources for disclosures of the vulnerabilities and exploits, when applying disclosure procedures, like Coordinated Vulnerability Disclosure (CVD),<\/li>\n\n\n\n
- to take responsibility for disclosure procedures as a manufacturer.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for updates and patches \u2013 to adapt the release schedule to the type of vulnerability:\n
- \n
- regular schedule of release for “known unacceptable vulnerability”, which can be “a vulnerability that could not cause uncontrolled risks; a vulnerability that is not currently known to cause uncontrolled risks; or a vulnerability that could present controlled risk”,<\/li>\n\n\n\n
- as soon as possible, release for “critical vulnerabilities with uncontrolled risk”. Examples of these types of vulnerabilities can be found in Postmarket Security Guidance \u2013 “Postmarket Management of Cybersecurity in Medical Devices, 2016”.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for arising risks, threats, vulnerabilities, and other adverse factors:\n
- \n
- to keep up-to-date documentation throughout the total product lifecycle (TPLC),<\/li>\n\n\n\n
- to tailor actions to different risk profiles, i.e., actively marketed and older, still-used devices, to ensure an accurate assessment of patient risk for each available device version.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Design, Development, and Maintenance Processes and Procedures<\/strong><\/strong>: guidance underlines that:\n
- \n
- providing and maintaining required cybersecurity processes affects not only the device itself, but also its related systems<\/strong>, like servers for software\/firmware updates or healthcare network connections. That means it is essential to assess cybersecurity risks and apply proper security controls across all related systems, documenting everything as outlined in FDA guidance to demonstrate compliance.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- SBOM<\/strong>: the required SBOMs are recommended to contain supporting documentation described in detail in the guidance (section V.A.4.b).<\/li>\n<\/ol>\n\n\n\n
Submitting device modifications \u2013 what is required?<\/strong><\/strong><\/h3>\n\n\n\n
Compliance with FD&C Act \u00a7524B also applies when submitting device modifications under the already mentioned FDA pathways. In that case, the required cybersecurity information depends on the type of change and its impact. Guidance explains what exactly is required for each case:<\/p>\n\n\n\n
- \n
- If the change may affect cybersecurity, full cybersecurity documentation described in section VII.C is required.<\/li>\n\n\n\n
- If the change is unlikely to impact cybersecurity, manufacturers still need to:\n
- \n
- submit or reference a cybersecurity plan,<\/li>\n\n\n\n
- state whether critical vulnerabilities exist or were fixed,<\/li>\n\n\n\n
- provide an up-to-date SBOM (Software Bill of Materials).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Cybersecurity as a determinant of FDA approval<\/strong><\/strong><\/h3>\n\n\n\n
As devices become more interconnected, ensuring cybersecurity is now essential to protect public health. Guidance states that FDA treats “Reasonable assurance of cybersecurity”<\/strong> as a key component in ensuring a medical device’s safety and effectiveness<\/strong>. According to the 2022 FDORA law, the new cybersecurity rules (Section 524B) do not<\/strong> limit the FDA’s power to review cybersecurity when evaluating a medical device. This means that cybersecurity can directly influence the FDA’s approval decisions for devices submitted under the <\/strong>aforementioned pathways.<\/p>\n\n\n\n
In 510(k) reviews, the FDA considers how new risks or technological changes (e.g., added connectivity) affect cybersecurity and whether the device has proper protection. The FDA may request additional data if the device lacks protection against known threats (e.g., a nursing station alarm system without proper encryption). If it’s inadequate, the FDA may declare the device not substantially equivalent (NSE)<\/strong> to its predicate due to potential safety risks.<\/p>\n\n\n\n
Adding “Controlled Risk” definition<\/strong><\/h2>\n\n\n\n
New guidance has been enriched with a ‘Controlled Risk’ definition.<\/p>\n\n\n\n
Fig. 2 Controlled risk<\/figcaption><\/figure>\n\n\n\n It has been used to describe the type of vulnerability “that could present controlled risk” (types of vulnerabilities have already been addressed in the previous chapter).<\/p>\n\n\n\n
Updates in references<\/strong><\/strong><\/h2>\n\n\n\n
Guidance adds the following references:<\/p>\n\n\n\n
- \n
- Section 3305 of FDORA<\/strong> (Food and Drug Omnibus Reform Act of 2022<\/em>) as an act implementing the already mentioned section 524B to the FD&C Act.<\/li>\n\n\n\n
- ANSI\/AAMI SW96:2023<\/strong>, Standard for medical device security – Security risk management for device manufacturers<\/em>, recently identified by FDA as a recognized consensus standard – it has been referred to as AAMI TIR 57, as an industry standard that aids in managing cybersecurity risks<\/strong> of the device, including:\n
- \n
- providing information on how to manage safety and security processes interaction to ensure that all risks are adequately assessed -ensuring that risk control measures for one type of risk assessment do not inadvertently introduce new risks in the other (Section V.A of guidance),<\/li>\n\n\n\n
- providing requirements and expectations for the Risk Management Plan and Report,<\/li>\n\n\n\n
- performing authorization checks based on benefit\/risk assessment,<\/li>\n\n\n\n
- determining if reacting to a security event is worth it, and how to do it safely when implementing event detection and logging.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- 21 CFR Part 806<\/strong> \u2013 it provides rules on handling and reporting corrections and removals of a device in case of post-market emerging vulnerabilities. Together with 21 CFR 820.100, it is referred as a supporting mechanism on establishing Cybersecurity Management Plans.<\/li>\n<\/ul>\n\n\n\n
Updates also include changes in already existing references:<\/p>\n\n\n\n
- \n
- Quality System (QS) Regulation<\/strong> 21 CFR Part 820(g) <\/strong>\u2013 the new guidance informs about the final rule taking effect on February 2, 2026, addressing risk management activities under QS Regulation. The rule is to be similar to the requirements of the Quality Management System of ISO 13485. The 2023 version of the risk management concept was based on a rule that was not yet in force.<\/li>\n\n\n\n
- JSP2<\/strong> \u2013 the new guidance updates the reference to the “Medical Device and Health IT Joint Security Plan (JSP) to its new version – JSP2. Although not-binding, the JSP is a FDA-recognized roadmap for building cybersecurity into medical devices. It is identified as a possible Secure Product Development Framework (SPDF) to meet FDA requirements and expectations.<\/li>\n<\/ul>\n\n\n\n
What is new in JSP2?<\/strong> Generally speaking, the main change is that JSP2 is now directly aligned with goals #6 and #7 from the 2024 Health Industry Cybersecurity Strategic Plan (HIC-SP):<\/p>\n\n\n\n
- \n
- Goal 6<\/strong> promotes secure-by-design<\/em> and secure-by-default<\/em> approaches to technologies that aim to reduce the cybersecurity burden on end users.<\/li>\n\n\n\n
- Goal 7<\/strong> fosters a trusted healthcare ecosystem by collaborating with technology partners, suppliers, and service providers to strengthen long-term cybersecurity readiness.<\/li>\n<\/ul>\n\n\n\n
The updated 2025 FDA guidance on cybersecurity no longer directly refers to:<\/p>\n\n\n\n
- \n
- Machine Learning (ML)-based devices<\/strong>, but it doesn’t mean ML-based devices are not within its scope. FDA still recalls devices that “include artificial intelligence (AI) and cloud-based services”. Without a specific focus on ML, the FDA seems to emphasize that cybersecurity expectations apply based on risk and connectivity, <\/strong>not just the use of specific technologies like ML. <\/li>\n\n\n\n
- OTS-specific guidance on cybersecurity for MD <\/strong>(“Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” \u2013 taking new 2022 FDORA law and section 524B into account, the older OTS-specific guidance predates these rules and no longer reflects the FDA’s updated legal framework. The 2025 guidance seems to consolidate FDA cybersecurity expectations and absorb OTS software into its broadened scope.<\/li>\n\n\n\n
- NIST Suite B<\/strong> \u2013 as guidance aligns with current NIST recommended standards for cryptography, it removes already outdated NIST Suite B from the list.<\/li>\n<\/ul>\n\n\n\n
<\/a><\/figure>\n\n\n\nSummary<\/strong><\/h2>\n\n\n\n
The 2025 guidance<\/strong> builds upon the 2023 version by fully incorporating the legally binding requirements of Section 524B of the FD&C Act<\/strong>. While the 2023 edition introduced these requirements, the 2025 version explains required documentation for cyber devices in detail.<\/p>\n\n\n\n
A key feature is new Section VII<\/strong>, which clearly outlines the documentation FDA expects in premarket submissions, helping manufacturers align with approval expectations.<\/p>\n\n\n\n
The 2025 update reinforces that cybersecurity is a core element of device safety and effectiveness<\/strong>, not just a technical add-on. It underscores cybersecurity as a total product lifecycle (TPLC)<\/strong> responsibility, emphasizing the need for Secure Product Development Framework (SPDF) integration, proactive risk management and threat modeling, timely identification and disclosure of vulnerabilities, and well-structured, comprehensive documentation.<\/p>\n\n\n\n
Overall, the 2025 guidance provides clearer expectations and stronger alignment with regulatory requirements compared to its 2023 predecessor, raising the bar for how cybersecurity is addressed in both premarket and postmarket phases.<\/p>\n\n\n
- OTS-specific guidance on cybersecurity for MD <\/strong>(“Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software” \u2013 taking new 2022 FDORA law and section 524B into account, the older OTS-specific guidance predates these rules and no longer reflects the FDA’s updated legal framework. The 2025 guidance seems to consolidate FDA cybersecurity expectations and absorb OTS software into its broadened scope.<\/li>\n\n\n\n
- Goal 7<\/strong> fosters a trusted healthcare ecosystem by collaborating with technology partners, suppliers, and service providers to strengthen long-term cybersecurity readiness.<\/li>\n<\/ul>\n\n\n\n
- JSP2<\/strong> \u2013 the new guidance updates the reference to the “Medical Device and Health IT Joint Security Plan (JSP) to its new version – JSP2. Although not-binding, the JSP is a FDA-recognized roadmap for building cybersecurity into medical devices. It is identified as a possible Secure Product Development Framework (SPDF) to meet FDA requirements and expectations.<\/li>\n<\/ul>\n\n\n\n
- Quality System (QS) Regulation<\/strong> 21 CFR Part 820(g) <\/strong>\u2013 the new guidance informs about the final rule taking effect on February 2, 2026, addressing risk management activities under QS Regulation. The rule is to be similar to the requirements of the Quality Management System of ISO 13485. The 2023 version of the risk management concept was based on a rule that was not yet in force.<\/li>\n\n\n\n
- ANSI\/AAMI SW96:2023<\/strong>, Standard for medical device security – Security risk management for device manufacturers<\/em>, recently identified by FDA as a recognized consensus standard – it has been referred to as AAMI TIR 57, as an industry standard that aids in managing cybersecurity risks<\/strong> of the device, including:\n
- Section 3305 of FDORA<\/strong> (Food and Drug Omnibus Reform Act of 2022<\/em>) as an act implementing the already mentioned section 524B to the FD&C Act.<\/li>\n\n\n\n
- SBOM<\/strong>: the required SBOMs are recommended to contain supporting documentation described in detail in the guidance (section V.A.4.b).<\/li>\n<\/ol>\n\n\n\n
- providing and maintaining required cybersecurity processes affects not only the device itself, but also its related systems<\/strong>, like servers for software\/firmware updates or healthcare network connections. That means it is essential to assess cybersecurity risks and apply proper security controls across all related systems, documenting everything as outlined in FDA guidance to demonstrate compliance.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- for disclosure procedures:\n
- Design, Development, and Maintenance Processes and Procedures<\/strong> on control of security updates and patches,including post-market surveillance.<\/li>\n\n\n\n