2026 年 NIST PQC 遷移成本怎麼估算？先算哪些工作項

NIST 已於 2024 年發布三項後量子密碼標準，但標準發布不會自動變成企業的固定遷移報價。估算 NIST PQC 遷移成本時，應先盤點密碼資產，再按依賴複雜度、測試範圍、供應商配合和分階段部署工作量建立模型；不要直接套用沒有來源的單價。本週可先整理系統清單、責任人和未知依賴，之後再用低、中、高情境提出預算區間。

本文適合需要編列遷移預算的資安負責人，用來拆分成本項；負責排期與資源評估的專案經理，可用它標示假設與不確定性；系統工程負責人則可補上技術債、整合和驗證工作量。

先界定預算涵蓋範圍與估算輸出

先把預算對應到明確階段：遷移規劃、試點驗證、正式改造，或上線後維護。若只估試點，就不應把數個系統的全面部署混進總額；若準備提交多年期預算，也不能只列一次性的程式修改，而略過後續金鑰與設定維護。

建議每筆估算都保留工作項目、負責團隊、估算依據、假設與待確認事項。內部投入可依工時紀錄及組織核定的人力成本換算；外部費用則採實際報價或合約條款。本文不設定單一金額、行業平均值或通用工時，因為系統可見度、架構與供應商責任各不相同。

NIST 的遷移材料可協助團隊規劃發現與轉換工作；密碼敏捷性指引則可用來檢視架構是否便於日後替換密碼機制。這些材料適合建立工作範圍，不是企業報價或全行業成本基準。

依盤點結果估算資產發現與風險排序

盤點的工作量不只取決於系統數量，也取決於資料是否可查、負責人是否明確，以及加密用途能否從程式和設定中辨識。只檢視程式碼庫，可能漏掉閘道、憑證服務、封裝套件或外部服務中的密碼依賴；只靠訪談，也可能無法核實實際運行設定。因此，應把自動化掃描、文件核對和責任人訪談分開估算。

資產紀錄至少要連結業務系統、技術負責人、使用中的協定或函式庫、上游與下游依賴，以及目前可取得的支援資訊。接著依業務影響、暴露範圍、資料保存需求和替換難度排序；排序是為了決定先驗證什麼，不代表可直接推算成本。

提醒：資產清單中的「未確認」不等於「沒有依賴」。應將未確認項目列為待查工作，指定負責人和確認方式；否則預算容易低估後續發現與整合成本。

按自研與外部依賴拆分改造責任

逐項檢查自研程式、第三方函式庫、憑證及服務介面。自研程式通常要拆出演算法呼叫、設定、協定協商和相容性調整；第三方元件則先確認版本支援、升級方式及合約是否涵蓋相關協作；憑證與服務介面需核對簽章、金鑰交換及依賴端能否共同變更。

涉及 ML-KEM 時，不應只把它記成一項程式庫升級。估算還要說清楚使用情境、所依賴的產品或函式庫版本、對接端是否支援，以及測試與回退由哪個團隊負責。未取得供應商支援資訊前，可先列出確認工作，但不能假設支援已到位，也不能把第三方回覆時間當成確定工時。

NCCoE 的遷移初稿與配套初稿可作為檢視遷移與整合工作範圍的參考；正式預算仍應回到企業實際產品支援文件、合約範圍和系統清單，不把示範材料當成自身工時估值。

把驗證、互通與發布演練列入專案投入

測試成本應按可重現的測試工作估算，而不是引用別人的效能數字代替本地驗證。可將測試拆成協定與元件相容性、不同執行環境的互通、效能測量、故障情境、回退路徑和發布演練，並為每項註明環境、參與團隊、測試資料與驗收條件。

若有測試結果，應保留執行環境、設定、版本、負載條件和重現方式；若環境尚未準備好，就先估設備或遠端環境的取得、權限審核、連線設定和測試協調，不要把尚未執行的驗證視為已完成。NCCoE 的遷移與互通材料可協助辨識互通驗證工作，但團隊投入仍須以自身測試計畫和結果估算。

以下對照表可用來選擇估算方式；三種方式都應附上可核對的假設，而不是用來替代工作項目明細。

將一次性改造與持續維運分開

正式上線後，仍可能有金鑰生命週期管理、設定維護、日誌監控、依賴升級、供應商支援追蹤和週期性複核。這些應列作持續投入，並註明預算涵蓋期間、系統範圍、責任團隊和複核觸發條件，不能和一次性的改造工時合併成無法解釋的總數。

可勾選以下項目，形成第一版估算底稿：

• [ ] 已列出納入本次預算的系統、環境與排除範圍。
• [ ] 每項密碼資產均有責任人；未知依賴已指定查核方式。
• [ ] 自研程式、第三方元件、憑證和服務介面分開列項。
• [ ] 相容性、效能、跨環境驗證、故障回退與發布演練均有負責方。
• [ ] 一次性遷移成本與持續維運成本分開記錄。
• [ ] 工時、內部成本與外部費用均有可核對的組織資料或實際報價。

用情境區間處理未知項目，不預設單價

已確認的工作量可按團隊紀錄與核定成本計入；供應商尚未確認的工作，應列為待確認並記錄詢問對象、回覆期限和責任人；高不確定性的依賴則設定低、中、高情境，逐一說明採用的假設。例如，情境差異可以來自支援版本是否可用、是否需要替換元件，或測試是否必須跨團隊協作，而非任意加上一個比例。

提交預算時，最好同時呈現每個情境的納入系統、待確認項目、工時來源和外部報價狀態。當資產盤點補齊、供應商確認支援方式或測試結果出爐後，再更新估算；這樣可以說明區間如何收斂，也能避免把規劃假設誤當成已核實的實際成本。

常見問題

以下問答補充估算模型如何落到企業預算表，特別是資產資料不足、供應商依賴尚未釐清時的處理方式。

企業的後量子密碼遷移預算應列入哪些工作？
除了程式與設定修改，也要列入資產發現、依賴核對、供應商協作、互通和效能測試、回退及發布演練，以及持續維運。每項工作都應有責任方和估算依據，並區分一次性投入與後續投入。

怎樣估算現有系統的 PQC 改造工作量？
先按系統拆分自研程式、函式庫、憑證及服務介面，再由負責團隊根據程式碼檢視、實際測試計畫、產品支援資訊和合約估算。未查清的依賴應列為待確認工作，而不是直接視為不需改造。

盤點結果如何轉成可審核的預算？
把每項資產連到業務系統、責任人和依賴來源，再分別記錄發現、分析、改造、驗證與維運工作。內部投入採組織工時和核定成本，外部投入採可核實報價；尚未確認的項目要保留在情境假設中。

哪些部分最難預估？
通常是未記錄的間接依賴、第三方產品支援狀態，以及跨環境互通、故障回退和發布驗證。這些項目需要實際清單、供應商回覆與可重現測試結果才能收斂，不能用通用比例或外部效能數字代替。

若現行做法依賴分散的測試環境、臨時申請權限，或不同團隊各自維護設定，估算時就要把環境準備、連線協調和結果重現納入成本；但若工作長期且負載穩定，自行維護專用環境也可能更合適。若預算包含遠端測試環境，可先依 Vuncloud 的 Mac 雲端租用資訊確認當期服務內容，再以價格頁面所列的實際資訊核算，不預設價格、規格或可提供的測試能力。