QianHeng乾珩 PQC Docs Hub量子文档 ✦ Ask AI✦ 问问文档 ⚐ Scan⚐ 扫一扫

Migration Playbook

A concrete, step-by-step plan for moving an organization to post-quantum cryptography. Each phase has explicit actions, an accountable owner, and an exit criterion so you can tell when you are allowed to move on. Treat the whole thing as a loop — re-enter phase one as your estate and the standards evolve.

Phase summary

PhaseOwnerExit criterion
1. Govern & inventoryCISO / crypto governance leadCBOM complete; assets risk-ranked via X+Y>Z
2. PrioritizeRisk + architectureRanked backlog signed off by risk owners
3. Pilot hybridPlatform / networkingHybrid KEX live in a production-like path
4. Crypto-agile rolloutEngineering leadsCrypto behind an abstraction; algorithms negotiated
5. Migrate PKI & signingPKI teamPQC/composite CA issuing; firmware/code-signing PQC pilot with an explicit state-management plan
6. Decommission & monitorOperations / SOCLegacy disabled; continuous monitoring & re-assessment

Phase 1 — Govern & inventory

  • Actions: stand up crypto governance and a central policy; run cryptographic discovery across code, binaries, network, certs, and HSMs; produce a CBOM; risk-rank every asset using Mosca's X + Y > Z.
  • Owner: CISO / crypto governance lead.
  • Exit: a maintained CBOM exists and every quantum-vulnerable asset has a risk rank.

Phase 2 — Prioritize

  • Actions: order the backlog by data sensitivity, data lifetime, and exposure; pull long-lived secrets, external-facing services, and signing roots to the front.
  • Owner: risk and architecture, with sign-off from data owners.
  • Exit: a ranked migration backlog accepted by the business.

Phase 3 — Pilot hybrid

  • Actions: deploy hybrid key exchange (e.g. X25519MLKEM768) in a low-risk TLS or VPN path; measure handshake size, latency, and interop; capture lessons.
  • Owner: platform / networking.
  • Exit: hybrid KEX runs in a production-like environment with acceptable performance and no interop breakage.

Phase 4 — Crypto-agile rollout

  • Actions: put crypto behind an abstraction layer; remove hard-coded algorithms and sizes; add algorithm negotiation and versioning; adopt agile, PQC-capable libraries. See Crypto-Agility.
  • Owner: engineering leads per service.
  • Exit: services route crypto through the abstraction and negotiate algorithms; no hard-coded primitives remain on the priority paths.

Phase 5 — Migrate PKI & code-signing

  • Actions: stand up a PQC/composite-capable CA; issue PQC or composite certificates; for firmware and code-signing where the signing environment is controlled and state can be managed reliably, prioritize evaluating LMS/XMSS; where you cannot guarantee that state is never reused, choose the stateless SLH-DSA or another suitable scheme; plan trust-store distribution. See PKI Impact.
  • Owner: PKI team.
  • Exit: PQC/composite CA in production; firmware/code-signing has piloted a PQC or hash-based signature scheme with an explicit state-management plan (XMSS/LMS must not be used where state cannot be managed safely); trust-store rollout underway.

Phase 6 — Decommission & monitor

  • Actions: disable legacy algorithms and negotiation fallbacks; alarm on any legacy use; re-run discovery on a schedule; re-assess X+Y>Z as standards and the threat evolve.
  • Owner: operations / SOC.
  • Exit: legacy disabled on migrated paths; monitoring and periodic re-assessment in place — then loop back to phase 1.
Note
Firmware and code-signing are the place to act first, even before TLS. Devices signed today may run for a decade, and a forged firmware signature is catastrophic. LMS and XMSS are standardized for signing, but they are stateful — only use them where signing state can be managed reliably; otherwise prefer the stateless SLH-DSA. Plan firmware signing early rather than waiting for the rest of the program.

Standards & references

迁移实施手册

一份将组织迁移到后量子密码的具体分步计划。每个阶段都有明确的行动、一名负责人和一条退出标准,让你能判断何时获准进入下一阶段。请将整体视为一个循环——随着资产现状与标准演进,再回到第一阶段重新开始。

阶段总览

阶段负责人退出标准
1. 治理与盘点CISO / 密码治理负责人CBOM 完成 资产经 X+Y>Z 风险排序
2. 优先级排序风险与架构风险责任人签署确认的排序待办
3. 混合试点平台 / 网络混合密钥交换在类生产路径上线
4. 密码敏捷化推广各研发负责人密码置于抽象层之后 算法可协商
5. 迁移 PKI 与签名PKI 团队PQC/复合 CA 签发中 固件/代码签名完成 PQC 试点并明确状态管理方案
6. 退役与监测运维 / SOC旧算法关闭 持续监测与重新评估

第 1 阶段 治理与盘点

  • 行动:建立密码治理与集中策略,对代码、二进制、网络、证书与 HSM 执行密码发现盘点,产出 CBOM,并用 Mosca 的 X + Y > Z 对每项资产做风险排序。
  • 负责人:CISO / 密码治理负责人。
  • 退出:存在一份持续维护的 CBOM 且每项易受量子攻击的资产都有风险等级。

第 2 阶段 优先级排序

  • 行动:按数据敏感度、数据寿命与暴露面为待办排序,把长寿命机密、对外服务与签名根置于最前。
  • 负责人:风险与架构团队,并由数据责任人签署确认。
  • 退出:一份经业务方接受的排序迁移待办清单。

第 3 阶段 混合试点

  • 行动:在低风险的 TLS 或 VPN 路径部署混合密钥交换(如 X25519MLKEM768),测量握手尺寸、时延与互操作性,沉淀经验。
  • 负责人:平台 / 网络。
  • 退出:混合密钥交换在类生产环境运行 性能可接受 且无互操作中断。

第 4 阶段 密码敏捷化推广

  • 行动:将密码置于抽象层之后,移除写死的算法与尺寸,加入算法协商与版本化,并采用敏捷且支持 PQC 的库。参见密码敏捷
  • 负责人:各服务的研发负责人。
  • 退出:各服务均通过抽象层路由密码并协商算法,优先路径上不再残留写死的原语。

第 5 阶段 迁移 PKI 与代码签名

  • 行动:建立支持 PQC/复合的 CA,签发 PQC 或复合证书;对于签名环境受控、可可靠管理状态的固件与代码签名,可优先评估 LMS/XMSS;若无法保证状态不复用,应选择无状态 SLH-DSA 或其他合适方案;同时规划信任库分发。参见 PKI 影响
  • 负责人:PKI 团队。
  • 退出:PQC/复合 CA 投产,固件/代码签名已完成 PQC 或哈希基签名方案试点并明确状态管理方案(无法安全管理状态的场景不得使用 XMSS/LMS),信任库分发进行中。

第 6 阶段 退役与监测

  • 行动:关闭旧算法与协商回退,对任何旧算法的使用告警,按计划重跑发现盘点,并随标准与威胁演进重新评估 X+Y>Z。
  • 负责人:运维 / SOC。
  • 退出:已迁移路径上旧算法关闭,监测与定期重新评估就位——随后回到第 1 阶段循环。
注意
固件与代码签名是最该率先行动之处,甚至应先于 TLS。今天签发的设备可能运行十年,而一枚被伪造的固件签名后果不堪设想。LMS 与 XMSS 已就签名场景完成标准化,但属于有状态方案——仅在能可靠管理签名状态时使用;否则应优先选择无状态的 SLH-DSA。固件签名宜尽早规划,不必等待整个计划完成。

标准与参考

⚑ Report an error⚑ 纠错与校正