當產品的 PQC 升級受限，誰有權決定繼續支援？

技術路徑走到硬體與信任鏈邊界時，企業要說清楚支援期限、客戶通知與退場責任。

文／游政卿

◤作者游政卿現為合勤投資控股（ZyXEL Group）資安長，EC-Council C|CISO；台灣資安主管聯盟副會長。負責合勤集團資安治理、產品安全、供應鏈安全與永續相關策略，直接向董事長室匯報。

談到後量子密碼（PQC）遷移，我在產品會議裡常聽到一句話：「請產品線提出全面升級時程。」對新產品提出這項要求相對容易；已出貨多年、分散於各種客戶環境的設備，升級條件落差很大。有些型號具備完整轉換空間，有些僅能調整部分功能，另有些受硬體設計限制，轉換空間極小。到了這一步，我更在意決策權責：誰能核准這些產品繼續支援，以及公司準備如何向客戶交代。

企業應依密碼風險、保護年限與替換工期，分級安排設備汰換節奏。目前量子電腦距離具備實務破解主流 RSA 與 ECC 的能力仍有差距。投入時點取決於產品採用的密碼機制、信任維持年限，以及完成替換所需時間。短期保護且即將退場的系統，與韌體簽章需要維持十年的設備，採相異優先順序。若省略保護年限與替換工期的分級，PQC 容易形成焦慮採購；若整體延後，長生命週期產品則可能錯過可控的遷移窗口。

[ 加入 CIO Taiwan 官方 LINE 、 Facebook 與 LinkedIn，與全球CIO同步獲取精華見解 ]

美國國家標準暨技術研究院已公布 FIPS 203、204 與 205 三項後量子密碼標準。英國國家網路安全中心建議分三個節點規劃。2028 年前完成盤點與初步計畫；2031 年前完成最高優先項目並補齊完整路線圖；2035 年以完成所有系統、服務與產品遷移為目標。該指引也指出，少數技術可能需要更長的轉換時間。對台灣企業而言，這些節點屬於規劃座標。先找出到了 2035 年仍可能留在客戶現場的產品，再往回估算測試、認證、韌體發布與客戶換機所需時間，才能形成按型號排序的遷移清單。

內容目錄 隱藏

硬體信任根決定演算法的替換空間

升級障礙往往超出韌體版本範疇。一款設備的安全開機若綁在固定於硬體的信任根，即使應用層可以調整，整條信任鏈的轉換空間也會受硬體設計約束。新金鑰與簽章所需資源可能超出處理器與記憶體容量；通訊協定或上游安全模組也可能僅支援既有演算法。工程團隊即使完成韌體，客戶現場還要承擔停機、復原與驗證風險。工程團隊交出版本只是第一步。客戶現場還要完成部署、復原與驗證，遷移流程才算走完。

跨部門的責任斷點通常出現在這裡。研發於技術紀錄中註明硬體僅支援既有演算法，產品單位維持原有支援說法，業務照原條件續約，資安風險清單則保留一項待處理事項。各單位都完成了自己的工作，公司層級需要指定風險承擔者，並設定支援截止日。等客戶開始追問，技術條件已經轉成責任缺口。

遇到這種情況，我建議團隊先完成技術可行性評估，再進入風險接受程序。格式可以精簡，第一步先把受影響型號和密碼機制用在哪裡列清楚。接著記錄替代方案測試結果與上游元件支援狀態，產品負責人再補上出貨範圍、剩餘支援年限和主要使用情境。這些資料擺在一起，才看得出問題出在資源排程還是設計邊界，也才知道下一步要追加投入，或設定支援期限與退場安排。

技術邊界確認後，決策回到產品治理

產品負責人先交代繼續支援的理由與範圍；研發說明可維持的安全功能，資安團隊提出殘餘風險。法務與業務再確認合約和客戶承諾。涉及關鍵基礎設施、長期簽章信任或大量在役設備的型號，交由產品治理或經營團隊核准。決議要寫明支援期限、重新檢視日期與提前終止條件，讓後續續約有明確邊界。

如果公司決定暫時繼續支援，緩解措施應列明維護單位、有效期限與失效後處置，並納入同一份風險決議。透過支援 PQC 的閘道建立外層保護通道、限制遠端管理、隔離網路或縮小功能範圍，可以降低曝險並爭取轉換時間；設備本身維持原有密碼能力。對外則要明確區分「降低曝險」與「完成 PQC 遷移」。

客戶通知與退場必須一起規劃

產品單位顧慮續約，工程團隊等待方案確認，法務評估技術揭露範圍。相關單位應共同設定通知期限，確保客戶在採購、續約或停止支援前，掌握產品的既有密碼能力與替換安排。企業可保留敏感設計細節，同時說明受影響版本、維護範圍、必要設定與建議替換時間。若牽涉韌體簽章、裝置身分或管理連線，產品安全事件應變團隊（PSIRT）、客服、業務與法務要使用同一份核准內容，通知與客戶回覆也要留存。

[ 閱讀所有游政卿的文章 ]

對關鍵基礎設施、醫療與營運技術（OT）環境來說，換機通常需要跨越多季，並配合預算與維護窗口。停止支援公告應同時交代替代產品、移轉安排、舊設備設定與金鑰處理，以及客戶選擇繼續使用時的責任邊界。路線提出得越晚，客戶可用的預算與維護安排空間越小，製造商也更可能承擔超出安全維護能力的支援承諾。