NEWVenvera 支持您的语言: 完整平台支持英语、德语、西班牙语、保加利亚语、阿拉伯语和简体中文。查看新功能 →
欧盟《网络弹性法案》罚款与处罚
合规指南

欧盟《网络弹性法案》罚款与处罚

·Alexander Sverdlov

欧盟《网络弹性法案》(CRA)规定的罚款上限为 1500 万欧元或全球年度总营业额的 2.5%,以较高者为准。这一上限适用于该条例视为最严重的违规行为:未满足附件 I 中的基本网络安全要求,以及未履行第 13 条规定的制造商义务或第 14 条规定的报告义务。在其之下还有两个较低的档位,分别为 1000 万欧元或 2%,以及 500 万欧元或 1%。

罚款的结构比醒目的上限数字更重要。第 64 条并不按漏洞的严重程度来确定罚款档位。它按您违反了哪项义务来确定档位。一家交付了有缺陷的产品但如实报告的制造商,与一家交付了同样产品却保持沉默的制造商,所处的境地截然不同。

最高罚款适用范围出处
1500 万欧元或 2.5%不符合附件 I 中的基本网络安全要求,以及不履行第 13 条和第 14 条规定的义务。Art. 64(2)
1000 万欧元或 2%不履行其他义务,包括第 18 条至第 23 条、第 28 条、第 30(1) 至 (4) 条、第 31(1) 至 (4) 条、第 32 条、第 33(5) 条,以及第 39、41、47、49 和 53 条。Art. 64(3)
500 万欧元或 1%在答复请求时,向公告机构或市场监管机构提供不正确、不完整或具有误导性的信息。Art. 64(4)

在每个档位中,上限均为固定金额与营业额百分比两者中的较高者,因此,对于全球营业额超过 6 亿欧元的任何公司,在最高档位中真正起约束作用的是百分比。

欧盟《网络弹性法案》第 64 条规定的三档罚款上限:1500 万欧元或 2.5%,1000 万欧元或 2%,以及 500 万欧元或 1%

CRA 规定了哪些罚款?

共有三档上限,由第 64 条设定,并由各国主管机构适用。该条例设定最高额;各成员国制定罚则并负责执行,这意味着实际处以的罚款金额,是各国在欧盟设定的上限范围内作出的决定。

第 64(5) 条列出了主管机构必须考量的因素:违法行为的性质、严重程度、持续时间及其后果;同一或另一市场监管机构是否已因类似违法行为对同一经营者处以罚款;以及经营者的规模和市场份额,其中明确提到了微型企业和中小企业(包括初创企业)。小型制造商首次发生、主动报告并迅速纠正的违规,并不是这一上限所针对的情形。

哪些违规适用最高档罚款?

有三类,值得准确区分,因为已发布的各类摘要恰恰在这一点上含糊不清。

附件 I:基本网络安全要求

第 I 部分涵盖产品属性:交付时不存在已知的可被利用的漏洞、默认安全、能够接收安全更新。第 II 部分涵盖漏洞处理:软件物料清单(SBOM)、协调披露,以及及时分发安全更新。

第 13 条:制造商义务

网络安全风险评估、合格评定、技术文档、支持期,以及在产品的整个生命周期内(而不仅仅是在销售时)保持产品合规的义务。

第 14 条:报告

被积极利用的漏洞以及影响产品安全的严重事件必须报告:24 小时内发出早期预警,72 小时内提交更完整的通知。这是最有可能率先被违反的义务,因为它自 2026 年 9 月 11 日起生效,远早于该条例其余部分的适用时间。

有一项范围很窄的豁免:根据第 64(10)(a) 条,微型企业和小型企业如错过第 14(2)(a) 条或第 14(4)(a) 条规定的具体截止期限,不予罚款。报告义务依然存在;只是不适用针对迟报的罚款。

欧盟《网络弹性法案》最高罚款档位涵盖的内容:附件 I 第 I 部分和第 II 部分、第 13 条规定的制造商义务,以及第 14 条规定的报告时限

由谁处以罚款?

由各成员国指定的国家市场监管机构处以罚款,而不是欧盟委员会。实际上,这意味着您的产品在哪个成员国上市,该成员国的主管机构就可以采取行动;在整个欧盟范围内销售产品的制造商,可能会面临不止一个主管机构审查同一款产品。

根据第 14 条提交的报告,通过单一报告平台发送给被指定为协调者的 CSIRT 以及 ENISA,该平台是一个通报渠道,而非执法渠道。这一区别很重要:及时报告才能让您免于落入最高档位,而您报告的对象并不是对您处以罚款的机构。

在处以罚款之前,执法如何逐步升级?

罚款是一系列措施的终点,而不是第一步。市场监管机构通常会先评估产品,要求在规定期限内采取纠正措施;如果经营者不采取行动,则升级为限制产品在市场上的供应,然后是撤出市场或召回。行政罚款处于这一升级阶梯的末端。

实际结果是,在商业上真正令人痛苦的后果,通常比罚款来得更早。对于大多数制造商而言,针对在售产品下达的撤市令所造成的损失,比随后可能到来的罚款更大。

欧盟《网络弹性法案》的执法如何从市场监管审查开始,经由纠正措施和限制措施,逐步升级到撤出市场和行政罚款

CRA 罚款与 GDPR、NIS2 和 AI Act 相比如何?

低于那些备受关注的监管制度,而且是有意为之。欧盟《通用数据保护条例》(GDPR)的罚款最高可达全球营业额的 4% 或 2000 万欧元。欧盟《人工智能法案》(EU AI Act)针对被禁止行为的罚款最高可达 7% 或 3500 万欧元。欧盟 NIS2 指令针对基本实体的罚款最高可达 2% 或 1000 万欧元。欧盟《网络弹性法案》(CRA)介于 NIS2 和 GDPR 之间,为 2.5% 或 1500 万欧元。

真正重要的比较不在于上限,而在于重叠。一次事件可能同时触及多个监管制度:通过存在漏洞的产品造成的个人数据泄露,既是 GDPR 问题,也是 CRA 问题,由不同的主管机构依据不同的规则进行评估。一次性映射 CRA、GDPR 和 NIS2 之间的重叠,比在事件发生时才发现要省钱得多。

欧盟《网络弹性法案》最高罚款与 GDPR、NIS2 和 EU AI Act 罚款上限的对比,以占全球年营业额的比例表示

其他搜索结果错在哪里

最常见的错误是把最高档位当作唯一的档位来介绍。大多数已发布的摘要开篇就写 1500 万欧元或 2.5%,然后就此打住,这让读者以为任何违反 CRA 的行为都会带来这样的风险敞口。事实并非如此:1000 万欧元这一档涵盖的义务清单要长得多,而且除制造商以外的大多数经营者遇到的正是这一档。

第二个错误是把上限描述为 1500 万欧元或 2.5%,以较低者为准。实际上是以较高者为准。对于大型制造商而言,欧元金额根本不是相关的数字。

第三个错误是遗漏了针对中小企业的规定。第 64(5) 条中与企业规模相关的考量因素,以及第 64(10)(a) 条中范围很窄的豁免,都会改变较小制造商的实际风险敞口,而大多数摘要对这两点都只字未提。

评估您自身的风险敞口

请填写下表。目的不是得出一个数字,而是弄清楚您最可能出现的违规情形属于哪个档位。

问题您的回答涉及的档位
您的全球年度总营业额是多少?超过 6 亿欧元时,起约束作用的是百分比,而不是欧元上限。
您是制造商,还是进口商或分销商?第 13 条规定的制造商义务属于最高档。第 19 条至第 23 条规定的进口商和分销商义务属于 2% 档。
以目前的情况,您能否在 24 小时内提交第 14 条规定的早期预警?最高档。自 2026 年 9 月 11 日起生效。
您是否具备 SBOM 和协调披露流程?附件 I 第 II 部分,最高档。
您是否属于微型企业或小型企业?第 64(10)(a) 条对第 14 条截止期限的豁免,以及根据第 64(5)(c) 条对企业规模的考量。

如果大多数行都是空白,那么有用的下一步不是寻求法律意见,而是建立基线。我们关于欧盟《网络弹性法案》(CRA)合规时间表的指南阐述了弥补这些差距实际需要做些什么,而免费合规检查可以为您提供一个起点。

关于欧盟《网络弹性法案》罚款的结论:罚款针对的是未按时提交的报告,而不是漏洞本身

常见问题

CRA 的最高罚款是多少?

违反附件 I 或第 13 条和第 14 条的,最高罚款为 1500 万欧元或全球年度总营业额的 2.5%,以较高者为准。

我们会在 2027 年 12 月之前被罚款吗?

会。第 14 条规定的报告义务自 2026 年 9 月 11 日起适用,且属于最高罚款档位。该条例的其余部分自 2027 年 12 月 11 日起适用。按日期逐一列出的完整说明,请参阅我们关于 CRA 罚款与截止期限的指南。

开源开发者是否面临风险?

通常不会。在商业活动之外提供的自由和开源软件不在经营者义务的范围内,而且该条例为开源软件管理者设立了一个监管较轻的角色。如果您以商业方式将产品投放市场,您所集成的组件就由您负责。

一次事件是否只对应一笔罚款?

不一定。不同成员国的主管机构可以针对同一产品采取行动,而且单一事件在触及 CRA 的同时,还可能触及欧盟《通用数据保护条例》(GDPR)或欧盟 NIS2 指令规定的义务,这些义务会被分别评估。

主动报告能否减少罚款?

它并不是列明的考量因素。第 64(5) 条考量的是违法行为的性质、严重程度、持续时间和后果,此前是否因类似违法行为被处以罚款,以及经营者的规模和市场份额。按时报告之所以重要,是因为迟报本身就属于最高档位的违规。

主要来源

罚款上限及各档位所涉义务取自 Regulation (EU) 2024/2847 第 64 条,以及第 13 条、第 14 条和附件 I。适用日期出自同一条例,背景信息则来自欧盟委员会关于欧盟《网络弹性法案》(CRA)的政策页面。欧盟《通用数据保护条例》(GDPR)、欧盟 NIS2 指令和欧盟《人工智能法案》(EU AI Act)的罚款上限对比数据,来自这些法规各自的罚则条款。在依赖任何数字之前,请先核实现行文本。

Alexander Sverdlov

Alexander Sverdlov

Venvera 首席执行官兼创始人

Alexander 是 Venvera 的创始人,在欧洲网络安全与合规领域拥有 20 多年经验。他曾为受监管的金融机构、金融科技公司和 SaaS 企业主导安全与风险项目,这些企业需要遵守 DORA、NIS2、GDPR、ISO 27001 和 EU AI Act。创立 Venvera 之前,他创办了进攻性安全咨询公司 Atlant Security,为 EU 和中东地区的客户开展渗透测试、红队演练和 ISO 27001 就绪项目。他的文章聚焦现代合规的跨框架实践:如何把一项控制措施映射到多项义务,电子表格会在哪里失灵,以及审计师真正坐下来之后,监管机构实际要求的是什么。

查看 Alexander 的更多文章 →

相关文章