截至 2024 年 8 月 13 日，NIST 已批准首批 3 项后量子密码标准；这说明迁移规划已有明确标准依据，但并不意味着企业能直接套用统一报价。(csrc.nist.gov) NIST PQC 迁移成本估算应从密码资产数量、依赖复杂度、测试范围、供应商配合和分阶段部署工作量自下而上建立；本周先确定预算边界并启动资产盘点，再用低、中、高情景提交估算，不要先填一个没有依据的总价。
这篇适合需要提交迁移预算的安全负责人，用于拆分成本项。
负责排期与资源评估的项目经理，可据此记录假设和不确定性。
承担系统改造的工程负责人，可补入技术债、验证和发布工作量。
先划定预算边界与输出口径
同一个项目名下，可能混有“先弄清现状”“验证某个试点”“完成正式改造”以及“上线后持续维护”等不同工作。如果预算只报一个总额，审批人就难以判断哪些内容已确认，后续追加又是范围变化还是漏项。
建议先在立项说明中写清本次预算覆盖的阶段、系统范围、估算周期和排除项。例如，试点预算可包含测试环境准备、供应商确认及互操作验证，但不默认包含所有业务系统的正式切换。各项工作同时标注责任部门、估算依据、一次性或持续属性，以及需要谁在什么条件下确认。
NIST 已发布后量子密码标准，并提供迁移相关材料；NCCoE 的迁移项目也将密码发现与互操作测试作为重要工作方向。它们适合帮助企业确定“要盘点什么、要验证什么”，但不是面向特定企业的工时报价或行业成本基准。(nccoe.nist.gov)
用四类场景拆出工作量
密码资产盘点不是简单数设备或应用。它要回答算法在哪里调用、保护什么数据、由谁负责，以及依赖能否由企业自行改动。NCCoE 的发现指南将密码清单作为风险管理和迁移规划的依据；对企业来说，自动化发现结果还需要与系统清单、责任人访谈及供应商资料相互核对。(nccoe.nist.gov)
| 场景 | 主要工作 | 估算依据 | 常见漏项 |
|---|---|---|---|
| 密码资产盘点与排序 | 发现算法调用、核对依赖、访谈系统负责人、标注风险 | 实际系统清单、扫描结果、责任人确认记录 | 未纳管应用、证书服务、影子依赖、无人认领的旧系统 |
| 应用、协议与供应链改造 | 分开记录自研代码、第三方库、证书与服务接口的改造责任 | 代码与组件清单、合同范围、供应商书面支持信息 | 版本升级限制、外部接口协同、硬件或托管服务不可控 |
| 测试、互操作与发布 | 兼容、性能、回退、跨环境验证及发布演练 | 本团队可复现的测试计划和结果 | 客户端差异、证书链、网络路径、生产回退条件 |
| 运维与持续复核 | 密钥生命周期、配置维护、日志监控、依赖升级与供应商追踪 | 运维制度、值班和变更流程、预算周期 | 监控规则更新、密钥轮换、迁移完成后的算法复核 |
盘点阶段：把“数量”补成“可估算条目”
密码资产盘点的条目至少要记录系统标识、算法或密码组件的使用位置、数据用途、环境、负责人、依赖方和证据来源。发现工具只能覆盖其可观察到的范围；静态扫描、运行时观测、配置核对和访谈可能互相补充，任何单一结果都不宜直接当成完整资产总量。
估算时，不要以“每个资产固定多少工时”机械相乘。对于重复部署、共用组件且负责人明确的系统，可复用调查结论；对于代码位置不明、供应商接管或停止维护的系统，应把查证本身列为工作，而不是假设改造简单。NCCoE 的材料强调识别公钥算法的使用位置及其依赖系统，这正是把盘点结果转成预算条目的起点。(nccoe.nist.gov)
改造阶段：区分自研责任与供应商责任
将自研代码、第三方密码库、证书与身份体系、协议端点、托管服务分别建项。每项记录“谁能改、改动发生在哪一侧、供应商是否确认支持、合同是否覆盖实施或验证”。如果支持版本或交付范围尚无书面回复，就记为待确认依赖，不要把它当作已包含的工作。
NIST 的标准中，ML-KEM 对应密钥封装机制；另有用于数字签名的标准。它们涉及的系统位置和验证路径可能不同，因此预算不应只写“替换算法”，而要明确受影响的接口、组件和签名或密钥建立流程。标准名称是技术基线，并不自动证明现有产品已经支持，也不代表所有系统都能以同一种方式改造。(csrc.nist.gov)
验证阶段：按本企业可复现测试估算
测试预算应覆盖兼容性、性能测量、跨环境验证、故障回退和发布演练。先写清客户端与服务端组合、证书链、协议路径、业务负载、观测指标和失败判定，再由工程团队执行并记录实际所需的准备、排障、复测与审批时间。
NCCoE 发布的互操作与性能材料适合用来识别测试维度和潜在边界，但其中的实验结果不能替代企业自身的测试工时或性能承诺。不同实现、网络条件和系统组合都会影响结果；因此，外部实验数据用于提出测试问题，不用于直接推算本企业要花多少人天。(nccoe.nist.gov)
运维阶段：把持续成本单列
上线后仍要考虑密钥与证书生命周期、配置基线、日志和告警规则、密码库升级、例行回归，以及供应商支持状态追踪。把这些工作按预算周期列为持续投入，并注明由平台、安全、运维还是供应商承担。NIST 的密码敏捷性指导将算法替换能力放在协议、应用、软件、硬件和基础设施等具体环境中讨论；如果迁移只完成一次替换，却没有维护后续调整能力，预算就可能漏掉关键运营工作。(csrc.nist.gov)
以情景区间处理未知项
情景区间不是给未知工作“猜一个百分比”，而是将证据强弱分开。内部金额应来自组织的工时记录、核定人工成本、已审批预算或有效供应商报价；缺少这些依据时，只报告工作量范围、未决假设和预算待确认状态，不给出虚构单价。
| 估算情景 | 纳入假设 | 如何更新 |
|---|---|---|
| 低情景 | 资产位置和责任人已确认；改造路径明确；供应商书面确认支持；测试范围收敛 | 以已验证工作项和内部历史记录估算 |
| 中情景 | 少量资产需补充调查；部分组件需要联调；关键供应商事项仍待回复 | 将待确认事项单列，并在回复或试点结果返回后重算 |
| 高情景 | 存在未知依赖、老旧组件、跨组织接口或回退路径尚未验证 | 将调查、供应商协同、额外测试和分阶段发布纳入风险范围，不用统一比例加价 |
提交预算时，把三类金额或工时状态分栏：已确认、待供应商确认、高不确定性。若金额尚未取得真实报价，就写明“待询价”；若内部工作量没有历史数据，就用试点记录补证据，而不是把情景区间包装成精确预测。
预算工作表的勾选项
- [ ] 已明确本次覆盖规划、试点、正式改造、持续运维中的哪些阶段。
- [ ] 盘点条目有系统负责人、算法或组件位置、依赖方和证据来源。
- [ ] 自研、第三方库、证书服务、协议接口和托管服务分别标明责任。
- [ ] 供应商支持、合同范围和版本限制有书面依据；未确认事项未当作已完成。
- [ ] 测试方案覆盖兼容、性能、回退、跨环境和发布演练，并有可复现记录。
- [ ] 一次性迁移与持续运维分开列项，明确估算周期和承担团队。
- [ ] 低、中、高情景均写出假设、责任人、金额来源或工时依据。
- [ ] 预算设有重估触发条件，例如盘点发现新依赖、供应商答复改变或试点未通过。
常见预算问题
预算项应围绕工作结果组织，而不是围绕算法名堆列表：资产盘点有清单和责任人，改造有系统边界和供应商责任，验证有测试记录，运维有周期和执行团队。这样既能回答企业做后量子密码迁移预算要包含什么，也能让审批人看出哪些项目仍需要补证据。
现有系统的 PQC 改造工作量，最好从一个有代表性的试点开始校准：记录发现、设计、实现、联调、复测和发布各阶段投入，再按系统差异调整，而不是用试点平均值套到所有应用。密码资产盘点结果则应关联风险、依赖和改造责任，才能形成迁移顺序与预算优先级；最难估的通常是隐蔽依赖、外部支持和跨环境互操作，需作为独立风险项保留。
下一步预算动作
先完成密码资产盘点，再把未确认依赖交由责任团队逐项核实；随后参照 NIST 的迁移与互操作材料补齐验证范围。若需要远程测试环境，应以 Vuncloud 当前服务页面和当前价格信息中的实际内容核算，不要把未确认的环境、交付方式或报价写入迁移预算。与长期固定负载或必须直连物理接口的场景相比，临时测试更适合先比较租用与自购的真实条件；迁移成本模型仍应把环境费用作为单独、可核验的项目。
为后量子迁移验证，准备一套可控的云端 Mac 环境
用 Vuncloud 独享 Mac mini M4 承载构建与兼容性验证任务，让测试资源与日常开发环境分开。
先按天试用评估资源需求，再按周、月或季度安排持续任务，便于分阶段规划预算。