“提供五年安全支持”：CRA 的支持期到底何时结束？
用预期使用时间、技术文档、投放市场证据和公开结束日期核对《网络韧性法案》的支持期说法。
重点监测信号
- 联网产品接近欧盟上市，市场材料写五年安全支持，却没有预期使用评估
- 核心第三方组件早于产品承诺停止支持，修复或替换负责人仍未确定
- 技术文档、购买信息、包装和更新渠道里的支持结束日期无法对齐
“五年”不是一条完整的《网络韧性法案》（CRA）支持期结论。根据 Article 13(8)，制造商要确定一个能反映数字要素产品预期使用时间的期限：通常至少五年；预期使用少于五年时才可更短；产品合理预期使用更久时，则要更长。每个说法都要有确定理由、产品事件和可见结束日期。
产品安全维护或 CRA 合规服务商的商务拓展负责人，在获授权的联网产品、嵌入式软件和安全 Telegram 群里，应寻找“具名上市 + 支持承诺 + 断裂证据链”。泛泛争论五年够不够不是项目。等包装和购买页面锁定后才看到，纠正日期证据成本更高，还可能错过维护架构决定。
第一问：五年是下限、例外，还是根本算错了？
《网络韧性法案》即条例（EU）2024/2847。Article 13(8) 要求制造商在产品投放市场时及支持期内有效处理产品及其组件的漏洞。
制造商确定支持期时，要看预期使用、合理用户期待、产品性质与预期目的，以及规定产品寿命的相关欧盟法；还可考虑同类产品、运行环境可用性、承担核心功能的第三方组件支持期和相关指引，并按比例应用这些因素。
同一段规定支持期至少五年。产品预期使用少于五年时，可对应较短时间。序言举过临时疫情接触追踪应用的例子；硬件、网络设备、操作系统和工业产品通常会使用更久，支持期也要相应更长。
正确的销售问题不是“你们能不能做五年”，而是：“哪个产品和使用评估得出这个期限，什么证据证明它从所说事件开始、在所说月份结束？”
第二问：哪一个事件固定了这张回执？
下面是说明用的合成消息，不是客户说法：
“明年春天 EU launch，安全更新保证五年。chip vendor 2030 年停 patch，这个月要定 box 上的 support date。”
消息有欧盟上市、五年说法、组件依赖和包装节点，却没有准确产品、预期目的、预期使用评估、投放市场日期、最终芯片、运行环境、更新渠道或支持结束月份。
支持期回执至少有五个日期：制造商批准预期使用分析和支持期的确定日期；对应产品版本的投放市场记录；向购买者展示的支持结束月份与年份；可能早于产品承诺结束的核心组件日期；以及声明期限内的漏洞接收、修复和更新记录窗口。
条例没有把支持期定义成“第一条群消息后五年”或“开发开始后五年”。计算必须回到产品技术和市场记录。
第三问：组件链能兑现承诺吗？
Article 13(8) 明确允许制造商考虑承担核心功能的集成组件支持期。这不等于直接复制最短组件日期，而是要求产品计划说明：核心组件早于用户停止使用产品而结束支持时怎么办。
证据文件应写明组件、功能、供应商结束日期、替换或缓解路径、更新分发渠道和负责人。开源组件的上游维护结束，与制造商自己维护的分支是两条事实；硬件组件仍可采购，也不代表漏洞修复仍在继续。
CRA 报告工作流需求处理已被主动利用漏洞和严重事件，不回答产品应处理漏洞多久。安全软件声明证据需求对应美国联邦交付，也不是欧盟产品支持期。价格与访问方式介绍 TOP Prospect 的发现工具。
TOP Prospect 可以从用户主动连接且有权访问的 Telegram 群里发现并合并相关片段，保留原文、来源、时间、摘要和排序理由供人工查看。它不能确定产品寿命、检查技术文档、承诺更新、发布结束日期或宣布 CRA 符合性。
第四问：客户看到的是不是同一个结束日期？
Article 13(19) 要求至少以月份和年份写明支持期结束日期，在购买时以易于取得、清楚易懂的方式提供，并在适用时出现在产品、包装或数字渠道。技术可行时，产品到达支持期结束还要通知用户。
证据链应把已批准回执与网页产品页、购买流程、包装或设备界面、说明书和更新服务对照。一处写 2033 年 3 月，另一处写“激活后五年”，不一致本身就是项目。
Article 13(18) 另行要求用户信息和说明至少在投放市场后 10 年，或支持期内可取得，以较长者为准。说明书可取得时间不能与漏洞处理支持期混为一谈。
第五问：团队有没有用错适用日期？
Article 71 规定 CRA 一般自 2027 年 12 月 11 日适用。Article 14 报告义务较早，从 2026 年 9 月 11 日适用；符合性评估机构条款自 2026 年 6 月 11 日适用。准备 2028 年上市的团队现在建立 Article 13 证据很合理，但 2026 年 8 月的消息不能因为 Article 14 日期接近，就声称 Article 13 已经普遍适用。
这条日期差异能把真实准备项目与错误的“下个月截止”分开。
一张支持期回执
本文的原创贡献是一页六字段记录：
| 字段 | 证明 |
|---|---|
| 产品 | 准确版本、预期目的和市场路线 |
| 预期使用 | 用户期待、产品性质、运行环境与适用法律 |
| 期限 | 已批准起止逻辑，包括少于五年的理由 |
| 组件 | 核心依赖支持日期与缓解负责人 |
| 发布 | 购买时和适用载体上展示的结束月/年 |
| 维护 | 漏洞接收、更新、披露与结束通知路径 |
字段对齐后，维护服务商可以界定工程、组件替换、更新分发或证据运营。字段不一致时，第一项交付应是带日期的差距分析，不是“五年保证”。
关键事实
- CRA 一般自 2027 年 12 月 11 日适用；Article 14 报告义务自 2026 年 9 月 11 日适用。
- Article 13(8) 要求在支持期内有效处理漏洞。
- 支持期反映产品预期使用时间，通常至少五年。
- 预期使用少于五年时可以更短；预期使用更久的产品需要更长支持。
- 技术文档必须包含用于确定期限的信息。
- Article 13(19) 要求在购买时和适用产品、包装或数字载体上清楚提供至少结束月份和年份。
常见问题
CRA 要求每个产品都恰好支持五年吗？
不是。支持期通常至少五年；产品预期使用少于五年时，可对应较短预期使用时间；预期使用更长的产品则需要反映更长使用期的支持。
哪些因素决定支持期？
Article 13(8) 包括预期使用、合理用户期待、产品性质与预期目的、相关欧盟法、类似产品、运行环境可用性、核心组件支持期和相关指引，并要求按比例考虑。
支持结束日期要出现在哪里？
Article 13(19) 要求至少写明月份和年份，在购买时以易于取得、清楚易懂的方式提供，并在适用时出现在产品、包装或数字渠道。
2026 年 8 月，Article 13 支持期义务已经普遍适用吗？
没有。条例一般自 2027 年 12 月 11 日适用；Article 14 报告义务提前到 2026 年 9 月 11 日，但不能把该较早日期套到 Article 13 支持期。
最强的需求 Signal 不是“CRA 说五年”，而是一款准备上市的产品，其技术文档、组件计划和面向购买者的结束日期还无法证明支持承诺。
常见问题
CRA 要求每个产品都恰好支持五年吗？
不是。支持期通常至少五年；产品预期使用少于五年时，可对应较短预期使用时间；预期使用更长的产品则需要反映更长使用期的支持。
哪些因素决定支持期？
Article 13(8) 包括预期使用、合理用户期待、产品性质与预期目的、相关欧盟法、类似产品、运行环境可用性、核心组件支持期和相关指引，并要求按比例考虑。
支持结束日期要出现在哪里？
Article 13(19) 要求至少写明月份和年份，在购买时以易于取得、清楚易懂的方式提供，并在适用时出现在产品、包装或数字渠道。
2026 年 8 月，Article 13 支持期义务已经普遍适用吗？
没有。条例一般自 2027 年 12 月 11 日适用；Article 14 报告义务提前到 2026 年 9 月 11 日，但不能把该较早日期套到 Article 13 支持期。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
