医疗器械也要做“网络安全体检”？一文看懂MDR与IEC 81001-5-1

MDR如何看待医疗器械网络安全？

• MDR中的网络安全要求体现在哪里

在MDR框架下，网络安全并不是一项独立的合规要求，而是与医疗器械的安全性和性能要求相衔接。MDR附件I《通用安全和性能要求》（GSPR）要求制造商结合医疗器械的预期用途、预期使用环境以及可合理预见的风险，采取相应的安全和风险控制措施。对于包含软件、网络连接或数据交互功能的医疗器械，这意味着制造商需要在产品风险管理和软件开发过程中充分考虑网络安全因素，并确保相关风险得到适当控制。

• MDCG 2019-16进一步明确网络安全考量

为帮助制造商落实相关要求，欧盟医疗器械协调组（MDCG）发布了 MDCG 2019-16《医疗器械网络安全指南》，从医疗器械生命周期的不同阶段提出网络安全方面的指导，包括安全设计、风险管理、验证与确认以及上市后监测等。因此，网络安全的合规考量并不局限于产品上市前的某项技术测试，而是需要与医疗器械的软件生命周期和风险管理过程相结合。

• 合规关注点从“测试结果”转向“过程与证据”

从监管和合规角度看，制造商需要能够通过技术文档和相关记录说明：网络安全风险是否得到充分识别，采取的安全措施是否与风险相匹配，以及相关措施是否经过验证。这也意味着，漏洞扫描、渗透测试等测试结果只是网络安全合规证据的一部分，更重要的是建立能够支撑这些结果的完整过程和可追溯证据。

IEC 81001-5-1：将网络安全融入软件生命周期

如果说MDR明确了医疗器械网络安全的合规方向，那么IEC 81001-5-1:2021则为健康软件的安全生命周期管理提供了具体的过程框架。该标准关注的并不是某一种具体的安全技术，而是如何将网络安全活动系统地融入软件产品生命周期，并通过相应的活动、任务和文档形成可追溯的过程证据。这也使网络安全能够与医疗器械软件开发及风险管理过程相衔接。

• 从规划阶段开始建立安全要求

网络安全应在软件开发初期就得到考虑。制造商需要在产品规划阶段明确网络安全相关活动、职责和资源，并确定适用的安全开发要求和编码规范。在此基础上，根据产品的预期用途、运行环境及潜在风险建立网络安全需求，例如身份认证与授权、数据保密性和完整性、日志与审计、软件更新以及系统的安全性和韧性等，使网络安全要求能够进一步落实到后续的设计与开发活动中。

• 在架构与设计阶段落实“Security by Design”

在架构和设计阶段，网络安全要求需要进一步转化为具体的安全架构和设计措施。制造商可以通过威胁建模识别潜在攻击路径，并结合信任边界、接口以及关键数据流分析安全风险。同时，应在设计中考虑纵深防御、最小权限、攻击面最小化以及故障安全（fail-safe）等原则，并对第三方软件和开源软件组件进行适当管理，确保软件供应链中的组件风险得到识别和控制。

• 在实施及验证阶段形成安全证据

进入软件实施阶段后，网络安全要求需要落实到安全编码、代码审查以及第三方和开源组件管理等具体活动中，并建立软件物料清单（Software Bill of Materials, SBOM），记录软件组件及其依赖关系，为后续的漏洞识别和风险分析提供基础信息。在验证与确认阶段，则需要根据产品的网络安全风险开展相应的安全测试，例如漏洞扫描、安全功能测试和渗透测试等，以验证安全控制措施是否得到正确实施并达到预期效果。测试的范围和深度应与产品的网络安全风险相匹配。

从威胁到患者安全：建立可追溯的网络安全风险管理

将网络安全融入软件生命周期后，下一步的关键是回答一个问题：识别出的网络安全威胁，如何转化为可评估、可控制、可验证的产品风险？

• 从威胁识别到风险评估

制造商可以通过威胁建模、漏洞分析以及安全测试等活动，识别潜在的网络安全威胁、攻击路径和软件安全弱点，并分析其可能造成的影响。在此基础上，结合 ISO 14971 的风险管理要求，进一步评估网络安全事件是否可能导致危险情况及对患者、使用者造成的伤害。对于已识别的漏洞，可参考 CVSS 进行严重性评价，但医疗器械风险判断还需结合预期用途、使用环境及对产品安全和患者安全的实际影响进行综合评估。

• 建立“威胁—风险—控制”的可追溯链条

完成风险识别和评估后，制造商需要针对已识别的风险制定相应的风险控制措施，并通过验证活动确认控制措施是否得到有效实施。整个过程应形成清晰的可追溯关系：

威胁 → 漏洞/攻击路径 → 危险情况 → 风险 → 风险控制 → 验证 → 剩余风险

这意味着，制造商不仅需要说明“采取了哪些安全措施”，还应能够解释这些措施针对的是哪项风险，以及如何证明其有效性。相关分析、决策和验证结果也应形成相应的技术文档和记录，从而支撑产品的安全性与合规性论证。

• SBOM为持续风险管理提供基础信息

对于包含第三方软件和开源组件的医疗器械，软件物料清单（Software Bill of Materials, SBOM） 可以帮助制造商明确软件组成及组件依赖关系，为后续漏洞识别和影响分析提供基础。当新的漏洞或安全威胁出现时，制造商可以利用SBOM快速判断受影响的组件及产品范围，并进一步评估其对产品安全和患者安全的潜在影响。由此，SBOM不只是软件开发阶段的清单，更可以成为支持产品全生命周期网络安全风险管理的重要基础数据。

上市之后怎么办？

• 建立持续的网络安全管理机制

医疗器械上市，并不意味着网络安全管理工作的结束。产品进入市场后，新的漏洞、网络安全威胁、软件组件变化以及实际使用反馈都可能不断出现。制造商需要持续关注相关信息，并评估其是否可能影响产品安全。因此，上市后的网络安全管理应成为贯穿产品全生命周期的持续过程。

• 持续监测漏洞与网络安全威胁

制造商应建立持续的信息监测机制，关注产品自身以及第三方、开源软件组件中的新漏洞、安全事件和网络安全威胁。对于发现的安全问题，应结合产品实际情况进行影响分析，并根据评估结果采取适当的修复、风险缓解或其他响应措施。同时，及时更新软件组成信息，以便在新漏洞出现时快速识别受影响的产品和组件。

• 建立安全更新与事件响应机制

当发现可能影响医疗器械安全的漏洞或网络安全事件时，制造商应建立明确的响应机制，及时开展分析、处置和必要的风险升级。对于需要通过软件更新解决的安全问题，还应对更新进行必要的验证，确保其不会引入新的安全风险或影响产品的预期性能。

• 与PMS和风险管理形成闭环

上市后的网络安全信息还应与医疗器械的上市后监督（PMS）及警戒流程相衔接。漏洞信息、安全事件、用户反馈以及安全更新等，都可能成为重新评估产品风险的重要输入。当新的网络安全风险出现时，制造商应及时更新相关风险分析和技术文档，必要时调整风险控制措施。最终形成：

持续监测 → 风险识别 → 响应与处置 → 验证 → PMS反馈 → 风险管理更新

通过这一闭环，网络安全才能真正贯穿医疗器械从设计开发到上市后运营的整个生命周期，而不是停留在上市前的测试和合规文件层面。

DQS观察

对于医疗器械制造商而言，网络安全不应被视为开发后期的附加项，而应从产品规划和设计阶段开始融入，并贯穿风险管理、验证以及上市后监测等环节。从实践来看，企业需要将MDR法规要求、IEC 81001-5-1安全生命周期管理和ISO 14971风险管理有机衔接，同时建立持续的漏洞监测和响应机制，使网络安全风险能够被及时识别、评估和处置。

在此基础上，通过专业的第三方评估、测试或认证服务，可以对企业建立的网络安全管理过程及相关证据进行独立评价，帮助识别潜在薄弱环节，并为企业持续完善网络安全管理和合规证明提供支持。只有将网络安全真正融入产品全生命周期，才能在满足合规要求的同时，更有效地支撑医疗器械的安全性和持续运行。