本文聚焦于2026年医疗技术领域一个广受误解的关键时间节点:2026年9月11日。届时,欧盟《网络韧性法案》的强制性事件和漏洞报告要求将正式生效。该日期是否直接影响您的组织,取决于一些许多企业尚未充分梳理的具体适用条件。该法案中的医疗器械排除条款确实存在,但它有明确的界限,许多医疗器械制造商在不自知的情况下就落在了这条边界的错误一边。

与此同时,FDA于2026年2月3日发布了关于医疗器械网络安全的最终指导。该指导引入了更新的上市前提交要求,并重新定义了软件材料清单在实际中必须包含的内容。欧盟与美国的监管框架正朝着相似的方向发展。对于仍将这些要求视为相互独立的合规事项,企业可能面临文件和流程方面的衔接空白,而这些监管缺口也越来越容易被大西洋两岸的监管机构识别。

欧盟网络韧性法案:医疗器械的实际定位

《欧盟网络韧性法案》(条例(欧盟)2024/2847)于2024年12月10日生效。该法案为在欧盟市场上销售的数字元素产品设定了强制性的网络安全要求。该法规的实施分阶段进行:2026年9月11日启动事件和漏洞报告义务。全面符合标准和CE认证要求要到2027年12月11日才适用。

根据欧盟MDR(欧盟条例2017/745)及体外诊断(欧盟IVDR法规,2017/746)监管的医疗器械不属于CRA的直接适用范围。其理由很简单:MDR和IVDR已经在其安全和性能框架中对网络安全施加了行业要求。监管机构不希望在同一产品上叠加两个合格评估流程。

许多制造商犯的错误是把这种排除范围看得太宽泛。排除条款涵盖的是你受监管的医疗器械。它并不会自动扩展到你组织或供应链中的其他所有方面。

 

排除并未弥合的三个缺口

第一个空白是非设备数字产品组合。许多医疗器械制造商还销售支持其受监管设备的软件工具、患者参与应用、连接配件或数据管理平台,但这些设备本身并不被归类为MDR或IVDR下的医疗器械。这些产品直接属于CRA的监管范围。自2026年9月11日起,任何已在欧盟市场上的此类产品都需承担事件和漏洞报告义务。那些没有绘制完整产品组合以确定哪些产品属于MDR范围的制造商,几乎肯定存在未解决的CRA风险。

第二个缺口是供应链。自2026年9月11日起,受CRA监管的供应商,包括软件组件供应商、连接硬件子系统制造商和现成软件供应商,必须通过ENISA单一报告平台向ENISA和国家计算机安全事件响应团队(CSIRTs)报告被积极利用的漏洞。报告时间表为:识别出被利用漏洞后提前预警24小时,完整通知72小时,修复后14天内提交最终报告。即使您的医疗设备被排除在CRA之外,您仍会收到CRA监管供应商的漏洞通知。你需要一个有文档的流程来接收、评估并回复这些通知。大多数量子管理系统默认不存在该过程。

第三个空白是MDR附录I本身。MDR附件I第17.2节要求软件医疗设备必须按照技术最新水平设计和开发,明确承担涵盖网络安全风险管理、信息安全和安全措施验证的义务。欧盟委员会正在积极咨询针对性的MDR修订,以使该法规更贴近CRA的规范。制造商应预期这些修订将正式化符合CRA 24小时全天候框架的事故报告要求。现行MDR要求与CRA之间的差距在实践中已在缩小,且在法律中还将进一步缩小。

 

ISO 22301 Zertifizierung

 

FDA 2026年2月最终指导:SBOM要求具有实际分量

2026年2月3日,FDA发布了最终指导:“医疗器械中的网络安全:质量体系考虑及上市前提交内容。”该指导适用于《食品、药品及化妆品法》第524B条定义的“网络设备”,该类别涵盖包含软件、具备网络连接能力并具备数据发送或接收能力的设备。

该指导对盘前提交预期进行了多项更新。操作上最为复杂的是软件物料清单的要求。FDA现在期望SBOM提交510(k)、De Novo或PMA时,列出所有带有版本号和已知漏洞的软件组件,涵盖开源组件、商用现成软件和专有代码。FDA推荐使用机器可读格式,如SPDX或CycloneDX。由一位工程师维护的电子表格不符合这一标准。

该指导还明确了《网络安全管理计划》的期望,该文件描述制造商在整个设备生命周期内如何监控、识别和应对上市后网络安全漏洞。该计划是上市前提交的要求。FDA评审员会在批准或批准该器械前进行评估。对于历来将盘后网络安全监控视为非正式活动的组织,2026年2月的指导将这种非正式行为转化为有记录的盘前风险。

该指导还涉及预定变更控制计划(PCCP)框架下的人工智能组件。对于使用AI/ML算法且许可后会变化的设备,SBOM必须在传统软件的同时捕获AI模型组件。预计CDRH将在2026年底发布专门针对AI设备的额外指导,并可能进一步扩展这些要求。

 

为两个框架构建一个 QMS 流程

这两大框架——欧盟CRA/MDR和FDA 524B条款——共享四个核心要求,成熟的量子质量管理系统可以通过统一方法而非平行路径来应对。

维护的、可机器读取的SBOM是基础。无论该要求来自FDA 2026年2月的指导,还是CRA对您产品组合中CRA监管产品的预期,底层数据都是相同的:每个软件组件、版本号以及产品中已知的漏洞。为下一次510(k)提交建立SBOM流程的组织,同时也在建设应对CRA时代供应链披露所需的能力。

第二个要素是与上市后监测计划相关联的有文档的脆弱性接收流程。根据ISO 13485和QMSR(21 CFR Part 820),PMS已经是必需的流程。将该流程扩展到捕获、评估和响应来自CRA监管供应商的网络安全漏洞披露,是现有程序的附加程序,而非新系统。

第三是将网络安全风险管理集成于ISO 14971风险管理文件中。MDR附录I第17.2节已经指出这一点。风险管理文件应记录网络安全风险、其被利用概率及潜在的临床后果。这与应用于软件攻击面的设备安全风险分析结构相同。

第四是将网络安全管理计划视为一份活的质量管理系统文件。FDA的指导明确指出,这不能是一次性的上市前伪影。应进行版本控制,按规定间隔审查,并在组件变更或新漏洞披露改变风险图景时及时更新。你的QMS已经要求的文档控制流程是正确的工具。

 

DQS观察

欧盟委员会针对MDR的定向修订工作仍在进行中。目前正在积极讨论的提案之一是将MDR事件报告要求正式与CRA的时间表保持一致。质量和监管团队应在未来90天内监控委员会公布的咨询回应。拟议的修订将表明医疗设备的网络安全报告预计能多快达到24小时标准。

FDA人工智能设备指导,预计于2026年底发布。CDRH表示,关于人工智能医疗设备的更多指导即将出台。2026年2月的网络安全指导针对PCCP背景下的人工智能组件进行了讨论。新指导可能会将SBOM的期望扩展到AI模型组件、训练数据集和验证工件。整合机器学习的医疗器械制造商应开始跟踪这些数据,并在指导生效前扩展现有的SBOM流程以捕捉AI组件。

欧盟人工智能法案与MDR文档有重叠。对于那些采用《欧盟人工智能法案》(欧盟条例2024/1689)中高风险AI系统的制造商来说,与MDR附件I要求的交叉构成了文档难题。欧盟人工智能法案带来了自身的技术文件义务和合规性评估流程。通知机构已开始在MDR技术文件审查中加入有关AI法案合规性的问题,以备正式合并要求的到来。制造商应在其MDR技术文件结构与《人工智能法案》要求的文件进行对应,以便下一次通知机构审计。

作者

DQS GC

DQS是德国第一家获得政府认可的认证机构,成立于1985年,在全球60多个国家设有办公室,拥有3000余名专业审核员,已颁发超过65000份证书。并在中国设有本地团队,为企业提供全流程本地化支持。

Loading...