姜景懷表示，企業可以管理資料中心內部伺服器與應用系統，卻難以控制使用者端裝置、行動網路或公共Wi-Fi環境，因此對外服務建立TLS連線的入口，是PQC遷移值得優先檢視的位置。大型企業的重要Web、API及行動服務前端，通常會部署應用交付閘道、負載平衡與網站應用防火牆（WAF）等設備，TLS連線也常在此終結與重新建立，使其具備集中治理條件。
以F5的應用交付與安全平台BIG-IP為例 ，姜景懷指出，BIG-IP採用全代理式（Full Proxy）架構，用戶端會先與BIG-IP建立TCP與TLS連線，再由BIG-IP另行與後端應用伺服器建立連線，使前端與後端的協定及加密機制可以分開處理。即使既有後端應用仍使用較舊TLS版本，也能透過中介層降低大量修改應用產生的相容性衝擊。BIG-IP可讓前端使用TLS 1.3與X25519＋ML-KEM，同時銜接使用TLS 1.2或其他既有機制的後端服務。
F5資深解決方案技術顧問姜景懷指出，企業可由TLS入口盤點加密資產，逐步導入Hybrid PQC並評估效能與相容性。
PQC遷移前仍須掌握現有加密資產。姜景懷說明，可透過OpenTelemetry等可觀測性機制，整合BIG-IP收集TLS版本、金鑰交換方式與連線資訊，辨識各項服務採用的TLS版本及金鑰交換機制，再連結至實際應用服務，作為升級優先順序與容量規畫依據。 憑證生命週期管理也是TLS治理的重要環節。當憑證有效期限持續縮短，人工申請、更新與撤銷將增加維運負擔。姜景懷指出，企業可採用自動憑證管理環境（ACME）協定，ACMEv2可透過TLS-ALPN-01等驗證方式自動完成憑證申請、簽發與更新，簡化大量TLS服務的憑證管理。
進入Hybrid PQC階段後，TLS金鑰建立可同時使用傳統X25519與後量子ML-KEM。姜景懷表示，混合式設計可兼顧既有生態系統相容性與量子風險防護；若連線端未支援Hybrid PQC，則可依雙方支援的金鑰交換機制回復使用傳統方式。不過，加入ML-KEM後，ClientHello攜帶的金鑰交換資料增加，原先可置於單一網路封包的ClientHello可能拆分為多個封包，也會增加TLS交握階段的設備處理負荷。
因此，企業評估PQC不能只確認功能支援，也須測試SSL每秒交易量、連線數與實際服務分布。姜景懷建議，先完成加密資產盤點及TLS 1.3升級，再針對高風險服務測試Hybrid PQC金鑰交換機制，觀察效能與相容性。大型環境面臨更高連線量時，也可將負載平衡與全代理及SSL卸載分層配置，以橫向擴充承接額外負荷。
2026 PQC Taiwan｜企業後量子安全高峰論壇特別報導—會後報導：