NIST 放出的 SP 800-213 Rev.1 草案，有个细节很适合拿来改物联网采购表。它不再只盯设备本体，而是反复说 IoT product。这个口径一变，采购、集成、运维三拨人都得把问题问细。
设备只是进门的那一块铁，真正进系统的是固件、云端服务、移动端配置工具、更新通道、日志接口和供应商支持。
采购评审要从设备清单改成产品清单
很多项目做 IoT 验收时，还在看端口、账号、加密、默认密码这些条目。这些当然要看，但只看这些不够。NIST 草案强调，IoT 产品进入信息系统后，会改变系统的风险评估，团队可能需要重新选择控制项。
落到企业现场，采购表至少要多几列。设备型号、固件版本、云服务依赖、移动 App、管理后台、日志出口、升级机制、漏洞响应联系人。哪一列空着，后面都会变成集成团队的手工补洞。
把新设备当成系统变更处理
草案里有一个很实用的说法，new 指的是新进入这个系统，不一定是刚出厂的新产品。这句话对工厂、园区、仓储项目很有用。一个网关在 A 产线跑了两年，搬到 B 产线后，网络边界、账号权限、数据去向都变了。
所以 IoT 接入流程不能只看采购时间。设备换场地、换网络、换数据平台、换供应商远程维护方式，都应该重新走风险评审。嫌麻烦可以理解，但物联网事故经常就卡在这种看起来只是挪一下的位置变化上。
供应商要交付可验证的证据
我更关心供应商能不能拿出证据，而不是 PPT 里写了多少安全能力。漏洞修复周期怎么定义，固件包怎么签名，管理后台有没有审计日志，远程维护账号怎么开关，设备退役时数据怎么清理，这些都要能演示。
优易云做设备接入和运维平台时，通常会把这些证据固化成验收项。测试人员不只记录通过或不通过，还要留下截图、日志、固件哈希、配置导出和供应商确认记录。以后设备批量上线，才知道自己到底放进了什么。
风险评估要连接运维动作
NIST IR 8618 记录的 workshop 讨论里，关键词很集中，制造、隐私、风险管理、可保护产品、软件开发。它提醒团队别把 IoT 安全做成一次性测评。设备上线后，环境会变，威胁会变，供应商支持状态也会变。
更稳的做法是把风险评估接到运维动作。发现固件过期就生成工单，发现云端证书快到期就提醒负责人，发现设备长期离线就触发资产核查。只有报告，没有动作，报告会慢慢变成归档材料。
给项目经理的一张短清单
项目启动时先问供应商四件事。产品包含哪些组件，哪些组件会联网，谁负责更新，停服或退役时怎么处理数据。问清楚这些，再谈价格和交期。
项目上线前再问团队四件事。设备进了哪个网段，日志流向哪里，谁能远程维护，发现漏洞后谁拍板停用。答案写下来，别只存在群聊里。
IoT 安全很容易被说成设备参数问题。NIST 这次草案给了一个更接地气的提醒，采购进来的其实是一套产品和一段生命周期。表格改对了，后面的坑会少很多。
