夜雨聆风
9月11日先到：欧盟《网络韧性法》下旧产品与软件更新责任
2026-07-30 | Frank Qin Legal Notes
向欧盟销售软件、联网设备和工业数字产品的企业，首先需要面对的不是2027年的全面符合性节点，而是2026年9月11日启动的制造商直接报告义务。届时，部分已经停产或停止支持的产品仍在责任范围；企业一旦对主动利用漏洞或严重事件形成合理确信，24小时内即须启动早期预警，并同步处理用户通知。产品、研发、安全、售后与法务是否能够围绕同一版本迅速决策，已成为管理层需要提前验证的经营能力。
2026年7月27日，欧盟委员会发布《网络韧性法》实施指南，以67个实例解释产品范围、重大修改、支持期、风险评估和报告义务。指南不具有约束力，但为企业理解正式条例提供了目前最具体的官方路径。
一、先确认产品是否进入规则范围
欧洲议会和欧盟理事会制定的Regulation (EU) 2024/2847，即《网络韧性法》（Cyber Resilience Act，CRA），已于2024年12月10日生效。其主要义务自2027年12月11日起适用；第四章关于符合性评估机构通知的规则已于2026年6月11日适用；本文所涉制造商第14条直接报告义务则自2026年9月11日适用。
CRA所称“含数字元素产品”，包括软件、硬件及其特定远程数据处理方案。产品在欧盟市场商业供应，且预期用途或合理可预见使用包含与设备或网络直接或间接的数据连接，才进入第2条的一般范围。医疗器械、部分车辆、经适航认证产品、船用设备、同规格备件、国防或涉密产品等存在明文排除；其他行业规则也可能限制CRA适用。因此，“软件出海”或“联网设备”只是筛查起点，并非最终法律结论。
二、旧产品纳入报告，但不等于无限追溯
CRA第69条规定，第14条报告义务适用于2027年12月11日前已经投放欧盟市场的范围内产品。已停产设备、旧版企业软件和经销渠道中的历史型号，不能仅因不再销售而从事件响应台账中消失。委员会指南还解释，报告义务可以在漏洞处理支持期结束后继续。
这一结论有明确边界。指南第217段指出，制造商在2026年9月11日前已经知悉某漏洞正在被主动利用的，CRA不要求追溯报告。若此前只知道漏洞存在，但主动利用在9月11日后才发生，或者制造商届时才知悉主动利用，则仍会进入报告义务。企业需要保留的是可执行的存量产品责任链，而不是对所有历史漏洞作无边界倒查。
这会直接影响档案清理和停售安排。产品停止支持后，企业或许不再承担同样的漏洞修复义务，却仍可能需要识别具体版本、法律意义上的制造商、受影响客户和欧盟监管报送入口。过早删除这些信息，可能使24小时报告机制失去事实基础。
三、一次软件更新何时改变产品身份
CRA第3条将“重大修改”定义为产品上市后的变更，且该变更影响其对附件I基本网络安全要求的符合性，或者改变产品原先接受评估时的预期用途。委员会指南结合条例序言第41段解释，重大修改后的产品再次供应市场时，可能按新产品和新的上市行为处理。对于2027年12月11日前已经上市的产品，CRA第69(2)条同时限定：主规则是在该日以后发生重大修改时才适用。
指南给出的商业判断并不是代码量或版本名称，而是风险轮廓是否变化。一个原本只展示机器状态的工业仪表盘，更新后若可以调整参数或重启设备，产品已从观察工具转为控制工具。一个“保持登录”功能看似有限，却可能引入令牌盗取和会话劫持等新风险。相反，群聊功能若在原始架构和风险评估中已经被真实预见，相应路由、管理和审核风险已有控制，后续启用未必构成重大修改。
安全更新同样不能只看标签。修复输入验证、关闭闲置端口且不改变用途或引入新风险，通常只是降低既有风险；若企业为修复本地加密问题，改为把文件上传至远程服务处理，数据流、产品边界和外部依赖已经改变，仍可能构成重大修改。
笔者认为，风险评估正在由上市附件转变为产品迭代的边界文件。企业能否证明新功能仍在原合规边界内，取决于产品路线图、架构图、威胁模型、版本说明、测试记录和发布审批能否互相印证，而不是风险评估中是否写有宽泛的“未来扩展”表述。由此，重大修改判断应当成为版本发布审批的一部分；结论不清时，发布排期本身可能需要调整。
四、白标和集成责任需要分阶段判断
CRA第3(13)条将自行开发、生产，或者委托他人设计、开发、生产并以自己名称或商标营销产品的主体定义为制造商。这一定义是判断2026年9月报告主体的起点。白标方即使没有实际生产产品，也不能仅凭合同把法定制造商身份交给原厂。
CRA第21、22条自2027年12月11日起一般适用，届时还将进一步明确：进口商、分销商以自己名称或商标销售产品，或者对已上市产品作重大修改，以及其他主体重大修改后重新供应产品时，将承担制造商义务。合同中的“分销商”“集成商”称谓不能取代实际品牌、改造和上市事实。
如果企业采购芯片、连接组件，加入自有固件和传感器并以自己名义推出整机，它通常从一开始就是新产品制造商，而不只是他人产品的修改者。指南也保留比例边界：重大修改只影响可识别部分且不影响整体网络安全时，新增责任可集中于该部分；影响整体风险时，责任可能覆盖整个修改后产品。能否沿用原厂测试和技术文件，最终取决于技术影响范围的证据。
五、支持期与报告期采用不同逻辑
CRA第13条要求支持期反映产品预期使用时间。原则上至少五年；产品确有证据表明预期使用少于五年时，可以按预期使用期确定；合理预期使用更长的工业设备、网络设备或软件，则应设置更长期间。因此，五年既不是无例外的最低期，也不是所有产品可直接套用的统一答案。
支持结束年月须在购买时清楚说明，这使支持承诺进入产品定价、渠道材料、工程资源和售后预算。一次重大修改需要重新审查支持期，却不必然自动重置完整五年；关键在于预期使用时间是否改变。
报告义务沿另一条时间轴运行。支持结束可能改变漏洞处理责任，却不当然终止符合条件的监管报告和用户通知。企业为停售产品保留何种记录、保留多久，还应与数据保护和成本控制一并评估，而不能简单沿用“支持结束即全部删除”的售后逻辑。
六、24小时是最迟期限，不是等待期
第14条的触发标准需要准确区分。被主动利用漏洞，是有可靠证据证明恶意行为人未经系统所有人许可，已经在系统中利用该漏洞。严重事件则须达到两类标准之一：产品保护敏感或重要数据或功能的可用性、真实性、完整性或保密性的能力受到或可能受到负面影响；或者事件已经或可能导致恶意代码进入、运行于产品或用户网络信息系统。普通漏洞、在本产品中不可达或尚未被利用的第三方组件漏洞，并不当然构成强制报告事件。
达到标准后，24小时早期预警和72小时进一步通知均须不得无故拖延，24小时与72小时只是最迟期限。漏洞最终报告在纠正或缓解措施可用后14日内提交；严重事件最终报告在72小时通知后一个月内提交。指南把“知悉”解释为及时完成初步评估并形成合理程度确信之时，不要求企业先完成根因调查。
监管报告也不是全部流程。第14(8)条要求制造商通知受影响用户，适当时通知全体用户，并告知可采取的缓解或纠正措施。指南强调通知应按风险和比例进行，不等于公开披露全部技术细节；在敏感环境中，企业可以把必要信息限定给相关客户。由谁判断用户范围、通过何种渠道发送、如何与监管材料保持一致，都应在事件发生前确定。
七、管理层需要完成一次真实演练
到9月11日前，更现实的目标不是提前完成2027年的全部符合性工作，而是形成一条可以计时验证的决策链。企业应由一名责任高管牵头，先按欧盟存量规模、联网暴露和客户重要性选出首批产品；产品、研发、安全、售后和法务围绕同一型号及版本，打通品牌主体、风险评估、修改记录、支持终点、关键组件、客户范围、监管入口和用户通知渠道。
随后应当用一条模拟安全线索做真实计时演练：何时完成初步评估，谁形成报告判断，24小时材料如何提交，受影响用户由谁通知，版本发布是否需要暂停。演练结果应回写事件预案和发布审批，而不是停留在会议纪要中。
CRA第64条对第13、14条违规设置最高1500万欧元或上一财年全球年营业额2.5%的行政罚款上限，以较高者为准；具体处罚由成员国规则和个案决定。微型和小型企业错过24小时早期预警期限有特定行政罚款例外，但并不免除基础报告义务；开源软件管理者另有明文罚款例外。对多数企业而言，眼前更直接的经营问题仍是：安全线索出现时，能否在法定最迟期限前把技术事实转化为管理决策。
官方法源
欧盟委员会指南发布页：
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
欧盟委员会《网络韧性法》实施指南附件：
https://ec.europa.eu/newsroom/dae/redirection/document/131456
Regulation (EU) 2024/2847正式文本：
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847
作者简介
秦国梁（Frank Qin），曾在国际知名头部律所、国内头部律所及高盛拥有争议解决、知识产权、企业合规、投融资上市、商业谈判与企业出海等领域的丰富实务经验。本文仅为一般性法律与商业信息分享，不构成针对具体事项的法律意见或法律服务承诺。
