网络韧性法案：销售数字化产品的企业将面临哪些变化

网络韧性法案（欧盟2024/2847号条例，简称CRA）是欧盟首部对在欧盟境内销售的“数字化产品”提出网络安全要求的法律，几乎涵盖所有包含软件或可联网的产品。该条例已于2024年12月10日生效，但主要义务要到2027年12月11日才正式生效。

之所以现在开始讨论，正是因为存在一个过渡期：设计和销售数字化产品的企业有时间进行调整，但部分中间节点（例如通报义务）在2026年就已经到期。

GiBSeS — 弄清楚CRA是否以及如何影响你的企业，是我们与开发联网产品的中小企业合作时进行的第一项诊断。

是指任何硬件或软件产品，其预期用途包括与设备或网络进行直接或间接、逻辑或物理上的连接。实际上包括联网设备（网络摄像头、路由器、智能家电、工业传感器、物联网设备），也包括单独销售的软件（应用程序、操作系统、程序库、固件）。

产品正常运行所必需的远程数据处理方案（例如设备的云端部分）同样包含在内。已受特定行业法规约束的产品则不在此列，例如大多数医疗器械、汽车和航空领域的产品。

GiBSeS — 最棘手的往往是弄清楚你的产品在哪里结束、服务从哪里开始：这是我们从一开始就帮助梳理清楚的区分。

CRA适用于在欧盟市场投放数字化产品的企业，具体义务因角色而异：制造商（设计或制造产品，或以自有品牌委托设计/制造的企业）承担最严格的义务；进口商（将非欧盟企业的产品带入欧盟的企业）需核实制造商是否已履行其职责；分销商则需在供应链中尽到应有的注意义务。

即使你只是以自己的品牌转售他人制造的产品，在该条例看来你也会被视为“制造商”。在想当然地认为义务属于别人之前，先弄清楚自己的角色是值得的。

GiBSeS — 准确界定你在供应链中的角色——制造商、进口商还是分销商——会彻底改变需要履行的义务清单，我们正是从这一点入手。

是的。CRA明确涵盖单独投放市场的软件，而不仅仅是嵌入在设备中的软件。因此，单独销售的应用程序、操作系统、固件、程序库和软件组件都包含在内。

关键在于该产品是在商业活动范围内被提供给欧盟市场的。分发方式（下载、许可、订阅）并不能让你免于承担相应义务。

GiBSeS — 对软件公司而言，“设计阶段即安全”的要求以及漏洞管理会直接影响开发流程：这是一项应该提前规划、而非临时应付的调整。

CRA的核心是两大类义务。第一，“设计阶段即安全”：产品必须基于风险评估，在设计、开发和实现阶段就确保达到适当的网络安全水平（例如：默认采用安全配置、保护数据、缩小攻击面）。

第二，贯穿整个生命周期的漏洞管理：及时发现并修复漏洞，发布安全更新（免费，且尽可能自动完成），维护软件物料清单（SBOM），并制定协调一致的漏洞披露政策。此外还需要技术文档、符合性声明和CE标志。

GiBSeS — 在没有专门安全部门的企业里，把这些原则转化为具体流程，正是我们协助中小企业开展的实际工作。

制造商必须在整个“支持期”内管理漏洞并提供安全更新，该期限应体现产品被合理预期使用的时长。通常这一期限不应短于五年；如果产品设计用途较短，支持期可以相应缩短，但必须明确告知。

支持期必须在购买时以购买者能够理解的方式告知。这会带来实实在在的经济影响，因为它要求你在数年内持续投入开发和安全资源。

GiBSeS — 确定支持期的长短既是技术选择，也是经济财务上的选择：我们会用具体的数字帮你权衡这一平衡点，避免过度承诺。

是的，但有一点很重要：这项义务并非针对每一个漏洞，而是针对被主动利用的漏洞以及影响产品安全的严重事件。在这些情况下，制造商必须在很短的时间内启动通报。

时限要求是：在得知问题后应在24小时内发出“早期预警”，不得无故拖延，随后在72小时内提交更完整的通报，最后提交最终报告。因此需要提前建立一套内部流程，一旦发生事件即可自动启动。

GiBSeS — 在真正用到之前就准备好符合24小时和72小时要求的通报流程，是最容易被低估的准备工作之一：最好提前进行演练。

通报通过欧盟层面协调统一的单一报告平台进行，涉及ENISA（欧盟网络安全局）以及被指定为联络点的国家级CSIRT（计算机安全事件响应小组）。实际操作中，你通过本国渠道进行通报，信息会被转发给相应的主管机构。

具体操作细节（使用哪个平台、对接哪个国家主管机构）由各成员国以及相关实施法案确定，因此当义务正式生效时，应核实所在国家的具体通报渠道。

GiBSeS — 提前确定所在国家正确的通报渠道，而不是等到事件发生时才手忙脚乱，是我们共同准备工作的一部分。

该条例已于2024年12月10日生效，但适用时间是分阶段的。主要义务——安全要求、CE标志、符合性声明——从2027年12月11日起适用。但在此日期之前，已有部分义务提前生效。

具体来说，被利用漏洞和严重事件的通报义务从2026年的一个提前日期开始适用（大约在2026年9月前后），而关于符合性评估机构的相关规定则提前几个月生效。由于部分具体日期可能会通过实施法案进一步明确，建议在临近截止日期时到官方渠道核实。

GiBSeS — 制定一份从2026年提前节点出发、而非从2027年才开始考虑的路线图，可以避免措手不及：这是我们首先要共同厘清的问题。

是真的，而且这一点很多人都会忽略。尽管CRA的大部分内容要到2027年底才正式生效，但被主动利用的漏洞和严重事件的通报义务在2026年就已提前适用。这意味着，在你需要满足产品的全部技术要求之前的几个月，你就必须准备好通报特定事件。

这是立法者刻意做出的安排：在整个合规体系全面运转之前，先确保真实威胁信息的流通渠道是安全的。这一中间节点的确切日期需要在官方渠道核实，但“通报义务先行”这一逻辑是确定无疑的。

GiBSeS — 区分2026年就需要落实的事项和可以从容为2027年准备的事项，正是我们帮助你理清的优先级问题。

是的：CRA将CE标志的要求扩展到了数字化产品，软件也不例外。CE标志表明产品符合该条例的要求；对于软件而言，当无法进行实体标注时，可以以数字形式加贴（例如在文档中或界面上）。

欧盟符合性声明是制造商以自身责任出具的文件，用以证明产品符合适用要求。该声明必须编制完成并随时供主管机构查阅，同时应附有技术文档，说明产品是如何达到符合性要求的。

GiBSeS — 准备一份扎实的技术文档和经得起推敲的符合性声明，并不像看起来那么简单：这是一项建立方法论的工作，一次到位后可在每款产品上重复使用。

这取决于产品的风险类别。对于绝大多数数字化产品，制造商自行进行符合性评估即可。而对于CRA所称的“重要”和“关键”产品这两个更敏感的类别（例如密码管理器、防火墙、VPN、操作系统、某些安全设备），则规定了更为严格的程序，某些情况下需要第三方符合性评估机构介入，或采用欧盟认证方案。

因此，从一开始就正确地对自己的产品进行分类至关重要，因为合规之路的繁重程度正取决于这一点。

GiBSeS — 产品分类是决定成本和时间的关键分岔点：在投入开发之前尽早核实清楚，是最有价值的诊断工作之一。

CRA按风险等级对产品进行分类。基础类别适用自我评估。“重要”产品（在条例中列出，分为两个等级）承担与安全相关的重要功能——比如浏览器、密码管理器、操作系统、路由器、防火墙、杀毒软件——需要执行更为严格的符合性程序。“关键”产品则是对整条供应链安全影响最为敏感的产品，可能需要强制性的欧盟认证。

这些类别清单可能会由欧盟委员会随时间更新，因此值得定期复核。

GiBSeS — 了解你的产品目前落在哪个类别——并持续关注清单是否发生变化——是我们帮助你持续把关的一部分工作。

在商业活动之外开发或提供的自由和开源软件，原则上不受CRA义务约束：非营利性的社区项目不会被视为商业制造商。但当开源软件被集成到商业产品中并投放市场时，情况就不同了：此时责任落在将最终产品商业化的一方身上。

该条例还引入了一个中间角色——“开源软件管理者”（以结构化方式支持用于商业场景的开源软件开发的组织），其承担的义务比真正的制造商更轻、也更为相称。

GiBSeS — 如果你的产品依赖开源组件，弄清楚供应链上谁对什么负责是一个需要提前理清的关键点，以免日后成为问题。

作为进口商，你只能将符合CRA要求的产品投放到欧盟市场。你必须核实非欧盟制造商是否已完成符合性评估、编制技术文档、加贴CE标志并提供使用说明。你还必须确保产品上标明了制造商和你自己的联系方式。

如果你有理由认为某产品不符合要求，就不能将其投放市场；如果事后发现风险，你必须采取行动并通知主管机构。实际上，你成为了境外制造商与欧洲市场之间的一道责任过滤层。

GiBSeS — 建立一套针对非欧盟供应商的核查清单，可以保护你免受那些最终需要由你来“背书”的产品拖累：这是一项值得系统化建立的把关机制。

是的，尽管你的义务比制造商要轻。作为分销商，你必须尽到应有的注意义务：核实产品是否加贴了CE标志，是否附有所需的文档和使用说明，以及制造商和进口商是否已履行各自的义务。

对于你明知或理应知道不符合要求的产品，你不能将其提供给市场；如果你发现了某种风险，必须予以配合，通知上游相关方，必要时还需通知主管机构。

GiBSeS — 即便是“较轻”的注意义务，也需要明确的检查标准：一次性定义清楚，就能避免日后逐案产生争议。

市场监管机构可以责令采取纠正措施，要求下架或召回产品，并禁止或限制其在欧盟市场上的供应。除了声誉损失之外，还可能面临数额相当可观的罚款。

因此风险不仅仅是罚款：更实际的是产品可能被要求下架，这会对营业额和客户关系造成经济上的冲击。监管决定由各成员国的国家主管机构负责作出。

GiBSeS — 评估真实的风险敞口——不只是理论上的罚款，还包括产品被下架的风险——是我们在做出任何决策之前进行的成本效益分析。

该条例设定了较高的罚款上限。违反基本安全要求以及制造商主要义务的，罚款最高可达1500万欧元或全球年营业额的2.5%（以较高者为准）。违反其他义务的，上限为1000万欧元或营业额的2%；向主管机构提供不准确或误导性信息的，最高可达500万欧元或营业额的1%。

这些都是最高金额：实际罚款数额由各国主管机构裁定，须考虑违规行为的严重程度、持续时间以及企业规模，并对中小企业和微型企业给予特别关注。你所在国家实际适用的具体金额取决于当地主管机构。

GiBSeS — 上限数字看起来很吓人，但真正有意义的问题是你自己实际面临多大风险：结合自身情况衡量真实风险，比单看最高罚款数字更有实际意义。

两者关注的内容不同，但相互补充。CRA规范的是产品安全：设计和销售硬件与软件的企业，必须使其产品安全并保持这种安全状态。NIS2指令规范的则是组织及其流程的安全：要求在被视为基础性或重要性行业中运营的主体采取网络风险管理措施。

简而言之：CRA关注的是你投放市场的产品，NIS2关注的是你的组织如何管理安全。一家企业可能因为不同方面同时受到这两部法规的约束。

GiBSeS — 弄清楚哪部法规因何种原因适用于你，可以避免重复合规和合规漏洞：这是我们以整合的方式帮你梳理清楚的工作。

两者可能同时适用，但作用层面不同。AI法案规范的是人工智能系统相关的风险（透明度、风险管理、高风险系统的义务）；CRA规范的是数字化产品的网络安全。因此，一款联网的AI产品可能既要满足CRA的安全要求，又要同时履行AI法案规定的义务。

立法者已努力协调这两部法规以避免重复，但在实践中，仍需针对具体产品逐案进行综合解读，才能弄清楚哪些要求适用于你的产品。

GiBSeS — 由独立顾问统筹兼顾AI法案和CRA两条战线、避免重复劳动，是一项实实在在的优势。

总体而言，CRA适用于在主要义务生效日期之后投放市场的产品。不过，对于在该日期之后被实质性修改的在售产品，以及需要保留的文档，也存在过渡性规则和特别注意事项。

此外，漏洞管理和通报义务与产品生命周期挂钩，因此不能想当然地认为现有的“产品库”完全不受影响。具体日期和过渡细节应根据实际情况在官方文本中核实。

GiBSeS — 盘点目前在售的产品、弄清楚哪些需要注意，是一个常常会带来意外发现的实际步骤：最好提前进行。

并不存在一个统一的数字：这取决于产品的复杂程度、风险类别、安全性在你的开发流程中已整合的程度，以及你需要保证的支持期长短。主要成本通常在于开发流程的调整（设计阶段即安全、SBOM、漏洞管理）、技术文档，以及对于高风险产品可能涉及的第三方介入。

好消息是，这其中很大一部分是流程上的“一次性”投入，之后可以在所有产品上重复使用。对中小企业而言，最昂贵的错误是拖到最后才应对，或者相对于实际风险过度投入。

GiBSeS — 根据实际风险来衡量投入——既不合规不足，也不过度设计——是我们处理合规问题的方式：先分析，后花钱。

具体分三步。第一，做盘点：列出你在欧盟市场投放的所有数字化产品，并针对每一款确定你的角色（制造商、进口商、分销商）。第二，做风险分类：核实自己属于基础类别、“重要”类别还是“关键”类别，因为这决定了合规之路的繁重程度。第三，评估差距：将你目前的开发流程、漏洞管理和文档情况，与CRA的要求进行对比。

在此基础上，制定一份兼顾2026年提前节点（通报义务）和2027年主要节点的路线图。目标不是立刻做完所有事，而是按正确的顺序做正确的事。

GiBSeS — 盘点—分类—差距分析，正是我们与生产型中小企业合作时所做的起步诊断，独立进行，不会将你绑定到某一项技术或某一家供应商。

是的。网络韧性法案（欧盟2024/2847号条例）遵循的是市场逻辑，而非注册地逻辑：无论制造商设立于何处，只要在欧盟市场投放“数字化产品”（可联网的硬件或软件），该条例就会适用。如果你的物联网设备、应用程序、固件或程序库在欧盟境内销售或提供，你就是该条例意义上的制造商，必须履行相应义务。

作为境外企业，并不存在可以让你豁免的营业额或销量门槛：起决定作用的是在欧洲进行商业化这一事实本身。

GiBSeS — GiBSeS帮助非欧盟企业在投入之前，弄清楚CRA是否以及如何影响其产品在欧洲市场上的销售。

CRA并不强制要求非欧盟制造商必须指定授权代理人：指定与否是一项选择，需通过书面授权正式确立，它可以让你将某些职责——例如保管技术文档、配合主管机构——委托给一个在欧盟设立的主体。

而几乎总是不可或缺的角色，是设立在欧盟的进口商，因为如果没有一个将产品投放市场的欧洲主体，很多义务实际上就无法履行。实际操作中，授权代理人可以简化与监管机构之间的沟通，但是否设立需要具体情况具体评估。

GiBSeS — GiBSeS帮助你判断设立欧盟授权代理人是否划算，还是依托进口商即可，不会让你背负超出必要的复杂架构。

主要责任始终由制造商承担，即便其总部设在欧盟以外：网络安全风险评估、符合基本要求、技术文档、符合性声明、漏洞管理，均由制造商负责。

设立在欧盟的进口商则承担把关角色：只能将符合要求的产品投放市场，且必须核实制造商是否已完成符合性评估、产品是否加贴CE标志并附有符合性声明和使用说明。下游的分销商则必须尽到应有的注意义务，核实标志和文档是否齐全。

如果进口商或分销商对产品进行了实质性修改，或以自有品牌销售产品，则可能需要承担制造商的义务。

GiBSeS — GiBSeS帮助你梳理欧洲销售链上各方各自的职责分工，让责任在与进口商签约之前就明确清楚。

是的。为了能够投放欧盟市场，数字化产品必须加贴CE标志，以证明其符合CRA的要求（以及可能适用的其他法规的要求）。该标志必须配有由制造商编制并签署的欧盟符合性声明，制造商需为此承担责任。

设计或生产地点并不重要：真正重要的是，在进入欧洲市场进行商业化之前，是否已经完成了适当的符合性评估、技术文档以及标志的加贴。

GiBSeS — GiBSeS陪伴非欧盟企业走完CRA的CE标志之路，从要求评估到符合性声明一路提供支持。

是的，这是可能发生的情况之一。市场监管机构和海关当局可以对不合规产品采取行动：暂停投放、要求下架或召回、禁止或限制其供应，若存在重大风险，还可以在边境扣留货物。

除了产品被物理扣留之外，CRA还规定了行政处罚，对于最严重的违规行为，罚款金额可能非常高（最高可达数百万欧元，或全球年营业额的一定比例）。对境外企业而言，最大的损失往往是突然失去进入欧洲市场的机会。

GiBSeS — GiBSeS帮助你提前识别欧盟主管机构重点排查的不合规之处，从而预防货物在边境被扣。

是的。无论制造商设立于何处，CRA都要求其在产品整个支持期内管理漏洞：提供安全更新，维护协调一致的披露政策，并在主管机构提出要求时提供软件物料清单（SBOM）。

此外还规定了通报义务：被主动利用的漏洞和严重事件必须通过欧盟统一通报平台进行报告，且时限要求严格（首次预警须在24小时内发出，随后提交更详细的通报）。这些义务是跟随产品而非制造商注册地而定的，也是最早生效的义务之一。

GiBSeS — GiBSeS帮助你建立符合欧盟时限要求的漏洞管理与通报流程，即便你的运营地点在欧洲之外。

该条例已经生效，但各项义务是分阶段启动的。被利用漏洞和严重事件的通报义务最先适用（从2026年9月起），而产品方面的大部分义务——基本要求、CE标志、符合性评估——则从2027年12月起全面适用。

对非欧盟企业而言，这段时间是宝贵的技术准备期：安全设计、文档编制以及可能涉及的公告机构介入都需要数月时间。最好把这些日期当作项目里程碑来对待，而不是遥远的截止日期。

GiBSeS — GiBSeS帮助你制定一份切实可行的路线图，稳步迈向CRA各项截止日期，避免在最后关头被欧盟市场拒之门外。

一般而言是的。CRA涵盖“数字化产品”这一类别，其中包括单独分发的软件——应用程序、固件、程序库、组件——只要它是在商业活动范围内被提供给欧盟市场，即便是免费提供也不例外。

不过也存在例外和特殊制度：某些服务（例如纯粹的SaaS服务）更多地归入NIS2指令等其他法规的管辖范围，而某些已受行业特定法规约束的产品类别则遵循自己的规则。具体界限取决于产品的分发和集成方式，因此需要针对具体情况进行核实。

GiBSeS — GiBSeS帮助非欧盟软件供应商在打开欧洲销售渠道之前，弄清楚自己适用于CRA、NIS2还是两者兼有。

CRA区分“默认”产品——通常允许自我评估符合性——与条例附件中列出的“重要”和“关键”产品类别，后者需要更严格的程序，甚至可能需要公告机构介入，或采用专门的认证方案。

属于较高风险类别的产品包括密码管理器、防火墙、操作系统、身份识别和网络安全组件等。确定正确的类别是第一个关键分岔点：它会从根本上改变合规的成本、时间和路径。

GiBSeS — GiBSeS帮助你正确地将产品归入CRA的相应类别，让非欧盟企业能够根据真实的风险水平来衡量所需投入的合规精力。

起点是弄清楚该条例是否以及如何与你相关：确认产品是否属于在欧盟销售的“数字化产品”，明确其类别（默认、重要或关键），并识别你欧洲供应链上的各方，尤其是进口商。

在此基础上构建整个路径：分析基本网络安全要求，进行风险评估，准备技术文档和符合性声明，建立漏洞管理和通报流程，最后完成CE标志。对非欧盟企业而言，把这一切当作一个市场准入项目来推进会很有帮助，并优先处理最近的截止日期。

GiBSeS — GiBSeS作为独立顾问，陪伴非欧盟中小企业从最初的分析一路走到CE标志完成，帮你打开欧洲市场的大门，同时不会将你绑定到单一供应商。