Raspberry Pi 把 EU Cyber Resilience Act 摆到工业客户面前，这件事很贴近嵌入式团队的日常。很多产品看上去只是一个网关、一块采集板、一个带屏控制器，卖到欧洲市场后就会进入产品合规链路。硬件选型、固件架构、远程维护和漏洞响应，都要能拿出证据。
CRA 管的是产品生命周期
欧盟官方说明把 CRA 放在产品设计、开发、维护和供应链责任里看。Raspberry Pi 的文章也点出，带数字元素的软硬件产品、远程数据处理方案、单独销售的软件或硬件组件，都可能落入范围。嵌入式设备厂商不能只把安全当作出厂前的渗透测试。
工程上要先问一个很朴素的问题。设备交付给客户后，团队还能不能知道它跑了什么固件、用了哪些开源组件、哪些证书快过期、哪些漏洞影响它。如果这些问题答不上来，后面的报告、补丁和客户沟通都会很被动。
报告窗口会压缩内部响应
CRA 把已被利用的漏洞和严重安全事件纳入报告义务，早期预警和完整通知都有明确时限。这个要求对嵌入式厂商的压力不在表格，而在判断速度。一个 CVE 出来后，团队要很快确认产品是否受影响、是否已经被利用、客户能不能先做缓解。
很多嵌入式项目的现实状态不太好看。BSP 来自芯片厂，内核被改过，用户态库混着供应商二进制包，量产后还有客户现场脚本。没有 SBOM 和构建记录，安全负责人只能靠记忆查版本。那种排查方式撑不住合规报告。
证据包比口头承诺可靠
建议把每个产品线做成一套安全证据包。里面至少放四类材料，组件清单、威胁建模记录、更新机制说明、漏洞处理流程。组件清单要能追到固件镜像，不要只停在仓库依赖。更新机制要写清楚签名、回滚、断电恢复和失败重试。
客户说明也要提前准备。设备支持多久，哪些接口默认开放，远程管理怎么关闭，日志能导出哪些安全事件，这些信息不能等销售临门一脚再整理。CRA 要求透明告知安全能力和限制，工程团队最好给销售和交付一份稳定口径。
Raspberry Pi 只能降低底层风险
Raspberry Pi 提供长期供货、文档、软件生态和工业集成支持，这能降低底层平台的不确定性。可产品责任仍在制造商身上。你把 Compute Module 放进控制器，外壳、载板、系统镜像、云端服务、移动 App 和更新服务器都成了你的产品边界。
这也是很多团队容易踩坑的地方。开发板阶段跑通了原型，量产阶段换了电源、网卡、内核参数和远程维护入口，安全边界已经变了。合规文档如果还沿用原型记录，审查时很难解释。
优易云的落地建议
准备进入欧洲市场的嵌入式产品，可以从一条样板产品线开始补账。把固件构建固定下来，生成 SBOM，给升级包加签名和回滚验证，把漏洞分级和客户通知流程跑一次桌面演练。演练时别只让安全同事参加，研发、测试、交付和售后都要坐进来。
合规不是把文档塞进文件夹。现场真正有用的是一条能跑通的链路，从漏洞输入到影响判断，从补丁构建到客户说明，从临时缓解到长期修复。链路跑顺了，证据自然会留下来。
