医疗器械网络安全：质量管理体系考量与上市前提交内容
Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
发布日期: 2026-02-03
INFO
This content has been machine-translated from the English original.
官方文件全文
医疗器械的网络安全：质量管理体系考虑及上市前提交内容
发布日期： 2026-02-03
本指南代表美国食品药品监督管理局（FDA或机构）对该主题的当前观点。它不赋予任何个人任何权利，并且不适用于FDA或公众。如果您采用替代方法，只要它符合相关法律和法规的要求，就可以使用。要讨论替代方法，请联系负责本指南的FDA工作人员或办公室，如标题页上所示。
I. 简介
随着无线、互联网和网络连接功能的日益集成，以及便携式媒体（如USB或CD）以及医疗设备相关健康信息和其他信息的频繁电子交换，确保医疗设备安全性和有效性的强大网络安全控制的需求变得越来越重要。
此外，对医疗领域的网络安全威胁变得更加频繁和严重，并可能对临床产生更大的影响。网络安全事件导致医疗设备和医院网络无法正常运行，从而中断了美国及全球医疗机构提供的患者护理。 这样的网络安全事件和漏洞可能导致患者因临床风险（如诊断和/或治疗延误）而受到伤害。
更高的互连性导致单个设备作为更大医疗设备系统的单个组成部分运行。 这些系统可能包括医疗机构网络、其他设备以及软件更新服务器等其他相互连接的组件。 因此，在所有这些系统的各个方面都缺乏充分的网络安全考虑，网络安全威胁可能会通过损害系统中的任何资产的功能来损害设备的安全性或有效性。 因此，确保设备的安全性和有效性，包括充分的网络安全，以及作为更大系统的一部分，确保其安全。
有关本文件中引用的、由FDA认可的共识标准（当前版本），请参阅“FDA认可的共识标准数据库”。
II. 范围
本指南适用于具有网络安全考虑的设备，包括但不限于包含设备软件功能1或包含软件（包括固件）或可编程逻辑的设备。本指南不限于网络连接或包含其他连接功能的设备。本指南描述了针对在以下情况下向设备和放射健康中心（CDRH）或生物制品评估与研究中心（CBER）提交的预上市提交类型，所提出的关于网络安全信息的建议：
510(k) 预上市通知；
De Novo 请求；
预上市批准申请（PMAs）和PMAs补充；
产品开发协议（PDPs）；
临床试验设备豁免（IDE）申请；
人道设备豁免（HDE）申请；
生物制品许可证申请（BLA）申请；以及
临床试验新药（IND）申请。
此外，本指南适用于根据《美国食品药品监督管理局法》(FD&C Act)第 201(h) 条的定义的所有类型的设备，包括符合《公共卫生服务法》第 351 条定义的生物产品，无论是否需要预先提交。 因此，本指南中的建议也适用于不需要预先提交的设备（例如，符合 510(k) 免除规定的设备）。本指南也适用于根据《美国食品药品监督管理局法》第 524B 条定义的网络设备，这些设备是设备的一小部分。 通常，本指南中的建议适用于组合产品的设备成分（例如，药物-设备和生物产品-设备组合产品），前提是…… 由于 IDE 提交的风险-效益阈值不同，且不涉及营销批准，因此，关于 IDE 提交文档的具体建议已在附录 3 中提供。 此外，附录 5 包含本指南中使用的术语。
III. 背景
FDA 认识到，医疗设备网络安全是医疗设备系统使用环境中，包括医疗机构、患者、医疗服务提供者和医疗设备制造商等各方共同的责任。 鉴于此，本指南中的“医疗设备系统”一词包括与该设备及其系统（如医疗机构网络、其他设备和软件更新服务器）相连的设备和系统。 在医疗保健领域，强调了网络安全对患者安全的必要性。 万国克里（WannaCry5）勒索软件已影响全球的医院系统和医疗设备。 针对常用第三方组件（如 URGENT/117 和 SweynTooth）的漏洞，已导致在各种临床专科中广泛使用的设备中出现潜在的安全问题。 2020年，德国医院遭受的勒索软件攻击，突显了因网络安全攻击导致患者护理延误可能造成的潜在影响。9 FDA 于 2014 年发布了最终的网络安全指南《医疗设备网络安全管理的前市场提交内容》，以及补充指南《医疗设备网络安全管理后的管理》，后文简称“后市场网络安全指南”。 然而，随着快速发展的环境、对新兴威胁的深入理解以及在整个产品生命周期（TPLC）中有效部署缓解措施的需求，需要对医疗设备网络安全采取更新和迭代的方法。 2014 年指南所做的变更旨在进一步强调确保设备设计安全、设计为 研究（CDER）和组合产品办公室（OCP）。 勒索软件。 通过实施和采用安全产品开发框架（SPDF）来实现这些 TPLC 考虑是可行的。10 按照本指南所述，SPDF 是一套流程，旨在减少产品在设备生命周期中漏洞的数量和严重程度。 许多领域，包括医疗设备领域，都存在类似的框架。 对医疗设备制造商的网络安全管理是，识别、分析、评估、控制和监控产品在整个生命周期中的风险，以确保其制造的设备是安全的和有效的。 FDA 发布了最终的规则11，修订了《质量系统（QS）条例》第 21 CFR 820 条，以更紧密地符合全球共识标准，该标准适用于许多其他监管机构使用的医疗设备。 此修订后的第 820 部分被称为《质量管理系统条例（QMSR）》。 QMSR 引用了 2016 年版的 ISO 13
IV. 总体原则
本部分提供了与医疗器械制造商相关的，关于医疗器械网络安全的一般原则。本指南中的原则对于提高医疗器械的网络安全至关重要，并且，如果遵循这些原则，预计将对医疗器械的安全性和有效性产生积极影响。本指南中的建议涵盖所有可能影响医疗器械安全性和有效性的相关网络安全考虑因素，包括但不限于软件、硬件和固件。
A. 网络安全是医疗器械安全和质量的一部分
质量管理系统法规 (QMSR) 医疗器械制造商必须建立并遵循质量管理系统，以确保其产品始终符合适用的要求和规范。 质量管理系统的要求可在 21 CFR 第 820 部分的 QMSR 中找到，该部分引用了 ISO 13485。 具体取决于医疗器械，QMS 的要求可能适用于上市前、上市后或两者。
14 尽管《食品、药品及化妆品法》第 524B(b)(4) 条授权 FDA 依据法规制定额外的网络安全要求，但 FDA 无需制定法规来详细说明《食品、药品及化妆品法》第 524B 条中规定的新要求。
除了《食品、药品及化妆品法》第 524B(b) 条中规定的网络安全要求外，第 524B(b)(4) 条还要求网络安全设备制造商遵守 FDA 规定的任何其他要求，以“证明该设备及其相关系统具有合理的网络安全保障”。
在上市后，设计和开发对于确保医疗器械的网络安全以及保持医疗器械的安全性和有效性也至关重要。 FDA 建议医疗器械制造商实施与 QMSR 保持一致的全面网络安全风险管理计划和文档，包括但不限于投诉处理（ISO 13485 第 8.2.2 条和 21 CFR 820.35(a)）、质量审计（第 8.2.4 条）、数据分析和改进（第 8.4 和 8.5 条）、软件验证（第 7.3.7 条）、风险管理（第 7.1 条）和维护（第 7.5.4 条和 21 CFR 820.35(b)）。
在上市前，为了证明某些具有网络安全风险的医疗器械的安全性和有效性，与 QMSR 的持续要求相关的文档输出可以作为上市前提交的一部分。17 本指南旨在解释如何使用与 QMSR 合规相关的此类文档，以证明赞助人或制造商如何处理与设备相关的网络安全考虑。 例如，21 CFR 820.10(c) 要求，对于所有通过软件自动化的设备，制造商必须符合 ISO 13485 第 7.3 条及其子条的“设计和开发”要求。
1. 安全产品开发框架 (SPDF) 可能是满足 QMSR 的一种方法
网络安全威胁有可能利用系统中存在的漏洞，从而导致患者受到伤害。 随着系统（包括设备）中存在的漏洞数量和/或随着时间的推移被发现的数量增加，威胁更容易损害医疗设备的安全性及有效性。 SPDF 是一套流程，旨在帮助识别和减少产品中漏洞的数量和严重程度。 SPDF 涵盖产品的整个生命周期，包括设计、开发、发布、支持和报废。 此外，在设备设计中使用 SPDF 流程可以避免重新设计的需求。 17 本指南中的建议并非旨在表明 FDA 将在根据《美国食品药品监督法》第 510(k) 条对申请人的 QMSR 合规性进行评估时，作为确定医疗设备“实质性等效性”的依据，但这一要求并非根据《美国食品药品监督法》第 513(i) 条的要求。 本指南旨在解释 FDA 如何评估医疗设备网络安全以及符合 QMSR 活动的网络安全输出，并解释如何利用 QMSR 来证明这些性能输出。 18 本指南中对条款和子条款的引用，应与 ISO 13485:2016 的条款和子条款相对应，除非另有说明。 使用 SPDF 是一种确保满足 QMSR 的方法。 由于其在满足 QMSR 和网络安全方面的优势，FDA 鼓励制造商使用 SPDF，但其他方法也可能满足 QMSR。
B. 设计用于安全
在审查上市前提交时，FDA 计划根据以下因素评估医疗设备的网络安全，包括但不限于，设备在整个架构中实现以下安全目标的能力。以下安全目标通常适用于本指南所涵盖的设备，包括但不限于包含人工智能 (AI) 和基于云的服务的产品。 安全目标：
真实性，包括完整性；
授权；
可用性；
保密性；以及
安全且及时的更新和补丁能力。
上市前提交应包含描述如何满足和整合上述安全目标的设备设计的信息。满足这些目标所需的安全要求、架构、供应链和实施的程度将取决于但不限于：
设备的预期用途、适应症以及合理可预见的滥用；
其电子数据接口的存在和功能；
其预期和实际的使用环境；
网络安全漏洞带来的风险；
漏洞的可利用性；以及
因漏洞利用而造成的患者伤害风险。
SPDF（安全产品开发）的目标是减少漏洞的数量和严重程度，从而降低医疗设备系统的可利用性，并降低患者受伤的风险。由于利用已知的漏洞或弱化的网络安全控制应被视为医疗设备系统的合理可预见的故障模式，因此这些因素应在设备设计中加以考虑。
使用SPDF的一个关键优势是，它可以帮助医疗设备：
20 制造商可能无法考虑到所有潜在的使用环境，但应考虑各种使用环境，并确保识别和控制最坏情况的使用环境（例如，最不安全的预期网络配置）。
透明性 缺乏网络安全信息，例如，用于将设备集成到使用环境中的信息，以及用户在设备生命周期内维护医疗设备系统网络安全所需的必要信息，可能会影响设备的安全性及有效性。为了解决这些问题，对于设备用户来说，获得关于设备网络安全控制、医疗设备系统潜在风险以及其他相关信息的途径至关重要。例如：
未披露所有通信接口或第三方软件，可能会导致无法传达潜在的风险来源。
如果缺乏关于设备是否存在已知的但未披露的网络安全漏洞或风险的信息，这可能与确定设备的安全或有效性是否可能受到损害有关；或
如果标签中缺少足够的信息，无法解释如何安全地配置或更新设备，可能会限制最终用户正确管理和保护医疗设备系统的能力。
这些信息以及其他相关信息对于帮助用户了解医疗器械系统抵抗网络安全威胁的能力、可能面临的威胁以及如何预防或减轻这些威胁至关重要。如果没有这些信息，网络安全风险可能会被隐藏、错误识别或不当处理，从而导致设备安全和有效性受到损害。 FDA 认为，本指南中讨论的网络安全信息对于确保设备安全有效使用至关重要，并且应包含在设备标签中，如以下第 VI 节所述。
D. 提交文件
设备网络安全设计和文档应与该设备的网络安全风险相匹配。制造商应考虑设备可能使用的更大系统。例如，对一个简单的、未连接的温度计进行的网络安全风险评估可能得出结论，该风险有限，因此，该设备只需要有限的安全架构（即，仅针对设备硬件和软件），并基于设备的特定技术特征和设计，实施少量安全控制。然而，如果该温度计用于关键的安全控制回路，或者连接到网络或其他设备，则该设备的网络安全风险被认为更大，并且需要进行更全面的设计和开发活动。提交方应考虑在向FDA提交的预上市文档中，包含来自这些设计和开发活动的结果，以证明对安全性和有效性的合理保证。本指南标识了FDA建议的信息，以支持符合本指南范围内的设备的预上市提交，包括但不限于网络设备。
由于网络安全是设备安全和有效性的组成部分，因此，在预上市开发过程中建立的网络安全控制也应考虑预期的和实际的使用环境（参见第四节B）。随着时间的推移，网络安全风险会演变，因此，网络安全控制的有效性可能会随着新的风险、威胁和攻击方法的出现而下降。在510(k)的背景下，FDA会评估提交的网络安全信息以及网络安全控制提供的保护，以证明实质性等效性（参见《药品及化妆品法》第513(i)条和21 CFR 807.100(b)(2)(ii)(B)）。
此外，如果设备标签中缺乏充分的网络安全信息，可能会导致设备在《药品及化妆品法》第502(f)条下被错误标记，如果该标签不包含充分的使用说明，或者在《药品及化妆品法》第502(j)条下被错误标记，因为在标签中推荐或建议的使用方式下，该设备对健康有害。对于网络设备，未能遵守《药品及化妆品法》第524B(b)(2)条规定的任何要求（与确保设备网络安全相关），将被视为违反《药品及化妆品法》第301(q)条的行为。
本指南建议，在基于网络安全风险的提交中，应包含网络安全信息，而不是任何其他标准或风险/担忧级别，这些级别已在单独的FDA指南中确立。例如，如果确定某个设备具有更高的
V. 利用 SPDF 管理网络安全风险
本指南中推荐的文档，是基于FDA评估具有网络安全漏洞的医疗器械的安全性及有效性的经验。然而，制造商可以采用替代方法并提供不同的文档，只要其方法和文档符合相关法律规定的上市前提交要求。
如前所述，《食品、药品及化妆品法》第524B条要求提交有关网络安全设备的特定文档。有关网络安全设备的更多信息，请参见本指南的第VII部分。
使用SPDF的主要目标是制造和维护安全有效的设备。
从安全角度来看，这些设备也是值得信赖且具有弹性的设备。这些设备可以通过设备制造商和/或用户（例如，患者、医疗机构）的设计和相关的标签进行管理（例如，安装、配置、更新、设备日志审查）。对于医疗机构，这些设备也可以在自身的网络安全风险管理框架内进行管理，例如美国国家标准与技术研究所（NIST）的“改善关键基础设施网络安全”框架，通常被称为NIST网络安全框架或NIST CSF。25
FDA建议制造商使用如QMSR中描述的设备设计流程，包括ISO 13485，以支持安全的产品开发和维护。为了保持制造商的灵活性，制造商可以使用满足QMSR并符合FDA关于使用SPDF的建议的其他现有框架。可能的框架包括，但不限于，可在《医疗器械与健康信息技术联合安全计划（JSP2）》中找到的，特定于医疗器械的框架，以及IEC 81001-5-1。来自其他行业的框架也可能符合QMSR，例如ANSI/ISA 62443-4-1《工业自动化和控制系统安全》第4-1部分：产品安全开发生命周期的要求。27
以下子章节提供了关于使用SPDF流程的建议，FDA认为这些流程对于开发安全有效的设备具有重要考虑，这些流程如何补充QMSR，以及FDA建议制造商作为上市前提交的一部分进行审查的文档。这些建议可能对必须“设计、开发和维护流程和程序，以提供合理保证，确保设备和相关系统具有网络安全”的网络安全设备制造商有所帮助（参见《食品、药品及化妆品法》第524B条(b)(2)）。这些章节中的信息并不代表完整的SPDF。有关SPDF的更多信息，请参见第V部分的早期部分。此外，FDA不建议制造商停止现
A. 安全风险管理
为了全面评估医疗器械系统中网络安全风险，每个设备的安全性与安全风险应在更大的系统中进行评估，即在设备所运行的系统中。在网络安全方面，安全风险管理流程至关重要。
24 应对网络安全风险，是在应对其他风险（包括软件、生物相容性、灭菌和电磁兼容性等）之外的。 27 ANSI/ISA-62443-4-1《工业自动化和控制系统安全》第4-1部分：产品安全开发生命周期要求，概述了与JSP2相似的产品安全开发生命周期。 因为，鉴于网络安全威胁和风险的不断演变，任何设备都无法完全安全。安全风险管理应成为制造商整个质量管理系统的组成部分，贯穿于整个TPLC。28 质量管理系统流程包括技术、人员和管理实践等，制造商使用这些实践来管理其设备可能存在的风险，并确保其设备在市场上，并且在市场上，是安全的并且有效，包括安全。 进行安全风险管理与在ISO 14971中描述的安全风险管理不同。这些流程的差异在于，在安全方面与安全方面，潜在危害的范围和风险评估因素可能不同。此外，虽然安全风险管理侧重于身体伤害、财产或环境损坏，或由于设备或系统不可用而导致的护理延误和/或拒绝，但安全风险管理可能包括可以导致患者间接或直接伤害的风险。此外，与FDA的安全性有效性评估相关的风险，例如与业务或声誉相关的风险，也可能存在。 一个安全风险管理流程的范围和目标，与其他的SPDF流程（例如安全测试）结合使用，是揭示如何通过漏洞，使威胁能够对患者和其他潜在风险产生影响。这些流程还应确保，针对一种风险评估的控制措施，不会无意中在另一种风险中引入新的风险。 例如，AAMI TIR57和ANSI/AAMI SW96详细说明了如何使安全和安全风险管理流程相互配合，以确保所有风险得到充分评估。29 FDA 建议，如QMSR和ISO 13485中详细说明的网络安全风险管理流程，应建立或纳入已有的流程，并应解决制造商的设计、制造和分销流程，以及贯穿于整个TPLC的更新。在QMSR中作为参考的ISO 13
总结风险评估方法和流程；
详细说明安全风险评估的剩余风险结论；
详细说明制造商在风险管理流程中采取的风险缓解措施；以及
提供与后续本指南中讨论的威胁模型、网络安全风险评估、SBOM（软件清单）和测试文档之间的可追溯性，以及其他相关的网络安全风险管理文档。
1. 威胁建模
威胁建模包括一个流程，用于在医疗设备系统中识别安全目标、风险和漏洞，然后定义措施，以防止、减轻或应对对医疗设备系统的威胁。 32 除了明确标识的内容外，关于安全风险管理计划和报告的更多详细信息，请参考AAMI TIR57《医疗设备安全——风险管理》和ANSI/AAMI SW96《医疗设备安全——设备制造商的安全风险管理》标准。 https://doi.org/10.2345/9781570208621.ch1 33 虽然安全架构很可能作为安全风险管理过程的一部分，但为了便于制造商向FDA提供关于医疗设备安全和有效性的详细信息，因此，出于对制造商建议提供的详细程度，我们将安全架构单独讨论。 它旨在优化系统、产品、网络、应用程序和连接的安全，当适当地和全面地应用时。 在安全风险管理方面，为了识别适合医疗设备系统的安全风险和控制措施，FDA建议进行威胁建模，以告知和支持风险分析活动。作为风险评估的一部分，FDA建议在设计过程中进行威胁建模，并涵盖所有医疗设备系统元素。 威胁模型应：
识别医疗设备系统的风险和缓解措施，并告知在网络安全风险评估中考虑的，包括缓解措施后的风险；
声明关于医疗器械系统或使用环境的任何假设（例如，医院网络本质上是敌对的，因此制造商应假设，攻击者控制着网络，并且能够修改、丢弃和重放数据包）；
捕捉供应链、制造、部署、与其他设备互操作、维护/更新活动以及报废活动中引入的网络安全风险，这些风险可能在传统的安全风险评估过程中被忽视。
FDA 建议，在上市前提交的文件应包含威胁建模文档，以证明医疗器械系统已如何分析，以识别可能影响安全性和有效性的潜在安全风险。制造商可以选择多种方法或组合来执行威胁建模。34 应为所选的方法提供理由。 关于如何提交威胁建模文档以供 FDA 审查的附加建议，请参见下文 V.B 节。 威胁建模活动可以在设计审查期间进行和/或审查。FDA 建议，威胁建模文档应包含制造商执行的威胁建模活动的信息，以便全面评估设备及其在设备运行的系统中，以确保设备的安全性。
2. 网络安全风险评估
作为安全风险管理的一部分，应将安全风险和控制措施作为网络安全风险评估的一部分，评估剩余风险。有效的安全风险评估需要考虑到网络安全相关的故障可能是有意或无意的。
因此，网络安全风险难以预测，这意味着无法根据历史数据或建模（也称为“概率方法”）来评估：
34 《MDIC/MITRE 医疗设备威胁建模指南》是一份教育资源，讨论了威胁建模过程、不同的威胁建模技术，并提供了虚构的医疗设备示例。
并量化事件发生的可能性。这种非概率方法不是在 ISO 14971 下进行的安全风险管理的基本方法，进一步强调了为什么安全和网络安全风险管理是不同的但相关的过程。相反，安全风险评估过程侧重于可利用性，即在设备和/或系统中存在的漏洞的可利用性。FDA 建议制造商根据设备和其所运行的系统所带来的风险水平来评估已识别的风险。
关于安全风险评估中的可利用性评估的更多讨论，请参见 FDA 的上市后网络安全指导。
上市前的网络安全风险的可利用性评估可能与上市后发现的漏洞的可利用性评估不同。在这种情况下，上市前的可利用性评估可能假设最坏情况，并实施适当的控制措施，或者为整个 TPLC 以及如何控制风险提供合理的可利用性评估的理由。
网络安全风险的接受标准应仔细考虑医疗设备系统的 TPLC，因为一旦设备上市，可能更难以解决网络安全问题。如前所述，在第 IV.B 和第 V.A 节中讨论的，已知的漏洞应被视为合理可预见的风险。在网络安全测试期间识别的漏洞的网络安全风险评估也应考虑设备的 TPLC，因为漏洞的可利用性很可能随着设备的生命周期而增加。例如，如果渗透测试人员能够利用漏洞，则该漏洞的可利用性很可能随着设备的生命周期而增加。此外，CISA 已知的利用漏洞目录中识别的漏洞应从设备中消除，因为这些漏洞已被利用，并且会使医疗设备系统和用户面临风险。
FDA 建议，在上市前提交的网络安全风险评估应涵盖来自威胁模型的已识别的风险和控制措施。用于在缓解前后对风险进行评分的方法，以及相关的接受标准，以及将网络安全风险转移到安全风险评估过程的方法，也应作为上市前提交的一部分提供。
3. 互操作性考虑
互操作性是评估端到端医疗设备系统的网络安全的重要考虑因素。正如 FDA 的《设计考虑和互操作医疗设备预上市提交建议》中（以下简称“互操作性指南”）所指出的，互操作的医疗设备能够通过电子接口与其他医疗或非医疗产品、系统或设备进行信息交换和使用。
作为医疗设备系统的一部分，设备可能需要考虑与互操作功能相关的网络安全问题，包括但不限于与以下接口的交互：
其他医疗器械和配件；
“其他功能”，如在 FDA 的指南“多功能产品”中定义
政策和注意事项；
医疗基础设施（例如，网络、电子病历、医学影像系统）；
通用计算平台。
虽然网络安全控制可能会增加接口的复杂性，以实现互操作性，但当这些控制措施得到正确实施时，它们可以帮助确保这些功能保持安全有效。网络安全控制应被用作一种手段，以安全有效地交换和使用信息。此外，网络安全控制不应被用于阻止用户访问其设备数据。 当使用通用技术和通信协议来实现互操作性时（例如，蓝牙、蓝牙低功耗、网络协议），设备制造商应评估在这些通信协议下是否需要添加额外的安全控制，以确保设备的安全性（例如，在蓝牙低功耗协议或相关技术存在漏洞的情况下，添加额外的安全控制以保护）。 除了互操作性指南中的建议外，制造商还应考虑与互操作性相关的适当网络安全风险和控制措施，并按照本指南的建议记录这些考虑。
4. 第三方软件组件
如 FDA 的《医疗器械中“标准软件”的使用指南》所述， 医疗器械通常包含第三方软件组件，包括标准软件和开源软件。35 当这些组件被整合时，这些软件组件的安全风险应成为整体医疗器械系统风险管理流程和文档中的一个重要因素。
作为证明符合 ISO 13485 第 7.3 子条款的设计和开发要求，以及支持供应链风险管理流程，所有软件，包括由设备制造商（“专有软件”）开发或从第三方获得的软件，都应进行网络安全风险评估。设备制造商应记录所有设备软件组件，并解决或以其他方式减轻与这些软件组件相关的风险。
此外，根据 ISO 13485 第 7.4 子条款，制造商必须建立流程和控制措施，以确保其供应商符合制造商的要求。这些信息应记录在符合 ISO 13485 第 7.3.10 子条款要求的“设计和开发文件”和符合 ISO 13485 第 4.2.3 子条款要求的“医疗器械文件”中。这些文件证明了设备的整体符合质量管理体系要求（QMSR），以及第三方组件符合设备所规定的规格。包括对第三方软件可能存在的或被引入的网络安全风险的分析和考虑的安全风险评估。
35 本指南中“组件”的用法与 21 CFR 820.3 的定义一致。 通过软件供应链，可以证明制造商已充分确保并记录了这些合规性。 软件会随着时间的推移进行更新，以提供额外的功能、解决安全问题，以及进行其他维护。这些更改可能会引入新的考虑或风险，这些需要作为风险管理的一部分进行考虑。因此，设备制造商应在整个设备生命周期中，作为配置管理的一部分，建立和维护设备源代码（即软件的原始“副本”）的控制。36 这可以通过多种方法来实现，例如源代码托管或源代码备份。37
由于许可限制、供应商协议条款或其他原因，制造商可能无法控制源代码。虽然在上市前提交中不需要提供源代码，但制造商应包括计划，说明如果支持终止或在上市前提交中出现其他软件问题，如何更新或替换第三方软件组件。设备制造商还应向用户提供任何他们可能需要的设备标签信息，以便他们可以管理与软件组件相关的风险，包括已知的漏洞、配置规范和其他相关的安全和风险
SBOM（软件清单）有助于促进风险管理流程，通过提供一种机制来识别可能因软件组件中的漏洞而受到影响的设备及其运行系统，无论是在软件作为组件被选择时（开发阶段），还是在产品生命周期的其他阶段，包括产品上市后。38 由于漏洞管理是设备安全风险管理流程的关键组成部分，因此SBOM或具有等效功能的机制应作为设备的配置管理的一部分，并定期更新以反映市场上设备的软件变更，并应支持相关文档，例如详述在子条款 36 中。 虽然一些供应商可能不会提供源代码，但制造商可以考虑将获取源代码纳入其采购控制，以便在购买的软件在供应商的预计支持或医疗设备的支持或生命周期结束之前提前结束时，获得源代码。 37 源代码托管涉及将相关软件的源代码（以及相关技术组件和文档）的副本存放在独立的第三方（“托管代理”）处。 源代码备份涉及存储（并在需要时更新）源代码的副本。 38 欲了解更多信息，请参阅美国商务部国家电信和信息管理局的软件透明度多方参与流程，该流程可在以下网站上找到：NTIA。 软件组件透明度。 7.3.10（设计和开发文件）和 ISO 4.2.3（医疗设备文件）
13485。为了协助 FDA 评估设备风险及其对安全性和有效性的影响（与网络安全相关），FDA 建议在上市前提交中包含
按照以下要求提供软件清单（SBOM）文档。对于医疗设备，必须提供软件清单（见《药品及医疗器械法》第524B(b)(3)条以及本指南的第VII.C.3条）。软件清单还可以作为一种重要的工具，帮助用户了解潜在风险，并在后续的第VI节中，关于标签的说明中体现。 (b) 支持软件清单的文档 美国食品药品监督管理局（FDA）的指南文件《医疗器械中使用离线软件》描述了制造商在无法完全控制软件生命周期的软件组件的预上市提交中应提供的信息。除了该指南中推荐的信息外，制造商还应提供符合最小元素的机器可读软件清单（也称为“基本属性”），这些最小元素是在2021年10月美国国家电信与信息管理局（NTIA）的《多方参与者软件组件透明度流程》文件《构建软件组件透明度：建立通用软件清单（SBOM）》中确定的。 除了NTIA确定的最小元素外，对于软件清单中包含的每个软件组件，制造商应在预上市提交中包含：
软件组件制造商提供的通过监控和维护提供的软件支持级别（例如，软件正在积极维护、不再维护、已放弃）；以及
软件组件的终结支持日期。
在提供时，制造商可以选择将这些额外元素作为 SBOM的一部分提供，或者单独提供，例如作为附件。 鼓励采用行业认可的 SBOM 格式。 如果制造商无法向 FDA 提供 SBOM 信息，制造商应提供理由，说明为什么该信息不能包含在市场准入前提交中。 作为市场准入前提交的一部分，制造商还应识别与设备和软件组件相关的所有已知漏洞，包括 CISA 已知的利用漏洞目录中识别的漏洞。 对于每个已知的漏洞，制造商应描述如何发现这些漏洞，以证明评估方法是否足够可靠。 对于具有已知漏洞的组件，设备制造商应在市场准入前提交中提供：
对已知所有漏洞（包括设备和系统影响）进行安全和安全风险评估；
详细说明可用于应对该漏洞的安全和保障风险控制措施。如果风险控制措施包括补偿性控制，则应以适当的详细程度进行描述。
欲了解有关专有和第三方组件的更多信息和讨论，请参阅下方的第 V.B.2 节，安全架构视图。
5. 未解决异常的安全评估
FDA 的《上市前软件指南》建议，设备制造商在提交时，应提供产品中存在的软件异常清单。对于每种异常，FDA 建议设备制造商评估该异常对设备安全性和有效性的影响，并参考《上市前软件指南》，以确定适用于此类设备的上市前提交所需的相关文档。 在开发或测试过程中发现的某些异常可能具有安全影响，并且也可能被视为漏洞。作为在 ISO 13485 第 7.1 条子条款下进行完整安全风险评估的一部分，对安全性和有效性影响的评估可能包括对异常的安全影响的评估。评估还应考虑任何现有的通用弱点枚举 (CWE) 类别。39 例如，临床用户在正常使用过程中可能会无意中发现先前未知的软件异常，此时异常的影响可能仅在特定情况下发生，并且可以从软件风险的角度进行评估，认为其可接受。相反，威胁可能会寻找此类异常，并找到利用它们的方法，以持续地表现出异常的影响，这与不包括安全考虑的异常评估相比，可能会对风险的可接受性产生重大影响。 应在上市前提交的文档中提供解决由此产生的具有安全影响的异常的标准和理由。
6. TPLC 安全风险管理
在设备整个生命周期内，网络安全风险可能会持续被发现。制造商应确保他们拥有适当的资源，以便在支持的设备生命周期内识别、评估和减轻已发现的网络安全漏洞。
作为使用 SPDF 的一部分，制造商应根据新信息更新其安全风险管理文档，例如，在开发过程中和设备发布后，发现新的威胁、漏洞、资产或不良影响时。
在设备整个生命周期内维护这些文档（例如，威胁建模、网络安全风险评估），可以快速识别设备发布后，一旦发现漏洞，以及在适当情况下，通过 ISO 13485 第 8.5 子条款中描述的纠正措施和预防措施，进行及时改进。
AAMI SW91《健康软件缺陷分类》附录 D 中，可以找到 39 个将 SW91 缺陷分类映射到 CWE 的示例。有关 CWE 类别的信息，请参阅 CWE 常见弱点枚举。
在设备的使用寿命内，FDA 建议，对于已投放的设备（例如，已上市或不再上市但仍在使用的设备），风险管理文档应考虑到风险管理方面的差异。例如，如果未自动应用于所有已投放的设备，则设备的不同软件配置很可能具有不同的风险状况。FDA 建议，为了确保患者风险得到准确评估，应评估所有已投放版本的任何不同影响。
关于是否需要根据市场后漏洞和一般市场后网络安全风险管理，以及新的预上市提交（例如，PMA、PMA 补充或 510(k)）或 21 CFR Part 806 报告的信息，请参阅《市场后网络安全指导》。
为了证明制造商流程的有效性，FDA 建议制造商跟踪和记录以下措施和指标 40，并在预上市提交和 PMA 年度报告（21 CFR 814.84）中提供 41，当可用时。选择定义 SPDF 的流程的适当措施和指标，对于确保设备设计符合 QMSR 的网络安全至关重要。至少，FDA 建议跟踪以下措施和指标，或提供等效信息：
已识别漏洞的更新或修复百分比（缺陷密度）；
从漏洞识别到更新或修复的时间；以及
从可用更新或补丁到在部署设备中完成实施的时间，具体取决于已知情况。
如果识别并解决多个漏洞，应提供上述指标的平均值。这些平均值可以根据数量或响应流程或程序变更，在多个时间框架内提供，以提高这些指标的效率。
B. 安全架构
制造商有责任识别其设备以及预期设备运行的系统中存在的网络安全风险，并实施适当的控制措施以减轻这些风险。这些风险可能包括由设备依赖于医院网络、云基础设施或“其他功能”（如 FDA 指南“多功能设备产品：政策和考虑”）而产生的风险。与系统架构一样，安全架构定义了系统及其与系统的所有端到端连接。安全架构定义过程包括对高层定义以及对 40 提供措施和指标仅为示例；也可以考虑并报告其他措施和指标。 ISO 13485 第 7.3.1 条要求制造商记录设计和开发程序。在第 7.3.2 条下，制造商必须建立并维护描述或引用设计和开发活动的计划，并定义实施责任。这些计划应随着设计和开发的进展而维护和更新（第 7.3.2 条）。在第 7.3.3 条下，制造商必须确定并维护与产品要求相关的输入，以确保与设备相关的设计要求是适当的，并且能够满足设备的使用目的。在第 7.3.4 条下，设计和开发输出应适合与设计和开发输入进行验证，并且应保留记录。第 7.3.4 条还规定，设计和开发输出应包含或引用产品验收标准，并确保对于其安全和正确使用所必需的设计输出已识别。 FDA 建议这些计划和程序应包括设备和系统安全架构的设计过程、设计要求和验收标准，以便全面解决设备和设备运行的系统中的网络安全问题。FDA 建议所有医疗设备应提供并实施上述第 IV 节中的安全目标，但认识到实现这些目标可能会有所不同。 FDA 建议在预上市提交中包含安全架构的文档。在预上市提交中提供安全架构信息的目标是向 FDA 提供医疗设备系统在接口、互连和与外部实体交互方面的安全背景和信任边界。这些元素的详细信息有助于识别可能在设备系统内部或通过设备系统发生的事件。这些信息有助于充分理解系统，以便 FDA 可以评估该架构本身与安全和有效性之间的关系。 制造商应分析整个系统，以了解设备预期运行的完整环境和上下文。安全架构应包括对系统层面的风险的考虑，包括但不限于与供应链相关的风险（例如，确保设备免受恶意软件或从上游依赖关系（如第三方软件）
1. 安全控制措施的实施
FDA 认为，设备应对网络安全风险的方式，以及设备在暴露于网络安全威胁时的响应方式，是设备设计的组成部分。
有效的网络安全依赖于将安全“融入”到设备中，而不是在设备设计完成后“临时添加”。 FDA 建议，设备制造商的设计流程应包括针对网络安全控制的设计和开发输入。44
FDA 建议，这些程序应包括对设备内置的安全功能的设计要求和验收标准，以便全面解决设备和设备所运行的系统中的网络安全问题。
安全控制使制造商能够实现《第四部分》中概述的安全目标，并且是 SPDF 的 integral part。 FDA 建议，一个充分的安全控制应包括，但不限于以下类别：
身份验证;
授权；
加密技术;
代码、数据和执行的完整性
保密性
事件检测和记录
弹性与恢复能力;
可更新性和补丁功能。
对于上述每一种安全控制类别，具体控制建议和实施指导，以避免常见的陷阱，已详细说明在附录 1 中。
安全控制的实施应在整个系统架构中使用，并基于与相关连接和设备相关的风险评估。如果没有在医疗设备系统中（包括管理、技术和运营控制）实施充分的安全控制，则无法保证安全性和有效性。此外，所选安全控制的设计缺陷或这些控制的实施，可能会对设备证明或维持其安全性和有效性产生重大影响。
44 在生成这些设计输入时，可以使用以下框架，包括 OWASP 的“以安全为设计的原则”、AAMI/ISA-62443-4-1，以及针对医疗设备的特定框架，如“连接医疗设备的希波克拉底誓言”、“医疗设备软件安全建筑规范”和 IEC 81001-5-1。
对于 OWASP “以安全为设计的原则”的具体实施，请参阅《医疗设备和健康信息技术联合安全计划》第 2 版 (JSP2)。 FDA 建议，为了证明安全性和有效性，应在市场准入前提交中提供上述每种类别的要求和验收标准。制造商应在市场准入前提交中提交文件，以证明上述类别（以及附录 1 中提供的进一步详细说明）的安全控制已（1）实施，并且（2）已进行测试，以验证其有效实施。有关网络安全测试的更多信息，请参阅下文第 V.C 节。
制造商可以在市场准入前提交中包含与附录 1 中描述的类似或补充的安全控制的证明。如果使用本文档中未描述的替代控制，制造商应提供特定设计特征和安全控制与相关风险的文档，以证明它们提供适当的安全性和有效性水平。随着网络安全设计和开发活动在开发阶段早期建立，FDA 建议设备制造商利用 FDA 的 Q 提交流程，与该机构就整个设备生命周期中的网络安全风险管理进行设计考虑。45 关于设计和开发方面的市场准入前文件建议的更多信息，请参阅下文“安全架构视图”部分。
2. 安全架构视图
除了设计和开发要求外，ISO 13485 第 8.5 条还要求制造商建立并维护改进程序，包括纠正措施和预防措施。根据第 8.4 条的要求，对质量数据进行分析以识别现有和潜在的质量问题，用于确定根据第 8.5 条所需的改进。FDA 建议制造商在设计、开发和维护医疗器械系统的过程中，开发和维护安全架构视图文档。如果确定了纠正和预防措施，这些视图可以用于识别受影响的功能以及解决风险的解决方案。 FDA 建议，在上市前提交的文件应包括本部分中描述的安全架构视图。这些安全架构视图可以帮助在上市前提交的文件中证明医疗器械系统的安全性，通过说明如何将用于解决网络安全风险的控制措施应用于医疗器械系统。 安全架构可以表达在不同的抽象级别和不同的范围内或视图中。提交中提供的安全架构视图的数量和范围取决于通过对医疗器械系统的威胁建模和风险评估识别的攻击面。因此，这些视图可以有效地向 FDA 提供威胁建模信息，并自然地与医疗器械的网络安全风险相关的文档进行扩展。 提交：“Q-Submission 计划” 全局系统视图；
多患者风险视图
可更新性/补丁功能视图
安全使用案例
在提交预上市文件时，应记录这些观点，包括图表和解释性文字。这些图表和解释性文字应包含足够的信息，以便理解医疗器械系统内资产如何在相关的实施细节中整体运作。对于安全架构视图，制造商应在确定预上市提交中应包含的详细程度时，遵循附录 2 中概述的建议。
这些安全架构视图应：
识别与安全相关的医疗器械系统元素及其接口；
定义医疗器械系统的安全上下文、领域、边界、关键用户角色和外部接口；
使架构与（a）医疗器械系统的安全目标和要求，以及（b）安全设计特征相对应，以应对已识别的威胁；
建立架构元素与用户和医疗器械系统安全要求的可追溯性。这种可追溯性应贯穿于整个网络安全风险管理文档。
如果某种视图能够充分捕捉上述其他视图中的风险，我们不期望制造商重复提供文档。同样，如果威胁建模文档能够充分捕捉该视图，我们也不期望制造商重复提供文档。 此外，如果上述任何一种视图不适用，制造商应提供解释，说明为什么该视图未包含在预上市提交中。 在预上市提交中，这些安全视图的范围应根据设备及其潜在的网络和/或云安全风险来确定。例如，具有网络和/或云访问的医疗设备系统，应包含更多的安全用例。 (a) 全局系统视图 全局系统视图应描述整个医疗设备系统，包括设备本身以及所有内部和外部连接。对于互连和联网的设备，该视图应识别所有互连元素，包括任何软件更新基础设施、医疗机构网络影响、中间连接或设备、云连接以及患者家庭网络影响。 根据医疗设备系统的复杂程度，可能无法在单个全局系统视图中包含所有数据流的具体信息。可以提供其他视图，这些视图详细说明了根据附录 2 推荐的通信具体信息，并且不需要在以下详细说明的其他类型的视图中重复。 (b) 多患者危害视图 当设备能够连接（有线或无线）到另一个医疗或非医疗产品、网络或互联网时，存在多个设备可能同时受到攻击的可能性。由于这种连接，如果一个设备受到攻击，或者如果一个非设备功能（即不属于《FD&C 法》第 201(h) 条规定的任何功能） 对设备功能产生影响，该设备可能会通过安全风险对患者造成危害。这可能会改变设备的用途。例如，一个非设备功能可以被黑客攻击，以执行设备功能，最终危害患者。 根据设备风险和使用环境，多个设备受到攻击可能会对多个患者产生严重的后果，无论是通过影响设备本身和/或医疗机构的运营（例如，所有多参数床边监视器同时重启，导致所有监视器连接到同一网络不再监测患者生命体征，且工作人员无法监测所有患者生命体征）。 FDA 建议制造商说明其设备及其在多患者危害视图中防御和/或应对可能对多个患者造成危害的攻击。该视图应包含附录 2 中推荐的信息。一旦识别出这些风险，由于风险的性质不同，也可能需要在随附的网络安全风险评估中进行不同的评估。 (c)
C. 网络安全测试
与产品开发的其他领域一样，测试用于证明设计和开发活动的有效性。虽然软件开发和网络安全是密切相关的学科，但网络安全控制需要进行超出标准软件验证和验证活动之外的测试，以证明在适当的安全背景下，控制措施的有效性，从而证明该设备具有合理的安全性和有效性。
根据ISO 13485第7.3.6条，制造商必须建立和维护验证设备设计的程序。此类验证应确认设计输出符合设计输入要求。根据ISO 13485第7.3.7条，制造商必须建立和维护验证其设备设计的程序。FDA建议，验证和验证应包括制造商对医疗设备系统网络安全的充分测试，制造商通过此类测试验证和验证其输入和输出，如适用。 安全测试文档以及相关的报告或评估应在上市前提交。FDA建议，在提交中考虑以下类型的测试（以及其他）：
安全要求；
制造商应提供证据，证明每个设计输入要求已成功实施。
制造商应提供边界分析和其边界假设的理由。
威胁缓解；
制造商应提供详细信息和证据，证明根据全球系统、多患者危害、可更新性和可修补性以及安全用例视图提供的威胁模型，有效实施风险控制措施的测试。
制造商应确保每项网络安全风险控制措施的充分性。
（例如，在执行指定安全策略方面的有效性、在最大流量条件下性能、稳定性、可靠性等，根据需要）。
漏洞测试（参考 ANSI/ISA 62443-4-1 的描述）；
制造商应提供以下测试和分析的详细信息和证据：
滥用或误操作情况，包括畸形和意外输入。
坚固性
模糊测试。
攻击面分析；
漏洞连鎖
已知的漏洞扫描的封闭式测试
二进制可执行文件的软件组成分析；
包括静态和动态代码分析，以及对以下资质的测试：
“硬编码”、“默认设置”、“容易猜测”、“容易被攻破”。
穿透测试
测试应通过针对产品中发现和利用安全漏洞的测试，识别和评估与安全相关的潜在问题。
穿透测试报告应提供，并包含以下内容：
检验人员的独立性和专业技术能力；
测试范围；
测试时长
采用的测试方法；
测试结果、发现和观察。
设备制造商应在测试报告中注明测试由谁执行（例如，独立的内部测试人员、外部测试人员），以及负责测试设备的测试人员与负责设计设备的开发人员之间的独立性级别。在某些情况下，可能需要使用第三方来确保这两个群体之间具有适当的独立性，从而妥善处理在测试过程中发现的漏洞或其他问题。对于任何第三方测试报告，制造商应提供原始第三方报告。对于所有测试，制造商应提供其评估结果，包括不实施或推迟任何结果的理由。
如前文 V.A.2 和 V.A.3 节所述，在测试过程中发现的漏洞和异常应作为安全风险管理过程的一部分进行评估，以评估其安全影响。在非安全软件测试中，发现缺陷的效益分析可能得出结论，该异常不需要修复，因为其对医疗设备系统功能的影响可能很小或不太可能。相反，在安全测试中，异常的可利用性可能需要采取措施来减轻其危害，因为它可以导致更大的、不同类型的危害。
47 对于任何使用的测试工具或软件，提供的详细信息可能包括，但不限于，工具的名称、适用的版本信息以及用于的工具的任何设置或配置选项。
对于将在未来发布中解决的问题（即，由于当前风险被评估为可接受，因此推迟软件发布以进行修复），预上市提交应包含有关这些发布的信息。此类计划应包括未来软件发布将解决的漏洞、发布的时间表、是否将在中间发布设备接收这些更新以及更新需要多长时间才能到达设备。
有许多权威资源可以概述安全测试，这些资源可以部分满足上述测试。48
FDA 建议，网络安全测试应贯穿整个 SPDF。在开发早期进行网络安全测试，可以确保在影响发布时间表之前解决安全问题，并可以避免重新设计或重新工程设备。在发布后，应定期（与风险相称，例如每年一次）进行网络安全测试，以确保潜在的漏洞能够被识别并解决，然后再被利用。
VI. 网络安全透明度
网络安全透明度对于确保设备和系统的安全有效使用和集成至关重要。49 这可以通过设备标签以及制造商建立漏洞管理计划来实现。然而，不同类型的用户（例如制造商、服务人员、患者）在承担缓解角色方面的能力不同，并且确保持续网络安全的措施应根据用户类型而定。生产网络安全设备的制造商应考虑本节的建议，即“设计、开发和维护流程和程序，以提供合理的保证，确保设备及其相关系统具有网络安全。”（《药品、食物和化妆品法》第 524 节 (b)(2) 条；参见第七节 C.2）。
A. 适用于具有
网络安全风险
FDA 通过多种方式监管医疗器械的标签。例如，根据《FD&C法》第502(f)条，标签必须包含充分的使用说明。根据《FD&C法》第502(a)(1)条，如果医疗器械的标签存在虚假或误导性信息，则该器械将被认定为不符合规定。 48 以下标准可能部分满足安全测试的建议：ANSI/UL 2900 软件 用于可连接网络的产品的网络安全，ANSI/ISA 62443-4-1 工业自动化和控制系统，第4-1部分：产品安全开发生命周期要求，此外还包括 IEC 81001-5-1 健康软件和健康信息技术系统的安全、有效性和安全性 - 第5-1部分：安全性 - 产品生命周期的活动。 此外，其他标准也可能完全或部分满足本部分概述的测试建议。 49 用户通常通过最终用户或在更大的风险管理框架（如NIST CSF）中管理医疗器械的安全性风险。 对于存在网络安全风险的设备，向用户提供相关安全信息可能是符合标签要求的一种有效方式。FDA 认为，通过标签向用户提供安全信息，是设计和开发活动的重要组成部分，有助于减轻网络安全风险，并确保医疗器械的持续安全和有效性。 因此，在起草用于预先提交的标签时，制造商应考虑所有适用的标签要求，以及通过标签向用户提供安全信息可能是一种有效的方式，以管理网络安全风险，并确保医疗器械的安全和有效使用。 任何传递给用户的风险都应详细说明，并考虑在可用性测试（例如，人机工程学测试）期间作为任务纳入，以确保用户能够采取适当的行动来管理这些风险。 以下建议旨在向用户传达可能有助于他们维持自身安全态势的相关设备安全信息，从而有助于确保医疗器械在整个生命周期内保持安全和有效。 详细程度、特定类型的信息（例如，操作手册、安全实施指南）在标签中的确切位置，以及提供这些信息的方法，应考虑到信息的预期用户。 管理网络安全风险的说明应易于理解，这可能包括对患者或护理人员等具有有限技术知识的人群。 制造商可能希望采用方法，以确保某些信息仅对用户可见，如果
包含与推荐的针对特定使用环境（例如：反恶意软件、防火墙使用、密码要求）的网络安全控制措施相关的设备说明和产品规格。
详细的图表，方便用户实施推荐的网络安全控制措施。
列出预期接收和/或发送数据的网络端口和其他接口。
此列表应包括端口功能的描述，并指示端口是入站、出站还是双向，以及已批准的目的端点。
- 针对用户，提供明确的指导，说明设备所需的辅助基础设施，以便设备能够按照预期的方式运行（例如，最低的网络要求、支持的
利用信息技术网络中的医疗设备进行风险管理——涵盖 IEC 80001-2-2 中规定的安全能力建立标准的相关部分；以及 IEC TR 80001-2-9 的应用，涵盖使用安全保证案例来证明对 IEC/TR 80001-2-2 安全能力的信心，以便提供符合这些标准的进一步标签信息。
（包括加密接口）。在适当的情况下，这些指导应包括技术说明，以实现安全的网络部署和维护，以及用户在检测到网络安全漏洞或事件时的应对措施说明。
- 按照第五部分 A.4 的规定，或采用行业认可的格式，生成 SBOM（软件清单），以便有效地管理其资产，了解已识别的漏洞对医疗器械系统的潜在影响，并采取措施以确保该设备的安全性及有效性。制造商应提供或提供
持续向用户提供 SBOM 信息。如果使用在线门户，制造商应确保用户拥有包含准确信息的最新链接。 SBOM 应采用可供机器读取的格式。
描述用户获取具有版本标识的、由制造商授权的软件和固件的系统性流程，包括描述用户如何了解软件何时可用。
描述设备如何响应检测到异常情况（即安全事件）的设计。这应包括向用户发出通知以及记录相关信息。安全事件类型可能包括配置更改、网络异常、登录尝试或异常流量（例如，向未知实体发送请求）。
对保护关键功能的设备功能的高层描述（例如，备份模式、禁用端口/通信）。
描述备份和恢复功能以及恢复经过身份验证的配置的程序。
描述经过身份验证的授权用户恢复设备配置的方法。
描述已出厂的设备的安全配置、用户可配置更改的说明以及识别可能增加医疗设备系统安全风险的用户可配置更改。安全配置可能包括终端保护，如反恶意软件、防火墙/防火墙规则、允许列表、拒绝列表、安全事件参数、日志参数以及物理安全检测，以及凭据重置等。
在适当的用途环境中，描述如何捕获证据，包括但不限于与安全事件相关的任何日志文件。
日志文件描述应包括日志文件的位置、存储、回收、归档方式，以及如何被自动分析软件（例如，入侵检测系统 (IDS) 或安全信息和事件管理 (SIEM)）所使用。
如果已知或预计，关于医疗器械（包括组件）的安全、支持结束和生命周期结束的信息。在支持结束时，制造商可能无法合理地提供安全补丁或软件更新。如果设备在支持结束后继续使用，制造商应制定并提前告知的风险转移流程，并强调，对于最终用户的网络安全风险可能会随着时间的推移而增加。
关于安全处置设备的信息，包括清除敏感、机密和专有数据和软件。
符合版本控制的《医疗器械安全声明》（MDS2） 以及根据《医疗器械和健康信息技术联合安全计划》第2版（JSP2）规定的客户安全文档，可以解决上述许多建议。
B. 网络安全管理计划
认识到，随着设备在整个生命周期（TPLC）中技术的演变，网络安全风险也在不断演变， 因此，FDA建议制造商制定一项计划，以在符合ISO 13485第8.4和8.5条款以及21 CFR第806部分的要求下，发布设备后，识别并向相关方沟通已识别的漏洞。该计划还可以支持QMSR和ISO 13485中描述的安全风险管理流程，这些流程已作为参考纳入QMSR。 FDA建议制造商将他们的网络安全管理计划作为其上市前提交的一部分，以便FDA可以评估制造商是否已充分解决如何确保设备在获得市场准入后，保持其安全性和有效性。对于网络设备，要求“制定一项计划，以在合理的时间内，监测、识别并解决，如果需要，市场后出现的网络安全漏洞和利用，包括协调的漏洞披露和相关程序”（参见《美国食品药品监督管理局法案》第524B(b)(1)条以及本指南的第VII.C.1条）。 网络安全管理计划应包括以下要素：
责任人员
监控和识别漏洞的来源、方法和频率（例如：研究人员、美国国家标准与技术研究院（NIST）的国家漏洞数据库（NIST NVD）、第三方软件制造商）
识别并解决 CISA 已知的利用漏洞
目录；
定期安全测试；
开发和发布补丁的时间表；
更新流程；
更新能力（即，更新可以向设备传递的速度）
描述其协调的漏洞披露流程；
制造商打算如何向客户沟通即将推出的修复、补丁和更新的描述。
关于协调的漏洞披露计划的更多建议，请参见 FDA 的“上市后网络安全指导”。
VII. 网络设备
本部分标识了 FDA 认为通常需要在《FD&C法》第 524B 条规定的义务下，对网络设备提供必要的信息。本部分提供针对网络设备的具体建议。生产网络设备的制造商应也考虑本指南中的建议，以满足《FD&C法》第 524B 条规定的义务。
A. 哪些机构需要遵守《FD&C法》第 524B 条 《FD&C法》第 524B(a) 条规定，包括制造商的任何个人，60 如果提交符合“网络设备”定义的设备（如《FD&C法》第 524B(c) 条所定义）的预上市申请或提交，无论采用 510(k)、54 PMA、55 PDP、De Novo 或 HDE 途径，都必须提供 FDA 要求的任何信息，以确保该网络设备符合《FD&C法》第 524B(b) 条规定的网络安全要求。
B. 适用《FD&C法》第 524B 条的设备 《FD&C法》第 524B 条及其要求适用于“网络设备”。《FD&C法》第 524B(c) 条将“网络设备”定义为符合以下所有标准的设备：（1）包含由赞助方验证、安装或授权的软件，作为设备或在设备中；（2）具有连接互联网的能力；以及（3）包含任何由赞助方验证、安装或授权的任何技术特征，这些特征可能容易受到网络安全威胁。
在部分参考 NIST 认可的“软件”术语的定义，FDA 认为“网络设备”包括包含软件的设备，包括固件或可编程逻辑的软件。61 FDA 同样将“连接互联网的能力”包括在内，即设备能够通过任何方式（包括设备和使用环境的威胁面评估中识别的任何点）有意或无意地连接互联网。 已经充分证明，如果设备具有连接互联网的能力，则无论设备赞助方是否有意连接互联网，该设备都可能连接互联网。62
与 WannaCry 勒索软件（更新 I）相关。 FDA 认为，如果设备包含以下任何一项功能，则具有连接互联网的能力。以下列表仅为示例，并非详尽无遗：
与网络、服务器或云服务提供商的连接；
射频通信（例如，Wi-Fi、蜂窝网络、蓝牙、蓝牙低功耗）
能量);
磁性感应通信；60
能够连接互联网的硬件连接器（例如，USB、以太网、串行端口）。61
C. 满足要求的文档建议
《食品、药品和化妆品法》第 524B 条 对于适用的预上市提交类型，制造商必须提供符合《食品、药品和化妆品法》第 524B 条要求的文档。关于支持每个要求的文档建议，将在以下部分进行讨论。
- 计划和程序 (第 524B(b)(1) 条) 《食品、药品和化妆品法》第 524B(b)(1) 条要求生产网络设备制造商，在预上市提交中向 FDA 提交： “一项计划，用于监测、识别和解决，在合理的时间内，对上市后的网络安全漏洞和利用，包括协调的漏洞披露和相关程序”。我们建议该计划应包含符合《第六部分 B》中描述的网络安全管理计划所建议的信息。特别是，该计划应涵盖以下内容：
首先，FDA 认为，根据《食品、药品和化妆品法》第 524B(b)(1) 条的要求，协调的漏洞披露 (CVD) 和相关程序可能包括：
- 与外部实体合作，公开已识别的漏洞和利用方法
（包括第三方软件供应商和研究人员）
制造商提供的网络设备中发现的漏洞和利用方法的披露；
制造商的程序，用于披露上述识别出的漏洞和利用方法。62
其次，根据《药品及化妆品法》第524B(b)(1)条规定的计划，还应描述开发和发布所需更新和补丁的时间表，并提供相应的理由：
《药品及化妆品法》第524B(b)(2)(A)条要求，生产商应向设备和相关系统提供针对已知的不良漏洞的更新和补丁63，并且这些更新和补丁应在合理且有充分理由的情况下定期发布。65
《药品及化妆品法》第524B(b)(2)(A)条中提到的“已知的不良漏洞”与
“关键漏洞，可能导致无法控制的风险” ，请参见第 524B(b)(2)(B) 条。 已知的不可接受的漏洞可能包括：无法导致无法控制的风险的漏洞；目前已知无法导致无法控制的风险的漏洞；或符合 FDA 的《上市后网络安全指导》中描述的，可能存在控制风险的漏洞。 为了解决这些漏洞，可能需要更新和/或修复软件，以保持软件的可维护性。 通常，软件应定期更新，以保持软件的可维护性。 关于与控制风险相关的漏洞的示例，请参见《上市后网络安全指导》。 针对此类漏洞的更新和修复，旨在降低无法控制的风险，因此不旨在降低对健康的影响或纠正《FD&C 法》的违反。 有关第 524B(b)(2)(B) 条的更多信息，请参见以下内容。
根据《FD&C 法》第 524B(b)(2)(B) 条，生产商必须向设备和相关系统提供更新和补丁，以尽快解决可能导致无法控制的风险的关键漏洞。
总体而言，这包括符合 FDA 《上市后网络安全指导》中描述的，可能导致无法控制的风险的漏洞。 关于与无法控制的风险相关的漏洞的示例，请参见《上市后网络安全指导》。
网络安全指导。 65 定期更新的理由通常应包含在网络安全管理计划中。 具体的设备，定期更新的周期可能会因多种因素而异。 影响周期长度的主要因素之一是风险。 例如，一个功能仅限于测量和报告患者体温的互联温度计，如果被利用，其潜在危害可能低于一个互联手术机器人，其潜在危害可能显著更高。 同时，即使是看似风险较低的设备，也可能被用于影响其他设备，从而在这些其他设备或更大的环境中被利用或中断时，造成显著的危害。 制造商应充分考虑其设备在所 intended 的环境（或环境）中的风险，并设计和实施提供合理网络安全保证的定期更新周期。
其次，我们建议制造商应预见并对这些计划（以及第七节 C.2 中讨论的流程和程序）进行适当的更新，67 随着新信息的出现，例如在产品生命周期的任何阶段，都可能发现新的风险、威胁、漏洞、资产或不良影响。 为支持这些努力，制造商还应创建或更新适当的文档（例如，威胁建模、网络安全风险评估），并在整个设备生命周期内维护这些文档。 这样可以使制造商在设备发布后能够快速识别漏洞的影响，并有助于满足《美国食品药品监督管理局》法案第 524B(b)(2)(A)-(B) 条的要求。
所需计划（以及第七节 C.2 中讨论的流程和程序），70 同样应，在适当的情况下，考虑到现场部署设备（例如，上市设备与不再上市但仍在使用的设备之间的差异）的网络安全管理方面的差异。 例如，如果未自动应用于所有现场部署的设备，则设备的不同软件配置可能会产生不同的风险。
应评估所有现场部署版本的不同影响，以确保准确评估患者风险。 2. 设计、开发和维护提供合理网络安全保证的流程和程序（第五节 B(b)(2)） 制造网络安全设备的制造商必须“设计、开发和维护提供合理保证，以确保该设备及其相关系统具有网络安全”的流程和程序。（《美国食品药品监督管理局》法案第五节 B(b)(2)）。《美国食品药品监督管理局》将相关系统包括但不限于制造商控制的元素，例如其他设备、按照《美国食品药品监督管理局》发布的《多功能设备产品：政策和考虑》中
D. 修改
如前所述，根据《食品、药品和化妆品法》第 524B 条的规定，适用于向 FDA 提交申请或提交材料的制造商，这些申请或材料符合以下任何途径的定义—— 510(k)、PMA、PDP、De Novo 或 HDE，用于符合“网络设备”定义的设备。 因此，如果制造商需要根据上述途径之一提交关于设备修改的申请或提交材料，则也需要遵守《食品、药品和化妆品法》第 524B 条的规定。71 遵循“最少负担”原则，72 我们建议制造商提供关于网络设备的信息，通常会因更改类型和这种更改是否影响设备网络安全而有所不同。 总体而言，我们建议制造商使用以下建议，以确定制造商在向 FDA 提交设备修改的预上市申请时，如何提供信息，以证明他们已满足《食品、药品和化妆品法》第 524B 条规定的新要求。
- 可能影响网络安全的更改 通常，可能影响网络安全并可能需要预上市提交的更改可能包括对身份验证或加密算法的更改、新的连接功能或更改软件更新过程/机制。对于此类更改，请参阅第 VII.C 节，其中列出了需要包含在每个预上市提交中的所需和推荐文件（参见《食品、药品和化妆品法》第 524B 条）。
- 不太可能影响网络安全的更改 通常，不太可能影响网络安全的更改可能包括材料更改、灭菌方法更改或在不更改架构/软件结构/连接的情况下更改算法。 对于此类更改，FDA 建议制造商提供以下信息，以满足《食品、药品和化妆品法》第 524B 条规定的预上市提交要求：
524B(b)(1)
如果此前未提供，制造商必须提供符合《食品、药品及化妆品法》第524B(b)(1)条规定的计划；我们建议该计划应包含上述第VII.C.1条所描述的信息。
如果之前已提供（参见 VII.C.1 节所述的）计划，则制造商应提供对先前提交的计划的引用，以及计划中任何变更的摘要。
受预先批准（PMA）要求的设备 - “PMA 补充决策流程” 规定：概念和原则。
524B(b)(2)
而不是完全按照所需或推荐的文档
第七部分 C.2，如上所述，制造商可以提供以下信息：
- 说明目前是否存在任何“可能导致无法控制的风险的关键漏洞”。73
- 说明自上次授权以来，该设备是否存在任何具有无法控制风险的漏洞，并已进行修复。如果是，制造商应按照美国食品药品监督管理局（FDA）发布的《上市后网络安全指导》的建议，描述修复过程。
524B(b)(3)
根据《食品、药品和化妆品法》第 524B(b)(3) 条，生产网络设备制造商必须提供 SBOM（软件清单），包括商业、开源和预装软件组件。为了协助制造商符合这一要求，我们建议，一个网络设备制造商应提供包含第 V.A.4.b 中推荐的信息的 SBOM。
一般来说，在进行网络安全审查时，FDA 旨在将重点放在对网络安全控制的修改或可能影响网络安全的修改上。然而，无论在预上市提交中提出的设备类型是什么，FDA 均会考虑已知的网络安全问题，这些问题适用于该设备，并在进行预上市审查以及确定设备是否具有合理的网络安全保障时，予以考虑。
E. 网络设备的安全保障
《食品、药品及化妆品法》第 3305(c) 条规定，第 524B 条“不得被解释为影响美国食品药品监督管理局（FDA）确保设备安全有效性的权威，这可能包括确保某些网络设备的网络安全……”。FDA 将这一规定解释为，一个“合理的网络安全保障”可以成为 FDA 确定设备安全性和有效性的组成部分。此外，确定设备具有合理的网络安全保障与各种预上市途径和授权相关，特别是 FDA 对 510(k)、PMA、PDP、De Novo 和 HDE 的审查。 鉴于过去几年市场上互联设备的快速增长（参见第 I 节），确保网络安全已成为 FDA 保护公众健康并提供设备安全性和有效性的合理保障的关键。
在评估 510(k) 提交时，FDA 会考虑使用环境的变化（例如，与该设备交互或运行的技术，以及任何新的风险）。
项目：在预先通知 [510(k)] 中评估实质性等效性。 附录 1. 安全控制类别及其相关建议
以下部分提供了对第五节 5.B.1 中介绍的每个安全控制类别的详细描述，以及避免常见问题的安全控制和实施的具体建议。
身份验证 通常，身份验证控制分为两种类型：信息和实体。一个安全配置的系统能够证明两者都存在。 信息身份验证：当设备和其运行的系统能够证明信息来自已知且可信的来源，并且在原始来源和身份验证点之间，信息未被篡改时，信息身份验证存在。重要的是要注意，虽然身份验证意味着数据是准确的，并且已受到未经授权用户修改（即，完整性）的保护，但完整性本身并不能保证数据是真实的，并且来自可信来源。因此，为了本指南的目的，身份验证被讨论为在完整性的基础上，更大的安全目标。 实体身份验证：当设备和其运行的系统能够证明从其发送和/或接收信息的目标端（无论硬件和/或软件）的身份，或在该目标端授权的用户/操作员时，实体身份验证存在。 在安全系统中，设备应验证来自外部实体的信息的真实性，以及验证自身生成的信息的真实性。一个适当考虑身份验证的医疗设备系统可以评估和确保：
静态数据（存储在设备中）
传输中的信息（已传输）
沟通端点的身份验证，无论这些端点是软件还是硬件；
软件二进制文件；
正在运行的软件的执行状态完整性；以及
以及任何其他适当的医疗设备系统部分，制造商的威胁模型和/或风险分析表明需要使用它们。
从技术层面来看，设备的身份验证方案强度取决于未经授权的方需要花费的时间（包括时间），以识别身份验证方案的分解。例如，这可能包括确定从可以用于绕过身份验证方案并访问医疗设备系统的加密函数中正确“输出”所需的时间和资源。 在选择身份验证方案时，制造商应考虑以下不同类型的方案的通用特征：
基于非加密接口、握手和/或协议的隐式身份验证方案，本质上是弱的，因为一旦被逆向工程，未经授权的用户可以轻松地模拟正确的行为，并看起来像是被授权。
加密身份验证协议通常更强大，但需要仔细的设计选择和实施实践才能充分发挥其作用。
此外，这些方案仍然受到与方案交互所需的加密密钥的保密性，以及持有或利用这些密钥的设备的完整性的限制。有关密码学的更多信息，请参见以下附录 1，子部分 C。因此，对于可能导致危害的非认证行为，设备应实施额外的、非标准的意图信号，例如短暂的开关，以授权命令/会话。 以下列表提供了认证方案的实施建议：
使用强大的加密认证，其中认证功能位于设备上，用于认证人员、消息、命令更新，以及适用的所有其他通信路径。在可能的情况下，应考虑并采用硬件安全解决方案；
根据相关的风险，以适当的频率对外部连接进行认证。
例如，如果设备连接到位于异地的主机，则设备和主机应相互认证每个会话，并限制会话的持续时间，即使连接是通过一个或多个已知的安全通道启动的；
使用适当的用户认证（例如，多因素认证，以允许系统管理员、服务技术人员或维护人员等，根据需要，访问受保护的设备）；
在允许软件或固件更新之前，需要进行认证和授权，包括影响操作系统、应用程序和反恶意软件功能的更新；
加强密码保护。不要使用硬编码、默认、容易猜测或容易被攻破的密码（例如，每个设备使用相同的密码；无法更改；默认状态下仍然存在；难以更改，并且/或容易被公开披露）。
在关键通信中，例如可能有害的指令，实施防重放措施。可以通过多种方法来实现，包括使用密码学nonce（仅在密码学通信中一次使用的任意数字）；
提供验证设备产生信息的真实性的机制，例如远程监护数据。 这对于那些如果被伪造或以其他方式修改，可能会导致患者伤害的数据尤其重要，例如：
- 临床医生或监护设备与植入式设备（如起搏器、除颤器或神经刺激器）之间的连接；
- 连续血糖监测系统与自动胰岛素泵之间的连接。
- 不要依赖循环冗余校验 (CRC) 作为安全控制。CRC 在安全环境中，并不能提供完整性和身份验证保护。虽然 CRC 是一种错误检测代码，并能提供对环境因素的完整性保护。
（例如，噪声或EMC），它们并不能提供对有意或恶意行为者的保护。
- 考虑在身份验证失败的情况下，设备和/或系统应如何响应。
授权 为了本指南的目的，授权是指授予系统实体（例如，设备、服务器或软件功能）访问系统资源的权利或许可。更具体地说，作为一种防御措施，授权方案会强制执行权限（即与已验证的会话、身份或/和角色相关的“权利”）。这些权限要么允许允许的行为，要么拒绝不允许的行为，以确保系统资源仅通过被接受的方以被接受的方式访问。 在一个充分设计的授权方案中，应将“最小权限”原则应用于用户、系统功能和其他实体，仅允许这些实体获得执行特定功能的必要级别的系统访问权限。 例如，在恶意行为者获得了与患者权限相关的凭据的情况下，该恶意行为者不应能够访问制造商或医疗服务提供商预留的设备资源或功能，例如设备维护程序或更改药物剂量数量的能力。 虽然基于密码学证明设计的身份验证方案通常被认为是更可靠的，因此更受欢迎，但也可以基于其他有力的证据（例如，根据 AAMI TIR57 或 ANSI/AAMI SW96 以及相关的支持性论证和安全测试结果进行的风险/收益评估）进行有意义的授权检查。例如，能够使用近场通信 (NFC) 的医疗设备程序员，可以获得基于 NFC 的信号意图78 授予的权限，而该信号无法由其他未授权的设备通过射频 (RF)（例如，家庭监视器）产生。 以下列表提供了授权方案的推荐设计实现： 77 NIST 计算机安全资源中心词典将“最小权限”定义为“一种安全原则，该原则规定系统应限制用户（或代表用户执行的任务的进程）的访问权限，以达到完成分配任务所需的最低限度” 通过验证用户（例如，用户 ID 和密码、智能卡、生物识别、证书或其他适当的身份验证方法）来限制对设备的授权访问；
在适当的医疗设备系统中，使用自动定时方法来终止会话；
采用一种授权模型，该模型采用最小权限原则，根据用户角色（例如：照护者、患者、医疗服务提供者、系统管理员）或设备功能来区分权限；
设计设备，默认拒绝（即，未经设备明确允许的任何操作都应被默认拒绝）。例如，设备应通常拒绝所有未经授权的连接（例如：传入的 TCP、USB、蓝牙、串行连接）。
忽略请求是拒绝授权的一种方式。 密码学 建议实施密码学算法和协议，以实现《第四部分》中概述的安全设计目标。虽然高质量、标准化的密码学算法和协议 readily available，但一些包含密码学保护的商业产品由于不当配置和/或实施，已被证明存在可利用的漏洞。 虽然本指南的其他部分引用了密码学控制，但以下建议与选择和实施设备及其运行的更大系统所使用的底层密码学方案以及相关的关键信息密切相关：
选择行业标准密码学算法和协议，并选择适当的密钥生成、分发、管理和保护，以及强大的非重用机制。
使用当前 NIST 推荐的密码学标准（例如：FIPS 140-379）或具有等效安全强度的密码学保护，这些保护在设备及其整个使用寿命期间都应被认为是安全的。
制造商不应实施在相关标准或最佳实践中已过时或被禁止的加密算法（例如，NIST SP
800-131A，关于使用密码算法和密钥长度的过渡。
使用状态为“遗留使用”的算法，应在提交前与FDA进行讨论。
设计系统架构，并实施安全控制措施，以防止任何单个设备的完全被攻破导致能够泄露其他设备的密钥的情况。
例如，避免使用存储在设备上的主密钥，或仅基于设备标识符或其他容易获取的信息而设计的密钥生成算法。
例如，避免使用设备序列号作为密钥或密钥的一部分。 患者可能出于获取关于其设备的其他信息而披露设备序列号，或者在设备召回期间，用于识别受影响的设备。
实施密码学协议，以允许协商参数/版本，从而使用最新的、安全的配置，除非另有需要。
- 不应允许降级或版本回退，除非绝对必要出于安全原因，并且记录和记录该事件。 降级可能会使攻击者利用先前、安全性较弱的版本，应尽量避免。
代码、数据和执行完整性
许多网络安全事件的根本原因是设备完整性的违反。 这包括违反存储代码、存储和运行数据，或执行状态。以下建议旨在解决这些类别。
代码完整性
建议考虑并尽可能采用基于硬件的安全解决方案。
验证固件和软件。 验证软件/固件内容、版本号和其他元数据的签名、消息认证码 (MAC) 等认证标签。 预期的安装版本号本身应进行签名或具有 MAC。 设备应具有电子和可见的标识（例如，唯一设备标识符 (UDI)、型号 80、序列号）。
允许安装经过密码认证的固件和软件更新，并且禁止在存在或失败的密码认证的情况下进行安装。使用经过密码签名更新，以帮助防止任何未经授权的保护级别降低（降级或回滚攻击）。
通过确保新的更新代表授权的版本更改；
一种可能的授权降级方法是为降级请求签署新的元数据，而这些降级请求仅在特殊情况下发生。
在执行之前，确保软件、固件和配置的真实性得到验证，例如，基于数字签名的“允许列表”81；
在交付产品之前，禁用或以其他方式限制所有测试和调试端口（例如：
JTAG、UART）的未经授权访问；以及
使用设备外壳和其敏感通信端口上的防篡改密封，以帮助验证物理完整性。
数据完整性
验证所有传入数据的完整性，确保在传输或存储过程中未被修改。密码认证方案验证数据完整性，但不验证数据的有效性。因此，应验证所有传入数据的完整性，以确保在传输或存储过程中未被修改；
验证所有来自外部来源的数据符合预期的协议或规范。此外，根据需要验证数据范围，以确保它们在安全范围内；
保护必要的用于确保设备安全和有效性的数据完整性，例如，关键配置设置，如能量输出。
执行完整性
采用行业认可的最佳实践，在设备运行时，确保代码的完整性和有效性。例如，基于主机的入侵检测。
检测/预防系统（HIDS/HIPS）可用于实现这一目标；
- 仔细设计和审查所有处理外部数据解析的代码，采用自动化（例如，静态和动态分析）和手动（即，代码审查）方法。
方法 保密性 制造商应确保对任何/所有可能导致患者伤害的数据（例如，通过未经授权的使用，缺乏加密）的保密性得到保障。 凭证的保密性缺失可能被威胁行为者利用，从而对多名患者造成损害。 为了保护敏感信息和/或在静止和传输状态下的数据，缺乏加密可能会使其暴露于滥用，从而导致患者受到伤害。 例如，在处理和存储用于身份验证的加密密钥时，必须保证保密性，因为泄露可能会导致设备功能的未经授权的使用/滥用。
按照本附录 A 和 B 中描述的适当授权和身份验证方案的实施，通常可以确保保密性。 然而，制造商应在进行威胁建模和其他风险管理活动时，评估和评估是否如此，并根据需要对其医疗设备系统进行修改，以确保适当的保密性控制措施到位。
事件检测和记录 事件检测和记录是至关重要的功能，应在设备和其所运行的更大系统中存在，以便能够识别和跟踪对医疗设备进行尝试和成功的入侵行为。 这些事件检测功能和记录应包括存储功能（如果可能），以便后续可以进行法证调查。
虽然以下许多建议主要针对工作站，但以下概念也适用于嵌入式计算设备。 制造商应考虑以下内容，适用于所有设备：
实施设计功能，以便在正常使用期间，可以检测、识别、记录、计时和处理安全漏洞和可疑的入侵尝试。 在处理安全事件时，应根据 AAMI TIR57 或 ANSI/AAMI SW96 评估风险/收益，以确定在安全事件期间是否适当影响标准设备功能。
- 确保设计能够实现取证证据采集。设计应包括机制，用于在设备上安全地创建和存储日志文件，以跟踪安全事件。
文档应包括日志文件的位置、存储、回收、归档方式，以及它们如何被自动化分析软件（例如 IDS）使用。 安全事件的示例包括但不限于：配置更改、网络异常、登录尝试和异常流量（例如，向未知实体发送请求）。
设计设备，以限制漏洞的潜在影响，通过指定安全配置来实现。安全配置可能包括端点保护，例如反恶意软件、防火墙/防火墙规则、允许列表、定义安全事件参数、日志参数、物理安全检测以及/或 HIDS/HIPS。
设计设备，使其能够集成和/或利用反病毒/反恶意软件保护功能。这些功能可能因设备类型和包含的软件和硬件组件而异：
对于使用 Windows 操作系统：
建议在设备上安装反病毒/反恶意软件。制造商应评估多种选项，以支持用户根据不同选项进行选择，尤其是在设备用于医疗机构环境时。
对于使用其他商业操作系统（例如 Ubuntu、
Unix、Linux、Apple、Android）的设备：
根据环境和设备相关的风险，可能建议安装反病毒/反恶意软件。不同的操作系统很可能会根据网络暴露和风险进行逐个评估。
对于使用嵌入式操作系统（例如实时
操作系统：Windows 嵌入式
通常情况下，抗病毒/恶意软件检测/防护软件并非必需，除非已识别到特定风险或威胁，而这些风险或威胁无法通过其他预期的安全控制措施来解决。
设计设备，使其能够实现软件配置管理，并允许授权用户通过电子方式（即可供机器读取）跟踪和控制软件变更。
设计设备，以促进变异分析的进行，从而在不同设备型号和产品线中识别出相同的潜在风险。
83 犯罪现场证据的采集是数字取证的重要组成部分。 NIST SP 800-86 将数字取证定义为：
“将科学应用于数据的识别、收集、检查和分析，同时保持信息的完整性，并对数据进行严格的保管和追踪。” https://doi.org/10.6028/NIST.SP.800-86
设计设备，以便在检测到设备故障或异常行为时，及时通知用户，包括可能与网络安全漏洞相关的行为。
考虑设计设备，使其能够以机器可读的格式生成 SBOM。
弹性与恢复能力 设备应设计成能够抵御可能的网络安全事件（也称为“网络弹性”）并保持可用性。网络弹性能力对于医疗设备至关重要，因为它们提供了一种应对未知未来漏洞的安全缓冲。
以下建议旨在帮助设计人员实现网络弹性：
实施保护关键功能和数据的特性，即使设备已部分受损。例如，进程隔离、虚拟化技术和硬件级别的可信执行环境，都提供潜在机制来限制设备成功利用的后果。
设计设备，以便经过身份验证和授权的用户可以保留和恢复可信的默认设备配置。
设计设备，以指定医疗设备系统中的任何组件，在与医疗设备系统其余部分通信能力中断（包括长时间中断）时，所具有的弹性或独立运行能力。
设计设备，使其能够抵御可能的网络中断、拒绝服务、其他产品过大的带宽使用、服务质量（QoS）中断以及/或过大的抖动（即接收到的数据包延迟变化）等网络事件。
设计设备，使其能够抵御可能的噪声（例如扫描）。
固件和软件更新 设备应能够以安全和及时的方式进行更新，以在产品整个生命周期内保持安全性和有效性。尽管采取了最佳措施，但设备在上市后仍可能存在未被发现、可利用的漏洞。尤其是在设备的使用寿命内，随着时间的推移，威胁不断演变，利用方法也变得更加复杂。 FDA 建议制造商不仅应具备更新设备的能力，还应计划对在现场部署的设备进行快速测试、评估和修复。以下建议可以帮助实现这些目标：
设计设备，以预先考虑对软件和固件补丁和更新的需求，以便解决未来的网络安全漏洞。 这很可能需要额外的存储空间和处理资源。
考虑更新过程的可靠性，以及在通信中断或故障时更新过程的工作方式。 这应包括对硬件影响（中断的具体时间）以及更新过程的哪个阶段中断或故障的考虑。
考虑与常规功能更新周期无关的网络安全补丁和更新。
实施流程、技术、安全架构和演练，以促进补丁和更新的快速验证、验证和分发。
保留和维护完整的构建环境、虚拟机、回归测试套件、工程开发套件、模拟器、调试器和其他相关工具，这些工具用于开发和测试原始产品，以确保补丁和更新可以安全且及时地应用。
在设备的支持生命周期内，维护必要的第三方许可证。
制定应急计划，以应对第三方公司破产或停止支持授权产品的可能性。 应考虑模块化设计，以便可以轻松替换第三方解决方案。
实施安全的过程和机制，用于向用户提供经过验证的软件更新和补丁。
附录 2. 安全架构流程的提交文件 在上市前提交中，FDA建议制造商提供关于第五节 B.2 中标识的视图的详细信息。关于如何提供这些视图以及提供详细程度的建议，请参见下面的章节。除了图表和说明性文本外，还可以提供流程图，以传达预期在架构视图中解决的一些信息细节。
A. 图表
FDA 建议制造商提供图表，以帮助描述医疗设备系统的架构、接口、通信协议、威胁和使用的网络安全控制措施。可以使用不同的图表方法来描述架构，包括数据流图、状态图、泳道图和流程图等。架构视图应包含图表（或图表）以及带有解释性文字的说明，以明确描述与特定用例相关的流程或协议步骤。 架构视图应提供医疗设备系统各部分之间通信路径的特定协议细节，包括身份验证或授权程序和会话管理技术。这些视图应足够详细，以便工程师和审查人员能够从任何资产（例如制造商服务器）到任何相关的资产（例如医疗设备），甚至跨越中间资产（例如应用程序），以逻辑和易于的方式跟踪数据、代码和命令。这些图表还可以包含第 V.B.2 节中标识的架构视图中识别的信息，如果通过图表比单独的说明性文字更清晰或更易于理解，则可以包含这些信息。
B. 架构视图的信息细节
对于第 V.B.2 节中描述的每个视图，制造商应提供系统级别的描述和分析，包括所有医疗设备系统中的端到端安全分析，无论其预期用途如何。 这应包括所有通信路径的详细图表和跟踪，如以下所述。 安全相关的分析需要能够构建和跟踪重要通信路径的详细跟踪，这些跟踪描述了医疗设备系统中的任何两个资产之间的数据、代码和命令的保护方式。 这种分析还可以帮助确定应包含在每个设备的 SBOM 中的软件。 FDA 建议，安全架构视图应考虑以下信息：
详细图表和支持性解释性文本，识别所有医疗设备系统资产，包括但不限于：
设备的硬件本身（包括对任何商业平台的评估）；
与目标设备直接交互的应用程序、硬件以及/或其他支持性资产，例如配置、安装/升级和数据传输应用程序；
医疗机构运营的资产；
通信/网络资产；以及
制造商控制的资产，包括与外部实体交互的任何服务器（例如，收集和分发设备数据的服务器，或固件更新服务器）。
对于安全用例视图（以及/或解释性文本）中任何两个资产之间的所有通信路径，包括在至少有一个中间资产（例如，应用程序）的情况下，应提供以下详细信息：
沟通接口和路径的列表，包括沟通路径
(例如，在两个资产之间通过中间人进行通信)，以及任何未使用的接口；
表明该路径是否用于传输数据、代码和/或指令，以及传输的数据/信息/代码的类型；
协议名称（或名称）、版本号和端口/通道/频率；
详细描述每个医疗设备系统资产的主要功能以及所有可用功能，包括对任何内置但当前未使用或禁用的功能（例如，休眠应用程序功能或端口）的评估，并确保这些功能不能被激活和/或滥用；
每个资产的访问控制模型或功能（例如，权限、用户帐户/组、密码）；
如果用户与资产和通信渠道进行交互时，其角色和责任级别；
从一个通信路径到另一个通信路径的任何“转移”序列（例如，从资产到资产、从网络到网络或从蓝牙到 Wi-Fi），以及在转移过程中如何安全/保护数据、代码和/或指令（即，如何确保其完整性和真实性）；
解释在异常/错误/意外情况下预期的行为（例如，在数据传输过程中中断连接）；
如果存在，认证机制，包括算法名称/版本（如果可用）、“强度”指示器（例如，密钥位数、计算轮数）和操作模式（如果适用）；
使用的密码学方法及其类型和级别的密码密钥使用方式，以及其在医疗设备系统中的使用方式（例如，一次性使用、密钥长度、使用的标准、对称或非对称）；这些描述还应包括固件和软件更新的密码学保护细节；
如果密码学算法是专有，或是对标准算法的专有修改，则由密码学专家进行详细分析；
对于每个创建的身份验证器，列出其验证位置，以及如何将验证凭证（例如，证书、非对称密钥或共享密钥）分发到两个端点；
详细说明每种凭证类型（例如，密码、密钥）的生成、存储、配置、传输和维护方式，包括制造商和医疗机构控制的资产（例如，密钥管理和公共密钥基础设施（PKI））；
身份管理84（如果适用），包括身份的管理/转移和配置方式（例如，从制造商到程序员和从程序员到设备）；
如果使用或支持通信会话，则详细说明会话的建立、维护和终止方式，包括但不限于对安全性属性（例如，唯一性、不可预测性、时间戳和会话标识符验证）的保证；
包括任何安全配置设置及其默认值；
精确地说明图表元素（或解释性文本）、相关的危害和控制措施，以及测试之间的关联；
解释或提供用于证明安全声明和任何假设的证据；
追踪资产与第 V.B.2 节中描述的 SBOM 组件（适用于专有和第三方代码），并在适当情况下。
附录 3：用于临床试验用具免予审批的提交文件 FDA 了解在临床试验期间，平衡创新与安全对于设计的重要性。为了确保在设备设计早期就解决安全问题，FDA 确定了本指南中推荐的用于提交 IDE 申请的子集文件。
根据 21 CFR 812.25，制造商必须作为 IDE 申请的一部分，提供临床试验计划。对于本指南范围内用于临床试验的设备，FDA 建议该临床试验计划应包含关于该设备网络安全的信息。 具体而言，FDA 建议将以下文件作为 IDE 申请的一部分：
- 将网络安全风险纳入知情同意书（21 CFR 50.25(a)(2)
以及 21 CFR 812.25(g)；
全局、多患者视图，以及可更新/可修补的功能 (21 CFR 812.25(c), (d))
功能安全风险相关的用例视图（例如：植入式设备编程）
(21 CFR 812.25(c), (d))
软件材料清单 (21 CFR 812.25(c), (d));
一般标签 - 连接性及其相关的通用网络安全风险、可更新性和流程 (21 CFR 812.25(f))
FDA 计划在“在评估医疗器械临床试验设备时，应考虑的因素”指南中，对这些信息进行审查，该指南概述了对医疗器械临床试验设备进行风险-效益评估的考虑因素。因此，基于上述推荐文档批准的临床试验设备（IDE）的批准，并不排除在后续营销申请审查期间，可能会提出关于网络安全的进一步问题或担忧。这部分原因是，设计变更可能需要进行，以及网络安全具有时间性。在临床试验期间和提交设备用于营销授权时，网络安全改进可能需要进行（例如，操作系统不再支持或即将结束支持，第三方软件更新）。
附录 4. 市场准入前的提交文件 要素与风险的关联 如第四节 D 和指南中所述，医疗器械的网络安全设计和文档应与该器械的网络安全风险相匹配。虽然预计文档的范围应与风险相匹配，但指南中标识的所有类型的文档均建议用于所有具有潜在网络安全风险的医疗器械的市场准入前提交。如前所述，本指南中的提交文件建议旨在帮助制造商在《美国食品药品监督管理局法案》第 524B 条规定的要求下，满足其网络安全设备的要求。
下表总结了指南中标识的所有市场准入前提交文件，以及与这些文件相关的指南部分，以及是否建议用于 IDE 提交。虽然安全风险管理报告中标识了文档要素，但制造商可以以与现有文档流程一致的方式提供这些文档要素。 此表并非旨在仅作为交付清单，因为指南中概述的流程旨在帮助将这些文档及其内容与 FDA 的建议保持一致。此表代表一种可能的组织信息方式。
以下文档将自然与网络安全风险水平相匹配。这在威胁建模和架构视图文档的范围方面最为明显。
- 例如，一个设备可能只有一个硬件连接（例如，USB 端口）或一个
这种SaMD产品，与其他软件的依赖关系和连接性有限，可能只需要针对全球系统、多患者风险以及可更新/可修补性等方面，提供单一架构视图；安全使用案例视图可能仅限于针对可用的连接性和软件，提供更小的、独特的视图。
- 对于具有更高复杂性的设备，例如但不限于，网络、无线连接、云和/或商业操作系统，可能需要多个架构视图，以涵盖多患者风险和可更新/可修复性方面。因为可能存在多种导致多患者风险或更新设备组件的方式。
此外，为了充分说明架构中各种独特的安全和临床应用案例，可能需要提供多个安全用例视图。
表 1. 推荐的上市前提交文件
文件类型 上市前提交文件 指导 章节 IDE 提交* 网络安全风险 管理报告 V, VI.B 可能有助于提交，但不明确推荐 文件类型 上市前提交文件 指导 章节 IDE 提交*
威胁模型（可能包括架构 视图） V.A.1, V.A.3, V.A.4, V.A.5, V.B.2, 附录 1, 附录 2 可能有助于提交，但不明确推荐（参见架构 视图推荐）
网络安全风险 评估 V.A.2, V.A.3, V.A.4, V.A.5, V.A.6 可能有助于提交，但不明确推荐
SBOM V.A.4, VI.A 推荐
漏洞 评估和 软件支持 V.A.4 可能有助于提交，但不明确推荐
未解决 异常 评估 V.A.5 可能有助于提交，但不明确推荐
可追溯性 V.A, V.A.1, V.A.2, V.A.3, V.A.4, V.A.5, V.A.6, V.B.1, V.B.2, V.C, VI.A 可能有助于提交，但不明确推荐 措施和指标 V.A.6 可能有助于提交，但不明确推荐 架构视图 V.B 推荐
- 全球、多患者
可更新性/可修复性
用于具有安全风险的功能的安全性使用案例
要求 章节 V.B.1， 附录 1 推荐
- 全球、多患者
可更新性/可修复性
用于具有安全风险的功能的安全性使用案例
架构视图 （可能包含在 威胁模型中） 章节 V.A.1, V.B.2, 附录 1, 附录 2 推荐
- 全球、多患者
可更新性/可修复性
- 用于具有安全风险的功能的安全性使用案例
测试 章节 V.C 可能有用，但不明确推荐 预上市 提交文件 指南 章节 IDE 提交* 标签 章节 VI.A 推荐
包含网络安全风险的知情同意书
通用网络安全标签
连接性及相关的总体网络安全风险、可更新性/处理 网络安全管理 计划 第六部分。B 可能有助于提交，但并非明确推荐 *为了本表的目的，“推荐”是指 IDE 提交的元素 在 FDA 的第 3 附录中讨论；“可能有助于提交，但并非明确推荐”是指如果提交，可以对 FDA 有帮助，但并非明确推荐在第 3 附录中的其他元素。如果设备特定的指南包含与本表中不同或额外的建议，则应遵循设备特定的建议。如果制造商不确定，应使用 FDA 的 Q 提交流程。 附录 5. 术语 本附录中列出的术语仅用于本指南的目的，旨在用于评估医疗设备的网络安全。这些术语并非旨在应用于任何超出本指南的范围。 异常 – 任何与用户需求、要求、规格、设计文件或标准所期望的行为不同。 资产 – 任何对个人或组织有价值的东西。85 攻击面分析 – 评估攻击面，以确定进入和从系统（包括常见漏洞和未受保护的端口和服务）以及系统的所有途径。 可更新性和补丁性 – 任何原因（例如功能更新、安全补丁、硬件更换）下，设备及其相关资产可以轻松和及时更改的程度。 更新 – 医疗设备软件的修正、预防、适应或完善修改。124 漏洞 – 信息系统、系统安全程序(s)、内部控制(s)、人类行为或实施中的任何弱点，这些弱点可能被利用。 漏洞链 – 连续利用多个漏洞，以攻击系统，其中一个或多个在链的末端需要先前在链中成功完成的漏洞才能被利用。 可信设备 – 一个医疗设备，该设备：(1) 能够安全地防止网络安全入侵和滥用；(2) 提供一个合理的可用性和可靠性水平；(3) 能够以其预期的功能；以及 (4) 遵循一般安全程序以支持正确运行。 不可控风险 – 由于缺乏适当的补偿控制和风险缓解措施，导致患者健康存在无法接受的残留风险。 未解决的异常 – 软件中仍然存在缺陷，因为赞助方根据对设备安全和有效性的影响，认为不应修复或纠正该异常。 更新 – 修正、预防、适应或完善
2025年，第一级最终指南
2025年6月 请参阅“可用性通知”以获取更多信息。本指南取代了题为“医疗器械中的网络安全：质量体系考虑和先于上市提交的内容”的最终指南，该指南于2023年9月发布。 重新发布为第一级草案指南 2024年3月 请参阅“可用性通知”以获取更多信息。 *此表格已实施，自2025年6月起，可能无法完全反映之前的指南历史。 **“可用性通知”可通过“查找FDA指南文档”网页访问。
脚注
[^1]: 按照本指南的定义，“医疗器械软件功能”是指符合《联邦食品、药品和化妆品法》（FD&C Act）第201(h)条定义的软件功能。按照本指南的定义，“功能”是指产品的特定用途，可以是产品的预期用途或产品的预期用途的一部分。有关更多信息，请参阅FDA的指南“多功能产品：政策和考虑”。
[^2]: 21 CFR 3.2(e)。 医疗器械构成部分需要考虑网络安全问题，包括但不限于包含医疗器械软件功能或包含软件（包括固件）或可编程逻辑的设备。有关更多信息，请联系负责该组合产品的FDA审查部门。4
[^3]: 21 CFR 4.2。
[^6]: 在本指南中，我们将“勒索软件”定义为一种不断演变的恶意软件，旨在加密设备上的文件，使任何文件及其依赖的文件和系统无法使用。 此定义来自美国网络安全与基础设施安全机构（CISA）的“勒索软件 101”网页。
[^7]: 欲了解更多信息，请参阅 FDA 的网络安全网页。
[^8]: 欲了解更多信息，请参阅 FDA 的“SweynTooth：某些医疗设备可能受到网络安全漏洞的影响”安全通告。
[^9]: 欲了解有关德国医院勒索软件攻击的更多信息，请参阅《关于网络攻击、一家医院和一位垂死病人的故事》。 旨在使 TPLC 能够应对不断出现的网络安全风险，并更清晰地阐述 FDA 对预上市提交信息的建议，以解决网络安全问题。
[^10]: 请参阅附录 5，术语。
[^11]: 请参阅 89 FR 7496。 本最终规则于 2026 年 2 月 2 日生效，并修改了 21 CFR 第 820 部分（第 820 部分）的大部分要求，并引用了 2016 年版的国际
[^13]: 请参阅 89 FR 7496 第 7505 页。
[^19]: 请参阅 ISO 13485 第 7.3 条。 当在营销和分销后添加基于连接的功能，或当发现导致不受控制风险的漏洞时，对设备进行处理。 SPDF 可以与现有的产品和软件开发、风险管理以及整个质量管理系统流程集成。
[^21]: 欲了解“合理预见的滥用”的更多信息，请参考 IMDRF 的最终指南“医疗器械网络安全：原则和实践”。 这种设计方式更有可能确保设备的安全，即设备从一开始就被设计为在整个设备生命周期内，在设备及其使用的系统和/或网络中安全。 C。
[^23]: 欲了解“实质性等效性审查标准”的更多信息，请参考 FDA 的指南“510(k) 计划：在预先通知中评估实质性等效性 [510(k)]”。 医疗器械日益互联的特性，表明必须在设备设计中解决与设备连接相关的网络安全风险，因为这会影响安全性和有效性。24 医疗器械或更大的医疗器械系统可能通过使用 SPDF 能够合理地控制网络安全风险。
[^25]: 欲了解更多信息，请参阅 NIST 网络安全框架。
[^26]: 请参阅医疗器械和健康信息技术联合安全计划版本 2 (JSP2)。
[^30]: 请参阅 21 CFR 第 820 部分。 进行风险评估，并评估额外的控制措施或风险转移给用户/操作员，或者，如果需要，给患者。 如果合适，风险转移应仅在所有相关风险信息已知、评估并适当传达给用户时发生，并且包括供应链继承的风险，以及当设备或医疗器械系统由制造商控制的资产达到支持结束和生命周期结束时，如何处理风险转移，以及用户是否能够承担该角色（例如，如果用户是患者）。
[^31]: 在本指南中，我们将“风险转移”定义为采取的措施，这些措施将部分或全部风险转移给其他用户、资产、系统、网络或地理区域。 此定义改编自DHS风险词典。
[^42]: NIST 800-160 第 1 卷修订版 1，“构建值得信赖的安全系统”指出，安全架构定义过程生成一套代表性的安全视图，以告知选择适当的安全架构。 该过程还确定与交互的设备和/或系统中的漏洞和易受攻击性，并提供有关这些交互如何发生以及如何安全地实现的详细信息。 它包含信息，证明在风险管理过程中考虑的风险得到充分控制，从而支持证明医疗设备系统的安全性。
[^45]: 欲了解更多信息，请参阅 FDA 的指南“医疗设备反馈和会议请求”。
[^46]: 请参阅 ISO 13485 第 7.3 条。 FDA 建议在预上市提交中至少提供以下类型的视图：·
[^50]: 请参阅 FDA 的指南“将人机工程学应用于医疗设备”。
[^51]: 欲了解有关 FDA 关于标签变更和提交要求的政策，制造商可以使用“查找 FDA 指导文件”工具来识别与其产品和提交类型相关的相关指导文件。
[^52]: 请参阅 IEC TR 80001-2-2《将医疗设备纳入 IT 网络中的风险管理应用》——涵盖医疗设备安全需求、风险和控制的相关部分； IEC TR 80001-2-8
[^53]: 《食品、药品和化妆品法》第 524B(a) 条规定，提交特定类型医疗器械营销申请的“主体”负有义务。 《食品、药品和化妆品法》第 524B(b) 条规定，“赞助人”负有义务。 在本指南中，我们假设制造商是提交申请的实体，并在整个指南中使用“主体”或“赞助人”一词的替代，即“制造商”一词。 但是，如果除制造商以外的其他人提交根据《食品、药品和化妆品法》第 524B(a) 条规定的申请或提交材料向机构，则该人应遵循本指南中的制造商指南。 提交用于网络医疗器械的任何人都必须遵守第 524B 条的规定。
[^54]: 在本指南中，“510(k)”指的是原始、特殊和简化的 510(k) 提交。
[^55]: 在本指南中，“PMA”指的是原始 PMA 和补充 PMA。
[^56]: 在本指南中，“HDE”指的是原始 HDE 和补充 HDE。
[^57]: NIST 将可编程逻辑控制器 (PLC) 定义为“一种固态控制系统，具有用户可编程的存储器，用于存储指令，以实现特定功能，例如 I/O 控制、逻辑、定时、计数、三模式 (PID) 控制、通信、算术和数据/文件处理。” 因此，PLC 是一种由两部分组成的系统：(1) 硬件控制器，以及 (2) “用户可编程的存储器”或可编程逻辑，它指示硬件控制器执行指定功能。NIST 将软件定义为，其中包括“存储在硬件上的计算机程序和数据——通常存储在只读存储器或可编程只读存储器中”。因此，可编程逻辑是一种特定的计算机程序和/或存储在硬件上的数据，因此也是一种软件。有关 NIST 关于这些术语的定义，请参阅 NIST 计算机安全资源中心词典。
[^58]: 仅供本指南参考，“威胁表面”与“攻击表面”含义相同，但 FDA 使用“威胁表面”而非“攻击表面”一词，因为网络威胁并不一定需要构成“攻击”才能对医疗设备及其相关系统构成风险。
[^59]: 欲了解更多信息，请参阅 WannaCry 勒索软件加密的医院医疗设备和指标。
[^61]: 例如，某些设备可能需要通过 USB 连接进行维护。 尽管连接可能很短暂，但连接功能存在，因此该设备被认为是能够连接到互联网。
[^63]: 根据 NIST 的定义，“更新”是指“修复软件中的安全和/或功能问题，包括补丁、升级或其他修改”（参见 NIST 计算机安全资源中心词典）。 CISA 将“补丁和软件更新”定义为“解决程序或产品中安全漏洞的软件和操作系统 (OS) 更新”（参见了解补丁和软件更新）。 我们将满足第 524B(b)(2)(A)-(B) 条规定的要求，用于更新或补丁，视为修改设备代码以应对网络风险的行动。
[^64]: 为了本指南的目的，我们指的是对“相关系统”的评估，以确定该设备在与相关系统交互时仍然具有网络安全。 更多关于相关系统的信息，请参见下文 VII.C.2。
[^67]: 请参见《食品、药品和化妆品法》第 524B(b)(1) 条。
[^73]: 根据《食品、药品和化妆品法》第 524B(b)(2)(B) 条，制造商必须向网络设备及其相关系统提供市场后更新和补丁，以尽快解决可能导致无法控制的风险的关键漏洞，以及其他要求。有关“可能导致无法控制的风险的关键漏洞”或设备可能暴露的漏洞（例如，与先导设备提交的技术特征相比的新风险或漏洞，如组件软件的支持级别、设备使用的通信协议或技术的更改），请参阅第 VII.C.1 条。例如，在审查用于中央护理站软件的 510(k) 时，如果 FDA 发现该设备与先导设备相比存在风险增加，因为该设备缺乏保护免受最近发现的网络威胁的必要加密，则 FDA 可能会要求提供额外的性能数据（例如，请参阅第 V.C 条的文档建议）。如果提供的资料不足，FDA 可能会认定该新设备与先导设备在实质上不相同 (NSE)，因为如果该威胁被利用，可能会对设备的安全性、有效性产生负面影响，因为在医院中，医疗人员需要准确的警报来有效监测患者的健康状况。
[^74]: 欲了解有关 510(k) 提交的当前审查实践的更多信息，请参阅 FDA 的指南“510(k)”
[^76]: 参见附录 5，“术语”中的“安全性强度”的定义。·
[^78]: 就本指南而言，“意图信号”特指 NFC 通信的实施。·
[^79]: 参见 NIST FIPS 140-3 密码模块的安全要求。https://doi.org/10.6028/NIST.FIPS.140- 42 产品，并且应避免将其作为密钥生成过程的一部分（例如，可以使用公钥密码来帮助实现这一目标）。·
[^80]: 欲了解更多关于 UDI 的信息，请参阅 FDA 的 UDI 规则、指南、培训和其他资源的网页。
[^81]: 就本指南而言，“允许列表”是指明确的实体，例如主机或应用程序，这些实体已知是无害的，并且已获得在组织和/或信息系统内的使用批准。该术语来自 NIST SP 800-128 中“白名单”的定义。https://doi.org/10.6028/NIST.SP.800-128·
[^114]: “安全产品开发框架”一词，是为本指南而开发的，旨在帮助反映和涵盖与安全开发生命周期和框架相关的概念。虽然“SPDF”是一个新的术语，但与安全产品开发和风险管理相关的概念并非新，并且符合《质量管理体系要求》（QMSR）和《标签规定》的要求。随着网络安全不断发展，FDA 将继续调整其术语，以反映最佳实践，并根据数据和信息保护的方式，在不同的安全领域之间建立联系。安全架构反映了安全领域、安全相关元素的在安全领域内的位置、安全相关元素之间的互连关系和信任关系，以及安全相关元素之间的行为和交互。