欧盟医疗器械网络安全合规指南：NIS2指令、MDCG 2019-16与MDR网络安全要求全解析

欧盟正在构建全球最复杂、最严格的医疗器械网络安全监管体系。与FDA将网络安全要求集中于单一指南文件不同，欧盟采用了多层叠加的立法架构：MDR基本安全与性能要求（GSPRs）构成底层基础，MDCG 2019-16 rev.1提供具体执行指南，NIS2指令覆盖关键实体的网络安全治理义务，而《网络弹性法案》（Cyber Resilience Act, CRA）则对所有含数字元素的产品施加横向安全要求。对于计划进入或已在欧盟市场销售联网医疗器械的中国企业而言，理解这四层法规之间的交互关系并建立系统化的合规架构，已成为市场准入的核心前提。

本文是本站FDA医疗器械网络安全指南和NMPA医疗器械网络安全合规全攻略的欧盟篇补充，专门聚焦欧盟网络安全法规体系，提供从法规解读到技术文件编写再到上市后管理的全链路指导。

一、欧盟医疗器械网络安全法规全景图

1.1 四层叠加的监管架构

欧盟医疗器械网络安全并非由单一法规覆盖，而是由多部法律和指南共同构成一个层次分明的监管体系：

层级	法规/指南	法律性质	适用对象	核心关注点
第一层	MDR 2017/745 附录I	强制性法规	所有医疗器械	产品安全性（GSPR 17.2, 17.4）
第二层	MDCG 2019-16 rev.1	指导性文件	含软件的医疗器械	网络安全上市前/后要求细则
第三层	NIS2指令 2022/2555	强制性指令	医疗器械制造商（Essential Entity）	组织层面网络安全治理与事件报告
第四层	CRA (EU) 2024/2847	强制性法规	含数字元素的产品	产品全生命周期安全性

关键区别：MDR和CRA关注的是产品层面的网络安全（产品本身是否安全），NIS2关注的是组织层面的网络安全（制造商的网络安全管理体系是否健全），MDCG 2019-16则是连接产品要求与实际执行的桥梁。

1.2 法规之间的交互关系

理解四层法规之间的关系是合规规划的基础：

交互关系	具体说明
MDR与CRA	CRA第12条明确规定：已符合MDR网络安全要求的医疗器械，视为满足CRA的对应要求（MDR优先原则）
MDR与NIS2	MDR覆盖产品安全，NIS2覆盖组织安全——两者互补而非替代
MDCG与MDR	MDCG 2019-16是MDR GSPRs 17.2/17.4的官方解读，公告机构以此为审查依据
NIS2与CRA	NIS2覆盖运营商义务，CRA覆盖产品义务——对制造商来说两者均适用

1.3 关键时间线（2024-2027）

日期	里程碑	对中国企业的影响
2024年10月17日	NIS2指令转化为各成员国国内法的截止日	成员国开始执行NIS2要求
2024年12月10日	CRA正式生效（Official Journal发布后第20天）	开始36个月过渡期
2025年6月11日	CRA安全事件报告义务生效（生效后6个月）	即使产品尚未合规，安全事件须报告
2025年6月	MDCG 2025-4发布——医疗器械软件应用在线平台安全分发指南	明确App Store等平台分发的合规要求
2025年12月11日	CRA合格评定机构通知要求生效（生效后12个月）	公告机构开始准备CRA审查能力
2026年5月26日	MDR全面适用截止日（所有器械须符合MDR）	遗留器械的网络安全升级截止
2027年12月11日	CRA全面适用（生效后36个月）	所有含数字元素的产品须满足CRA全部要求

二、MDR附录I网络安全基本要求（GSPRs）

2.1 GSPR 17.2：含软件器械的一般要求

MDR附录I第17.2条是欧盟医疗器械软件安全的基石条款，其原文要求如下：

"含有软件的器械或本身即为软件的器械，应根据最新技术水平（state of the art）开发和制造，同时考虑开发生命周期、风险管理、包括信息安全在内的原则、验证和确认。"

GSPR 17.2的四个核心要素：

要素	具体要求	典型证据
开发生命周期	遵循IEC 62304定义的软件生命周期过程	软件开发计划、需求规格、架构设计、测试报告
风险管理	将网络安全纳入ISO 14971风险管理框架	网络安全风险分析、威胁建模、FMEA
信息安全	采取适当措施保护数据机密性、完整性、可用性	加密方案、访问控制、安全架构文档
验证与确认	对安全控制措施进行充分验证	渗透测试报告、安全代码审查、漏洞扫描报告

2.2 GSPR 17.4：与其他设备或产品交互的要求

GSPR 17.4专门针对与其他设备、网络或平台有交互的医疗器械，要求制造商：

最小化连接风险：在与其他器械、网络环境或IT基础设施交互时，将安全风险降至可接受水平
定义预期IT环境：明确器械的最低IT平台要求、网络配置要求和安全措施
数据保护：防止未经授权的访问，确保数据传输的安全性
合理可预见的误用：考虑用户在连接和配置过程中可能出现的误操作

2.3 其他相关GSPRs

GSPR条款	与网络安全的关联
GSPR 1	一般安全要求——网络安全风险属于器械整体风险的一部分
GSPR 2	风险管理——须涵盖网络安全威胁情景
GSPR 4	受益-风险评估——网络安全风险纳入受益-风险分析
GSPR 14.2(d)	IFU须包含IT环境和安全配置说明
GSPR 23.4	个人数据保护——涉及GDPR合规
附录II 6.1	技术文件须包含网络安全相关安全与性能验证信息

三、MDCG 2019-16 rev.1 深度解读

3.1 文件定位与效力

MDCG 2019-16 rev.1（全称《Guidance on Cybersecurity for Medical Devices》）于2020年1月发布，是医疗器械协调小组（MDCG）就MDR/IVDR网络安全要求发布的官方解释性指南。虽然MDCG指南在法律上不具有约束力，但在实务中：

公告机构将其作为审查技术文件中网络安全内容的主要参考依据
各成员国主管当局在市场监督中参照此指南评估合规性
欧盟法院在争议裁决中会考虑MDCG指南的解释

3.2 上市前网络安全要求

MDCG 2019-16将上市前网络安全要求分为五大领域：

3.2.1 安全需求规格

要求项	具体内容
CIA三性分析	识别器械处理的所有数据资产，评估其机密性、完整性、可用性需求
安全目标定义	基于风险评估确定器械必须达到的安全保护级别
威胁建模	采用STRIDE、PASTA或Attack Tree等方法识别威胁情景
安全功能需求	将安全目标转化为可测试的功能需求（如加密强度、认证机制）

3.2.2 安全架构设计

制造商应在技术文件中提供以下安全架构信息：

纵深防御策略：说明器械采用的多层安全机制（网络层、应用层、数据层）
最小权限原则：说明用户和进程的权限设计遵循最小必要原则
攻击面分析：识别和文档化所有网络接口、物理接口和用户交互界面
信任边界：定义器械内部和外部的信任域划分

3.2.3 安全验证与确认

MDCG 2019-16要求制造商进行以下测试活动：

测试类型	说明	频率要求
漏洞扫描	使用自动化工具扫描已知漏洞	每次发布前 + 定期（建议至少每季度）
渗透测试	由独立安全专家进行深度安全测试	每次重大发布前
模糊测试	对输入接口进行异常数据注入测试	针对所有外部接口
安全代码审查	人工审查关键安全代码段	覆盖安全关键功能
第三方组件审计	审查开源和第三方组件的已知漏洞	每次发布前 + 持续监控

3.2.4 安全使用说明

制造商须在使用说明书（IFU）和随附文档中提供以下网络安全信息：

器械的最低IT环境要求（操作系统版本、网络配置、防火墙规则）
建议的安全配置和加固指南
用户和管理员的身份认证要求
数据备份和恢复程序
安全更新的安装说明
退役和数据擦除程序
残余网络安全风险声明：告知用户哪些风险需由使用环境承担

3.2.5 风险管理中的网络安全

MDCG 2019-16要求将网络安全风险纳入ISO 14971风险管理流程，具体包括：

风险管理步骤	网络安全特殊考量
预期用途定义	明确器械的网络连接方式和数据流
危害识别	包含网络安全特有危害（数据泄露、恶意代码注入、拒绝服务）
风险估计	考虑威胁主体的能力和动机（与传统安全风险不同）
风险控制	优先采用设计内安全（Security by Design）措施
受益-风险	网络安全风险可能影响器械的整体受益-风险结论
残余风险评估	网络安全残余风险须在IFU中向用户披露

3.3 上市后网络安全要求

MDCG 2019-16将上市后网络安全管理视为与上市前同等重要的义务：

3.3.1 漏洞监控

持续监控公开漏洞数据库（CVE/NVD、CERT/CC、ICS-CERT）
监控器械使用的第三方组件（操作系统、库、协议栈）的安全公告
建立接收外部漏洞报告的渠道

3.3.2 安全更新管理

更新类型	时限要求	是否需要变更通知
紧急安全补丁（CVSS ≥ 9.0）	尽快发布，建议14天内	视变更影响评估结果而定
关键安全更新（CVSS 7.0-8.9）	建议30天内	需评估是否构成重大变更
常规安全更新	按季度发布周期	通常无需通知
生命终止（EOL）计划	提前通知用户，建议至少12个月	须通知公告机构和用户

3.3.3 协调漏洞披露（CVD）

MDCG 2019-16鼓励制造商建立协调漏洞披露机制：

发布漏洞披露政策（VDP），明确报告渠道和处理流程
在公司网站上提供安全联系信息（如 security@company.com）
承诺不对善意安全研究者采取法律行动
与欧盟CERT合作处理跨境漏洞事件

四、NIS2指令对医疗器械制造商的影响

4.1 NIS2的适用范围

NIS2指令（Directive (EU) 2022/2555）于2023年1月16日生效，取代了此前的NIS1指令，大幅扩展了适用范围和处罚力度。

医疗器械制造商在NIS2中的定位：

分类	适用条件	法律后果
关键实体（Essential Entity）	医疗器械制造商被NIS2附录I明确列为"卫生部门"中的关键实体	须满足全部NIS2义务，受主动监管
重要实体（Important Entity）	中小型医疗器械制造商（员工<250人或年营收<5000万欧元）	义务相同但监管力度较低（事后监管）

规模门槛：NIS2原则上仅适用于中型以上企业（员工 ≥ 50人或年营收 ≥ 1000万欧元）。但成员国可将关键供应链中的小型企业纳入适用范围。

4.2 NIS2核心义务

4.2.1 网络安全风险管理措施（Article 21）

NIS2第21条要求医疗器械制造商采取以下最低安全措施：

序号	措施要求	对制造商的具体含义
1	风险分析和信息系统安全政策	制定并维护企业级网络安全策略
2	事件处理	建立网络安全事件检测、分析、响应和恢复流程
3	业务连续性和危机管理	确保网络事件不中断器械生产和供应
4	供应链安全	评估和管理供应商（含软件供应商）的网络安全风险
5	网络安全采购、开发和维护	在产品开发全生命周期中嵌入安全要求
6	网络安全措施有效性评估	定期进行安全审计和渗透测试
7	基础网络安全实践和培训	员工网络安全意识培训
8	密码学和加密政策	制定适当的加密和密码管理策略
9	人力资源安全	人员入职/离职的安全管理
10	多因素认证（MFA）	对关键系统实施多因素认证

4.2.2 事件报告义务（Article 23）

NIS2引入了欧盟最严格的网络安全事件报告时限：

报告阶段	时限	内容要求
早期预警	发现事件后24小时内	是否疑似恶意行为、是否可能跨境影响
事件通知	发现事件后72小时内	事件评估（严重程度、影响范围）、已知的入侵指标（IoC）
中期报告	应CSIRT或主管当局要求	事件处理进展、技术细节更新
最终报告	事件解决后1个月内	根本原因分析、采取的缓解措施、跨境影响评估

与MDR警戒报告的关系：如果网络安全事件同时构成MDR下的严重不良事件（Serious Incident），制造商须同时向主管当局提交NIS2事件报告和MDR警戒报告——两套报告体系并行，不可互相替代。

4.2.3 供应链安全要求

NIS2对供应链安全的要求对中国制造商影响尤为显著：

供应商风险评估：欧盟客户（医院、经销商）须评估中国制造商的网络安全能力
合同安全条款：采购合同中须包含网络安全要求条款
第三方组件管理：制造商须管理其使用的所有第三方软件组件的安全风险
ICT供应链协调风险评估：欧盟可对来自特定国家的ICT产品进行协调安全评估

4.3 NIS2处罚机制

实体类型	最高罚款	管理层责任
关键实体	1000万欧元或全球营收的2%（取高值）	管理层个人可被追究责任
重要实体	700万欧元或全球营收的1.4%（取高值）	管理层个人可被追究责任

管理层责任：NIS2第20条明确要求管理层（Management Body）批准网络安全风险管理措施并监督其实施，管理层须接受网络安全培训，个人可因失职被暂停职务。

五、欧盟《网络弹性法案》（Cyber Resilience Act, CRA）

5.1 CRA概述与适用范围

CRA（Regulation (EU) 2024/2847）于2024年12月10日正式发布于Official Journal，是全球首部针对含数字元素产品的横向网络安全法规。

CRA对医疗器械的适用规则：

情况	CRA适用性	说明
已获MDR/IVDR CE标志的医疗器械	CRA不额外适用（Article 12）	MDR网络安全要求视为满足CRA对应要求
仅具有MDR附件功能的软件（如HIS系统）	CRA适用	非医疗器械的健康IT产品须满足CRA
器械的非医疗功能组件	可能适用CRA	需个案分析

关键启示：对于已走MDR合规路径的医疗器械，CRA的直接影响有限。但CRA要求提高了整个数字供应链的安全基线——器械所使用的第三方操作系统、通信模块、云服务等组件供应商都将受CRA约束，间接推动了器械供应链的安全提升。

5.2 CRA核心要求（适用于非医疗器械的健康IT产品）

虽然CE标志的医疗器械可豁免CRA直接适用，但了解CRA要求有助于理解欧盟网络安全监管的整体方向：

要求类别	具体内容
设计安全（Security by Design）	产品设计阶段即考虑网络安全，默认安全配置
漏洞处理	产品整个支持期内免费提供安全更新
SBOM	须提供机器可读格式的SBOM
事件报告	发现被积极利用的漏洞后24小时内向ENISA报告
合格评定	关键产品须通过第三方合格评定
支持期限	明确声明产品的安全支持期限（至少5年）

5.3 CRA对医疗器械供应链的间接影响

影响维度	具体说明
操作系统供应商	嵌入式Linux、RTOS等须符合CRA，器械可获得更及时的安全补丁
通信模块供应商	Wi-Fi/BLE模块、蜂窝模块须符合CRA安全要求
云服务平台	与器械配合的云平台须满足CRA漏洞管理义务
开源组件	CRA对开源软件有特殊条款（商业集成者承担义务）

六、IEC 81001-5-1：健康软件产品安全

6.1 标准定位

IEC 81001-5-1:2021（《Health software and health IT systems safety, effectiveness and security -- Part 5-1: Security -- Activities in the product life cycle》）是全球首个专门针对健康软件网络安全生命周期的国际标准。在欧盟语境下，该标准具有特殊重要性：

被欧盟委员会列为MDR的协调标准候选（尚未正式纳入Official Journal协调标准清单）
MDCG 2019-16将其作为网络安全最新技术水平（state of the art）的主要参考
多家公告机构已将IEC 81001-5-1合规性作为网络安全审查的事实标准

6.2 标准核心内容

IEC 81001-5-1覆盖健康软件产品的全生命周期安全活动：

生命周期阶段	安全活动	关键输出物
需求阶段	安全需求分析、威胁建模	安全需求规格、威胁模型报告
架构设计	安全架构设计、攻击面分析	安全架构文档、攻击面分析报告
实现	安全编码实践、静态分析	编码规范遵循报告、静态分析报告
测试	安全测试（渗透测试、模糊测试）	安全测试报告、漏洞修复记录
发布	安全发布检查、SBOM生成	发布安全签核、SBOM文件
运维	漏洞监控、安全更新发布	漏洞跟踪记录、补丁发布记录
退役	数据擦除、安全功能停用	退役计划、数据处置记录

6.3 与IEC 62304的关系

比较维度	IEC 62304	IEC 81001-5-1
关注点	软件安全性和功能正确性	软件网络安全
风险管理	关注软件故障导致的安全风险	关注网络攻击导致的安全风险
生命周期覆盖	开发和维护	全生命周期（含退役）
配合使用	两者互补，建议同时实施	引用IEC 62304的流程框架

实践建议：在技术文件中，建议将IEC 62304和IEC 81001-5-1的合规证据整合为统一的软件安全生命周期文档包，避免重复工作。

七、SBOM（软件物料清单）要求

7.1 欧盟SBOM要求现状

与FDA已将SBOM列为强制性提交要求不同，欧盟当前的SBOM要求更为分散：

法规/指南	SBOM要求	强制性
MDR	未明确要求SBOM，但GSPR 17.2要求了解软件组成	间接要求
MDCG 2019-16	建议制造商维护SBOM以支持漏洞管理	建议性
CRA	明确要求机器可读格式的SBOM（Annex I, Part II）	强制性（2027年12月起）
IEC 81001-5-1	要求建立和维护软件组件清单	标准要求

7.2 SBOM实践要求

无论当前法规是否明确强制，从实际审查角度，SBOM已成为公告机构审查技术文件时的高频问询项：

SBOM要素	说明
组件名称	所有第三方和开源软件组件的完整名称
版本号	每个组件的精确版本标识
供应商	组件的来源（供应商名称或开源项目）
许可证	每个组件的开源许可证类型
已知漏洞	映射到CVE数据库的已知漏洞状态
依赖关系	组件之间的层级依赖关系

7.3 EU vs FDA SBOM要求对比

对比维度	欧盟（MDR + CRA）	FDA
强制性	MDR间接要求；CRA明确强制	FD&C Act 524B明确强制
提交要求	技术文件中备查（无需随申请提交）	须随510(k)/PMA申请提交
格式要求	CRA要求机器可读格式	建议使用SPDX或CycloneDX格式
更新频率	持续维护	每次提交时更新
覆盖范围	所有软件组件	所有软件组件（含开源和商业）
工具推荐	无官方推荐	无官方推荐（业界常用Syft、FOSSA、Snyk）

八、EU vs FDA vs NMPA网络安全要求对比

以下表格提供三大监管体系的系统性对比，助力同时面向多市场的中国企业建立统一合规框架：

对比维度	欧盟（MDR + MDCG）	美国（FDA）	中国（NMPA）
核心法规依据	MDR Annex I GSPR 17.2/17.4；MDCG 2019-16	FD&C Act Section 524B；FDA网络安全最终指南	《医疗器械网络安全注册审查指导原则》（2024年修订）
法律性质	法规 + 指南	法规 + 强制性指南	指导原则（非强制但实务中为审评依据）
适用范围	含软件的所有器械（含IVDR）	网络设备（Cyber Device）	具有网络连接功能或数据交换功能的器械
SBOM要求	间接要求（CRA将强制）	强制提交	要求提供第三方软件组件清单
威胁建模	建议（MDCG）	强制	建议（参照STRIDE等方法）
渗透测试	建议	强制	建议
安全更新机制	须在产品生命周期内提供	须在产品生命周期内提供	须制定更新计划
事件报告	MDR警戒 + NIS2事件报告	MedWatch + CISA报告	不良事件报告
上市后漏洞管理	MDCG要求持续监控 + NIS2义务	须在合理时限内解决已知漏洞	要求建立漏洞响应机制
协调标准	IEC 81001-5-1（候选）	AAMI TIR57；NIST CSF	YY/T 0664；GB/T 42932
不合规后果	公告机构不予发证；NIS2罚款（最高2%营收）	RTA拒绝受理；上市后强制召回	注册审评不予通过

九、技术文件中的网络安全证据

9.1 技术文件结构

根据MDR附录II和MDCG 2019-16的要求，技术文件中的网络安全部分建议按以下结构组织：

文档编号	文档名称	内容概述	参考标准/指南
CYB-001	网络安全管理计划	网络安全生命周期活动规划	IEC 81001-5-1 Clause 4
CYB-002	安全需求规格	CIA分析、安全功能需求	MDCG 2019-16 Section 4.2
CYB-003	威胁建模与风险分析	STRIDE分析、攻击树、DREAD评分	ISO 14971 + AAMI TIR57
CYB-004	安全架构设计文档	纵深防御策略、加密方案、认证架构	IEC 81001-5-1 Clause 5
CYB-005	SBOM	所有第三方和开源组件清单	CRA Annex I；NTIA Minimum Elements
CYB-006	安全测试报告	渗透测试、漏洞扫描、模糊测试结果	OWASP Testing Guide
CYB-007	安全更新与补丁管理计划	安全更新发布流程、时限承诺	MDCG 2019-16 Section 4.4
CYB-008	残余风险声明	未能完全消除的网络安全风险及缓解建议	ISO 14971 Clause 8
CYB-009	用户安全指南	安装配置指南、安全使用说明	GSPR 14.2(d)
CYB-010	上市后网络安全监控计划	漏洞监控、CVD政策、EOL计划	MDCG 2019-16 Section 5

9.2 公告机构审查要点

基于行业实践，以下是公告机构在审查网络安全文档时最常关注的领域：

审查重点	常见不足	建议做法
威胁建模的完整性	威胁场景覆盖不全，遗漏物理接口或供应链威胁	使用STRIDE系统化方法覆盖所有威胁类别
风险控制的可追溯性	安全需求与风险之间缺乏双向追溯	建立安全需求追溯矩阵
渗透测试的独立性	由开发团队自行执行渗透测试	聘请独立第三方安全公司执行
SBOM的完整性	遗漏间接依赖（transitive dependencies）	使用自动化工具生成SBOM
上市后计划的具体性	计划过于笼统，缺乏时限承诺	明确漏洞响应时限和补丁发布SLA

十、上市后网络安全义务

10.1 多重义务来源

欧盟医疗器械制造商的上市后网络安全义务来自多个法规层面：

义务来源	核心要求	报告对象
MDR Article 87	严重不良事件报告（网络安全事件导致的患者伤害）	成员国主管当局
MDR Article 88	现场安全纠正措施（FSCA）——含安全补丁发布	主管当局 + 用户
MDR Article 83-86	PMS/PMCF体系须涵盖网络安全监控	技术文件更新
NIS2 Article 23	网络安全事件报告（24/72小时/1个月分阶段）	CSIRT或主管当局
MDCG 2019-16	持续漏洞监控、安全更新发布、EOL管理	技术文件更新

10.2 漏洞管理流程

建议中国制造商建立以下漏洞管理流程以满足欧盟要求：

第一步：漏洞监控

订阅CVE/NVD漏洞数据库更新
监控SBOM中所有组件的安全公告
配置自动化漏洞扫描工具定期扫描
关注CERT/CC和ICS-CERT的医疗器械安全通告

第二步：漏洞评估

使用CVSS v3.1/v4.0评估漏洞严重程度
评估漏洞的可利用性（是否存在公开的PoC代码）
评估漏洞对器械安全性和有效性的实际影响
确定受影响的产品版本和用户范围

第三步：补丁开发与验证

开发安全补丁并进行回归测试
评估补丁是否构成MDR下的"重大变更"（需通知公告机构）
如构成重大变更，须在发布前完成公告机构评审

第四步：安全通告与补丁发布

向用户发布安全通告（含风险描述、缓解措施、补丁安装指南）
如涉及患者安全风险，向主管当局提交现场安全通知（FSN）
同步触发NIS2事件报告流程（如适用）

第五步：验证与关闭

跟踪补丁安装率
验证补丁效果
更新SBOM和技术文件中的漏洞状态
记录整个处理过程作为PMS证据

10.3 产品生命终止（EOL）管理

EOL管理是欧盟审查中的高频关注点：

EOL管理要素	具体要求
EOL声明时间	建议至少提前12-24个月通知用户和公告机构
过渡期安全支持	EOL声明后仍须在过渡期内提供紧急安全更新
数据迁移方案	为用户提供数据导出和迁移工具
数据擦除指南	提供安全数据擦除的操作说明
替代产品推荐	如有后继产品，提供迁移路径指南

十一、中国制造商欧盟网络安全合规路线图

11.1 分阶段实施路线图

第一阶段：差距评估与规划（建议周期：2-3个月）

对照MDR GSPR 17.2/17.4和MDCG 2019-16要求进行网络安全差距分析
评估NIS2指令对企业的适用性（规模门槛、成员国转化法差异）
审查现有产品的网络连接能力和安全现状
确定需要外部支持的领域（渗透测试、安全架构咨询）
制定网络安全合规项目计划和预算

第二阶段：体系建设（建议周期：3-6个月）

建立网络安全管理流程（参照IEC 81001-5-1）
将网络安全纳入ISO 14971风险管理框架
建立SBOM管理工具和流程
开发安全编码规范和代码审查流程
建立漏洞监控和响应机制
制定安全更新发布流程
培训研发和质量团队

第三阶段：产品合规实施（建议周期：3-6个月）

完成产品威胁建模（STRIDE方法）
编写安全需求规格和安全架构设计文档
实施安全控制措施（加密、认证、安全启动等）
生成并维护SBOM
执行安全测试（渗透测试、漏洞扫描、模糊测试）
编写残余风险声明和用户安全指南
整合网络安全证据至技术文件

第四阶段：公告机构审查准备（建议周期：1-2个月）

内部审查网络安全技术文件的完整性
准备公告机构可能提出的网络安全问询应答
确保安全测试报告的独立性和时效性
验证IFU中的网络安全信息完整准确

第五阶段：上市后运营（持续）

启动漏洞持续监控
执行定期安全更新发布
维护协调漏洞披露（CVD）渠道
将网络安全事件纳入不良事件报告流程
定期更新技术文件中的网络安全证据
每年进行网络安全体系有效性评审

11.2 资源投入估算

投入项目	估算费用（欧元）	说明
IEC 81001-5-1差距分析与咨询	15,000-30,000	外部安全顾问
威胁建模与安全架构设计	20,000-50,000	视产品复杂度
独立渗透测试	10,000-30,000/次	建议每年至少一次
SBOM工具部署	5,000-15,000/年	商业工具许可费
安全团队培训	5,000-10,000	初始培训费用
上市后漏洞监控	10,000-20,000/年	工具+人力
总计（首年）	65,000-155,000	视产品数量和复杂度

十二、常见不符合项与规避策略

12.1 公告机构审查中的高频不符合项

序号	不符合项描述	出现频率	根本原因	规避策略
1	网络安全风险未纳入ISO 14971风险管理文件	极高	网络安全和产品安全由不同团队负责	在风险管理计划中明确包含网络安全范围
2	威胁建模缺失或覆盖不完整	高	缺乏系统化威胁分析方法	采用STRIDE方法论，逐一覆盖六类威胁
3	缺少独立安全测试证据	高	预算限制或认知不足	至少在提交前进行一次独立渗透测试
4	SBOM不完整或版本信息缺失	中高	手动维护SBOM，遗漏间接依赖	使用自动化工具（如Syft、Trivy）生成
5	IFU中缺少IT环境安全要求	中高	产品说明书编写未涵盖网络安全章节	在IFU中增加专门的网络安全配置章节
6	上市后网络安全计划过于笼统	中	计划编写时缺乏具体操作细节	明确漏洞响应时限、更新频率、EOL计划
7	安全更新机制未经验证	中	更新机制本身的安全性未被测试	对OTA/安全更新通道进行专项安全测试
8	缺少残余风险声明	中	认为应消除所有风险而非披露残余风险	坦诚披露残余风险并提供缓解建议

12.2 中国企业特有的合规难点

难点	说明	解决方案
安全意识差距	网络安全在产品开发中的优先级不够	管理层培训+安全左移（Shift-Left Security）
安全测试能力	缺乏具有医疗器械经验的安全测试人员	与专业安全公司合作（如Eurofins、SGS、TUV）
英语文档能力	网络安全文档须为英文，技术术语要求高	聘请有安全背景的技术翻译或咨询公司
加密算法合规	部分中国常用算法（SM2/SM3/SM4）不在欧盟认可范围	同时支持国际标准算法（AES-256、RSA-2048、SHA-256）
跨时区漏洞响应	NIS2要求24小时内早期预警	建立欧盟本地或授权代表的初始响应能力

十三、案例分析与实践示例

13.1 案例一：联网患者监护仪的欧盟网络安全合规

产品概况：某中国制造商的多参数患者监护仪，具备Wi-Fi和以太网连接，可将数据传输至中央监护站和医院HIS系统，分类为MDR Class IIb。

网络安全合规挑战与解决方案：

挑战	解决方案
监护仪与中央站之间的数据传输安全	实施TLS 1.3加密通信；双向证书认证
多用户权限管理	基于角色的访问控制（RBAC）；支持与医院LDAP/AD集成
固件更新安全	实施安全启动（Secure Boot）；OTA更新使用代码签名验证
操作系统漏洞	基于嵌入式Linux定制最小化OS；建立定期安全补丁发布机制
物理接口安全	USB端口默认禁用数据传输；仅支持经认证的外部设备

技术文件关键文档：

威胁模型涵盖48个威胁场景（STRIDE方法）
由第三方安全公司完成渗透测试（发现并修复12个漏洞）
SBOM包含267个软件组件（使用CycloneDX格式）
IFU包含8页网络安全配置指南

结果：公告机构审查中收到3个网络安全相关问询，经补充文档后顺利通过审查。

13.2 案例二：云端SaMD的MDR网络安全合规路径

产品概况：某中国企业开发的基于云的医学影像AI辅助诊断系统（SaMD），分类为MDR Class IIa，部署于AWS欧洲区域。

特殊合规考量：

考量要素	合规策略
云基础设施安全	要求AWS提供SOC 2 Type II报告和ISO 27001证书作为供应商评估证据
数据跨境传输	确保患者数据处理在EU区域完成；与AWS签订数据处理协议（DPA）
API安全	实施OAuth 2.0 + OIDC认证；API速率限制；输入验证
AI模型安全	模型对抗鲁棒性测试；防止模型投毒和数据泄露攻击
多租户隔离	确保不同医疗机构的数据严格隔离
持续部署安全	CI/CD管道中集成安全扫描（SAST/DAST/SCA）

13.3 案例三：NIS2事件报告的实操场景

场景：某中国制造商的联网输液泵被发现存在远程代码执行漏洞（CVSS 9.8），安全研究人员通过CVD渠道报告。

合规响应时间线：

时间点	行动	法规依据
T+0小时	接收漏洞报告，启动内部评估	MDCG 2019-16 CVD政策
T+4小时	确认漏洞真实性，评估影响范围	内部漏洞管理流程
T+12小时	开发临时缓解方案（禁用远程管理端口）	风险控制优先
T+24小时	向CSIRT提交NIS2早期预警	NIS2 Article 23(4)(a)
T+48小时	向主管当局提交FSN草稿	MDR Article 87/88
T+72小时	提交NIS2事件通知（含IoC和影响评估）	NIS2 Article 23(4)(b)
T+14天	发布安全补丁，发出最终FSN	MDCG 2019-16 补丁管理
T+30天	提交NIS2最终报告（含根因分析）	NIS2 Article 23(4)(d)

十四、关键法规资源与参考文献

资源	链接/编号	说明
MDR 2017/745	Regulation (EU) 2017/745	欧盟医疗器械法规全文
MDCG 2019-16 rev.1	MDCG 2019-16 rev.1	医疗器械网络安全指南
NIS2指令	Directive (EU) 2022/2555	网络与信息系统安全指令
CRA	Regulation (EU) 2024/2847	网络弹性法案
IEC 81001-5-1:2021	IEC 81001-5-1 Ed.1	健康软件产品安全标准
IEC 62304:2006+A1:2015	IEC 62304	医疗器械软件生命周期
ISO 14971:2019	ISO 14971 Ed.3	医疗器械风险管理
AAMI TIR57:2016/(R)2019	AAMI TIR57	医疗器械安全风险管理原则
ENISA医疗器械网络安全指南	ENISA Procurement Guidelines	医院采购网络安全要求参考

总结

欧盟医疗器械网络安全合规的复杂性在于其多层叠加的法规架构——MDR提供产品安全基础，MDCG 2019-16细化执行要求，NIS2施加组织治理义务，CRA拉高整体供应链安全基线。对于中国医疗器械企业而言，应对这一挑战的核心策略可概括为三点：

第一，建立统一的网络安全管理体系。以IEC 81001-5-1为骨架，同时覆盖MDR产品安全要求和NIS2组织安全要求，避免为不同法规分别建立独立的合规体系。

第二，安全左移（Shift-Left Security）。将网络安全融入产品开发最早期阶段——从需求分析开始就进行威胁建模，而不是在提交技术文件前临时补写安全文档。后者不仅成本更高，而且极易被公告机构识别为形式化合规。

第三，建立持续运营能力。网络安全合规不是一次性项目而是持续运营义务。从SBOM维护、漏洞监控、补丁发布到NIS2事件报告，都需要建立常态化的流程和团队能力。对于在欧盟没有本地团队的中国企业，建议与欧盟授权代表或专业服务商合作建立本地安全响应能力。