Microsoftは2026年7月22日、企業内でWindowsを一括認証するKey Management Service（KMS）の信頼をTPMへ結び付ける「KMS Hardware-Secured」を発表した。Windows Server 2025には8月から準備状況を知らせる機能を加え、次のWindows Server長期サービスチャネル（LTSC）ではTPMベースの証明を必須にする。狙いは、偽造または複製されたKMSサーバーが正規ホストを装う余地を狭めることだ。
ただし、8月に非正規Windowsが一斉に使えなくなるわけではない。今回の対象は各PCではなく、組織内の認証要求をさばくKMSホストである。Microsoftが変えようとしているのは、Windowsの正規性を端末ごとに調べる方法ではなく、認証を発行するサーバーをどう信頼するかという前提だ。
2026年8月は「適合可否」の表示から始まる
Windows Server 2025では2026年8月から、KMSホストがハードウェアベースの保護に対応できるかを管理者へ通知する。slmgr /dlvには適合または不適合のメッセージが現れ、イベントログにも警告が記録される。これは強制開始ではなく、次期LTSCへの移行準備を促す機能である。
物理KMSホストを使う組織に対し、MicrosoftはWindows Server Catalogで認証されたサーバーかどうかを確認し、TPMを搭載して有効にするよう求めている。TPMがKMSに必要なキー認証機能を備えるかは、管理者権限のPowerShellで次のコマンドを実行すれば確認できる。
Get-TpmSupportedFeature -FeatureList "Key Attestation"
応答にKey Attestationが含まれれば、KMS Hardware-Securedが使うTPM認証機能に対応している。一方、必須化の時期についてMicrosoftが明らかにしたのは「次のWindows Server LTSCリリース」までだ。製品名、提供日、強制開始までの猶予、非対応ホストの扱いは発表に含まれていない。
KMSがソフトウェア応答を信じてきた理由
KMSは、大規模組織が端末ごとにMicrosoftへ接続せず、社内サーバーを介してWindowsをまとめて認証する仕組みである。管理者はKMSホストに顧客固有のボリュームライセンスキー（CSVLK）を入れ、Microsoftがそのホストキーを検証する。以後、クライアントはDNSからKMSホストを見つけ、Generic Volume License Key（GVLK）に対応する認証を要求する。
| 現行KMSの要素 | 仕組み |
|---|---|
| ホストの準備 | CSVLKを入れ、Microsoftがホストキーを検証する |
| クライアントの発見 | GVLKを持つ端末がDNSでKMSホストを探す |
| 認証しきい値 | Windowsクライアントは25台、Windows Serverは5台 |
| 更新周期 | 既定で7日ごとに再認証を試み、180日以内の接続が必要 |
KMSホストは要求元のクライアントIDを数え、台数を応答に含める。クライアントは、その台数がしきい値を満たすと認証される。Microsoftの現行資料によると、このIDは恒久保存されず、同社にも送信されない。KMSは組織の内部で完結しやすい設計だからこそ、クライアントが接続する先を偽造できれば、正規の社内認証基盤に見せかけられる。Microsoftが問題視する偽造・複製KMSサーバーは、この信頼点を狙う。
KMS Hardware-Securedは、ホストキーの正しさに加えて、そのキーを扱う機械の身元を検証対象に加える。つまり、正しい形式のソフトウェア応答を返せるかでは足りず、Microsoftが認めるハードウェア上でKMSが動いていることも示さなければならない。
TPMが認証ホストの身元と状態を結び付ける
TPMは秘密鍵をチップの外へ出さず、鍵を特定のハードウェアや起動時の測定値に結び付けられる。一般的なTPMキー認証では、信頼されたTPMが秘密鍵を保護していることを暗号学的に証明する。ソフトウェアの設定ファイルをコピーする方法では、同じ証明を別の機械へ持ち出しにくい。
Microsoftが示したKMS Hardware-Securedの流れは三段階である。まず、KMSホストがTPMに裏づけられたハードウェアIDを提示し、Microsoftが証明を検証する。次にTPMを使ってホストのプラットフォーム完全性を確かめる。検証を通過したホストが、組織内のWindows端末から届く認証要求を処理する。
この変更は、偽造KMSサーバーを動かすコストを引き上げる。認証に必要な秘密をTPMへ結び付けることで、ソフトウェア構成の複製やなりすましを難しくするためだ。正規ライセンスを運用する企業も、侵害されたKMSホストから認証情報を盗まれ、別の環境で使われる危険を減らせる。
もっとも、MicrosoftはKMS固有の証明プロトコルをまだ公開していない。どのプラットフォーム測定値を評価するのか、証明に失敗したホストをどう復旧させるのか、Microsoftへ送るデータに何が含まれるのかは不明である。TPMによる身元確認は偽造ホストを狙った防御であり、あらゆる非正規認証手法を止める保証ではない。
Windows 11のTPM 2.0要件とは対象が違う
Windows 11は最小ハードウェア要件としてTPM 2.0を求めている。だが、これはWindows 11を導入するクライアント側の条件だ。KMS Hardware-Securedの発表は、認証要求を受けるKMSホストへTPMベースの証明を加えるもので、個々のクライアントに新しいTPM検査を課すとは述べていない。
影響が及ぶ認証方式もKMSに限られる。Windowsのボリューム認証には、端末がMicrosoftのサービスへ接続するMultiple Activation Key（MAK）や、ドメイン内の認証オブジェクトを使うActive Directoryベース認証がある。RetailやOEMの認証も経路が異なる。KMSの変更をWindows認証全体の一律なTPM必須化と受け取ると、実際の移行範囲を見誤る。
Active Directoryベース認証は、対応OSを使うドメイン参加端末だけの環境ならKMSホストを取り除ける場合がある。対して、ワークグループ端末や古いボリュームライセンス製品を残す組織ではKMSが必要になる。管理者はTPM対応サーバーへの更新と同時に、そもそもKMSを維持すべき端末がどれだけあるかを洗い直すことになる。
仮想KMSホストに残る要件の空白
Microsoftの現行ガイドは、KMSホストを対応Windows上の物理マシンまたは仮想マシンに置けるとしている。1台が扱えるKMSクライアント数に上限はなく、可用性を確保するため最低2台のホストを推奨する。少数のKMSホストが全社の認証を担う構成では、移行対象の台数は限られても、停止時の影響は大きい。
ところが、KMS Hardware-Securedの発表が示した準備手順は物理ホスト向けである。仮想環境の指針は今後のブログで案内するとされ、仮想TPMだけで条件を満たすのか、基盤となる物理ホストの証明まで必要なのか、クラウド上のWindows Serverをどう扱うのかは示されていない。仮想化している企業は、8月の適合表示が出ても、それだけで移行設計を確定できない可能性がある。
今回の変更は、海賊版Windowsを端末側で見つける新機能というより、認証を発行できるKMSホストをハードウェアで絞り込む措置である。管理者が次に確認すべきなのは、Windows Server 2025の警告内容に加え、Microsoftが示す仮想ホストの証明条件と次期LTSCの強制日だ。その二つが揃って初めて、TPMの有効化で済むのか、KMSホストの更新や認証方式の組み替えが必要なのかを決められる。
