Google Cloud公布PQC轉型路線圖，目標2029年前完成部署，2027年底先降低SNDL風險，2028年底擴及簽章、身分與金鑰管理。現有API、load balancer與Cloud KMS已開始支援多項量子安全機制。
Google Cloud近期公布後量子密碼學（Post-Quantum Cryptography，PQC）部署路線圖，目標是在2029年前完成整體轉型；其中，2027年底前會優先降低現有加密資料未來遭量子電腦破解的風險，2028年底前再推進身分、數位簽章與金鑰管理等領域的PQC部署。這項規畫顯示，量子威脅已從長期議題轉為雲端平台必須分階段處理的實務工程。[1]
目前，Google Cloud API端點已提供量子安全金鑰交換，並採混合模式，同時使用現有金鑰交換機制與抗量子密碼演算法ML-KEM；Application load balancer與Proxy load balancer也可選擇啟用混合式金鑰交換機制。Cloud KMS則已正式支援ML-KEM、ML-DSA及SLH-DSA，這些都是NIST納入正式標準的抗量子密碼演算法。[1][2]
這份路線圖最核心的技術重點，是先處理「先儲存、後解密」（Store Now, Decrypt Later，SNDL）風險。SNDL的威脅模型很直接：攻擊者先大量攔截今天尚無法破解的加密資料，等到量子運算能力成熟後再回頭解密，因此即使資料現在看似安全，長期機密性仍可能失守。[1][3]
Google Cloud將轉型順序切分為多個層次，先從資料傳輸與邊界流量下手，再逐步延伸到可驗證性更高、生命週期更長的數位簽章與身分控制。這種排序反映出PQC遷移的實務難點：傳輸層可以先透過混合式金鑰交換降低風險，但憑證、簽章與身分系統牽涉到更廣泛的信任鏈、相依套件與相容性驗證，因此需要更長的導入週期。[1][3]
值得注意的是，Google Cloud採用混合模式，而不是直接全面切換到單一PQC演算法。這代表現階段的設計哲學是「漸進式安全提升」：一方面保留既有成熟機制的互通性，另一方面用ML-KEM等量子安全演算法建立新保護層，降低單點失敗與生態未成熟所帶來的風險。[1]
從標準化角度看，Cloud KMS已支援ML-KEM、ML-DSA與SLH-DSA，意味著PQC不再只是實驗性功能，而是已進入雲端密鑰管理的正式部署階段。對企業而言，這也表示PQC遷移已從「演算法選型」進入「資產盤點、系統相容性與營運流程調整」的工程期。[1][2]
這次路線圖對受影響最深的，首先是依賴Google Cloud進行資料傳輸、跨站連線與內部服務互通的組織。Cloud VPN、Cloud Interconnect及其他資料傳輸相關服務預計在2026至2027年間導入PQC支援，代表只要企業流量經過這些通道，未來就可能需要配合新的密碼套件與連線策略。[1][3]
第二個受影響面向是身分與憑證生態。數位簽章、數位憑證、身分驗證與存取控制一旦進入PQC轉換期，企業不只要更新伺服端設定，也要重新檢視客戶端、SRE工具、憑證發放流程、簽章驗證與自動化部署管線的相容性。[1][3]
第三個影響面向是金鑰管理與治理。Cloud KMS雖已支援多種量子安全演算法，但企業若未先盤點金鑰、憑證與相關密碼資產，仍無法有效排序遷移順序。換言之，PQC不只是安全功能升級，更是資產治理與風險管理的重新編排。[1]
企業應先建立完整的密碼學資產清冊，至少涵蓋金鑰、數位憑證、憑證鏈、TLS使用點、API整合點與跨雲連線通道。只有先釐清哪些系統承載長期敏感資料，才能判斷哪些資料最需要優先對抗SNDL風險。[1]
其次，開發與維運團隊應檢查現有應用程式是否能在量子安全API與混合式金鑰交換模式下正常運作。Google Cloud已提供部分可用功能，因此測試重點不只是「能不能連線」，還包括憑證驗證、握手相容性、代理層轉發與自動化腳本是否受到影響。[1]
第三，應提前更新依賴的程式庫與工具鏈，讓開發、部署與監控流程能支援PQC相關機制。這對內部SRE、CI/CD與基礎架構即程式碼流程尤其重要，因為密碼套件的改動往往會向下游擴散，形成隱性故障。[1]
最後，企業應把PQC納入中長期資安與合規規畫，而不是等到量子威脅成熟後才被動應對。Google的路線圖已清楚顯示，PQC遷移會先從傳輸層開始，再延伸到簽章、身分與金鑰管理；因此，越早完成盤點與驗證，越能降低後續切換成本與營運中斷風險。[1][3]