同社のガイダンスが示すのは、暗号化された通信を守るだけでは足りないという課題です。アプリケーション、デバイス、認証局、セキュリティインフラが、既存の信頼関係を損なうことなく新しいアルゴリズムに対応できるようにする必要があります。
同社のポスト量子暗号（PQC）Transport Layer Security（TLS）パイロットプログラムは、認証局がこうした変更を検証するための管理された環境を提供します。
Microsoftが2026年8月27日に発表した内容では、本格的な導入に先立って技術面・運用面の障壁を洗い出すため、7つのパイロットルートが指定されています。
企業にとってまず優先すべきは可視化です。セキュリティチームは、移行を単純な暗号のアップグレードと捉えるのではなく、どのシステムが証明書を発行、保管、配布、検証、更新しているのかを把握する必要があります。
ポスト量子への備えでは、攻撃者が暗号化された情報を収集し、将来の解読に備える「harvest now, decrypt later（今収集し、後で解読する）」攻撃に焦点が当たりがちです。
一方、認証は性質の異なる問題を抱えています。証明書チェーン、信頼されたルート、秘密鍵、そして複数のベンダーにまたがる連携プロセスに依存しているためです。
ある証明書があるアプリケーションでは正常に動作しても、別の環境では失敗する可能性があります。デバイス、ライブラリ、検査ツール、証明書管理プラットフォームのいずれかが、そのアルゴリズムや証明書サイズを処理できないことが原因です。
証明書やチェーンが大きくなれば、ハンドシェイクの性能、ストレージ容量、伝送上の制限、ネットワーク検査への影響も問題になります。
Microsoftのパイロットでは、参加する認証局に互換性の不具合を報告するよう求めています。対象は、証明書のパースエラー、TLSの相互運用性の問題、ハードウェアセキュリティモジュール（HSM）の制約、検証ツールや運用ワークフローでの障害などです。
報告には、可能な限り再現可能な例と影響を受けたシステムを含める必要があります。プログラムでは、ルート証明書にML-DSA-87を必須としています。
ML-DSA（Module-Lattice-Based Digital Signature Algorithm）はNISTが標準化したアルゴリズムで、大規模な量子コンピュータを持つ攻撃者に対しても安全性を保つよう設計されたデジタル署名を実現します。パイロットでは、下位の証明書やリーフ証明書にML-DSA-44とML-DSA-65の使用を認めています。csrc.nist+1
参加企業として挙げられているのは、ComSign、DigiCert、HARICA、IdenTrust Services、Sectigo、Shanghai Electronic Certification Authority、SSL.comの7社です。参加にはMicrosoftの承認と、同社のTrusted Root Programにおける良好な状態の維持が条件となります。
Microsoftのガイダンスは、証明書に依存するアプリケーション、サービス、デバイス、アプライアンス、インフラを組織が棚卸しするよう求めています。
チームは、そのうえで公開・非公開の証明書階層、トラストアンカー、外部で管理されている証明書、デバイス認証の関係を整理する必要があります。
ベンダーとの協議では、アルゴリズムのサポート状況、アップグレード計画、テスト能力、ハードウェア上の制約を取り上げるべきです。
長期運用される制御技術（OT）、組み込みデバイス、セキュリティアプライアンスは、入れ替えサイクルが移行を難しくする可能性があるため、特に注意が必要です。
テストは本番環境と切り離して実施しなければなりません。パイロット証明書は公的には信頼されておらず、本番サービスや一般公開のWebサイトの保護には使用できません。
Microsoftは、ML-DSAのサポートは限定的で発展途上にあり、同社の製品やライブラリ全体で完全に機能する保証はないとも警告しています。github
Microsoftは、2026年7月28日の更新プログラム以降でサポートされるWindows 11の構成を挙げています。サポート対象外のシステムでは、パイロットルートの処理時にNTE_BAD_ALGIDエラーが発生する可能性があります。テストを始める前にプラットフォームの確認が重要である理由を示しています。github
16,000以上のSOCチームがANY.RUNを活用し、脅威調査の効率化と手作業の削減を実現しています。チームでの利用を検討する
翻訳元: https://cyberpress.org/microsoft-urges-certificate-mapping/
