WindowsでNTLMが既定無効へ：30年続いた認証「遺産」を終わらせるMicrosoftの狙いと、現場が今すぐやるべき移行手順

Windowsの社内ネットワークで長年使われてきた認証方式「NTLM」が、今後のWindowsで“既定（デフォルト）で無効”になる方向に舵が切られました。狙いは、リプレイ攻撃や中間者攻撃、リレー攻撃、Pass-the-Hashなど、NTLMが抱え続けてきた構造的リスクを減らし、Kerberos中心のより堅牢な認証へ移行することです。TECHCOMMUNITY.MICROSOFT.COM+2BleepingComputer+2

• WindowsでNTLMが既定無効へ：30年続いた認証「遺産」を終わらせるMicrosoftの狙いと、現場が今すぐやるべき移行手順
  • NTLMとは何か：なぜ“いま”問題になるのか
  • 「既定で無効」は“削除”ではない：意味を取り違えない
  • 移行は3段階：2026年後半が大きな節目
    • フェーズ1：可視化と統制（監査の強化）
    • フェーズ2：移行の“詰まりどころ”を解消（2026年後半予定）
    • フェーズ3：次期主要リリースで“既定無効”へ
  • 企業がハマりやすい「NTLM依存」パターン
  • 今すぐやるべき実務チェックリスト（手戻り防止）
    • 1）NTLM監査を有効化し、依存元を棚卸し
    • 2）Kerberosが成立する前提条件を点検
    • 3）段階的に“NTLMなし”テストを回す
    • 4）どうしても残るレガシーは「例外」を設計する
  • まとめ：NTLM“既定無効”は、攻撃面を減らすための必然

NTLMとは何か：なぜ“いま”問題になるのか

NTLM（New Technology LAN Manager）は、1990年代初頭からWindows環境で広く使われてきた認証プロトコルです。ドメイン参加端末やファイル共有、古い業務アプリの認証など、企業ネットワークの「当たり前」のところに深く入り込んでいます。TECHCOMMUNITY.MICROSOFT.COM+1

しかしNTLMは、設計上「攻撃者に悪用されやすい条件」が残りやすいのが難点です。具体的には、サーバー真正性の担保が弱いケースがあり、弱い暗号利用や、監査・可視化の不足（近年は改善が進むものの）などが指摘されてきました。結果として、資格情報を踏み台にした横展開や、リレー攻撃などの温床になりがちです。TECHCOMMUNITY.MICROSOFT.COM+2BleepingComputer+2

「既定で無効」は“削除”ではない：意味を取り違えない

今回のポイントは「NTLMをWindowsから消す」ではなく、「ネットワークでのNTLM認証を自動では使わない（ブロックする）状態を既定にする」ということです。つまり、OSはまずKerberosなどのより安全な方式を優先し、それでも必要な場面だけ“明示的に”NTLMを許可する世界観へ変わります。TECHCOMMUNITY.MICROSOFT.COM+1

現場目線で重要なのは、放置していると、将来のWindows更新で“突然つながらない”が起き得る点です。反対に、今のうちに依存箇所を洗い出しておけば、移行は計画的に進められます。

移行は3段階：2026年後半が大きな節目

Microsoftは、NTLMを既定無効へ向けて段階的に進める方針を示しています。ポイントだけ押さえると次の流れです。TECHCOMMUNITY.MICROSOFT.COM+1

フェーズ1：可視化と統制（監査の強化）

まずは「どこでNTLMが使われているか」を把握するための監査（auditing）を強化。Windows 11 バージョン24H2、Windows Server 2025などで、NTLM利用の追跡・棚卸しを進めやすくします。Windows Central+2BleepingComputer+2

フェーズ2：移行の“詰まりどころ”を解消（2026年後半予定）

次に、Kerberosへ寄せたくてもNTLMにフォールバックしてしまう典型パターンを潰すため、IAKerbやLocal KDC（いずれも先行機能）などを提供し、Kerberosが成立しやすい条件を増やす計画です。開始時期として「2026年後半」が明示されています。Windows Central+2TECHCOMMUNITY.MICROSOFT.COM+2

フェーズ3：次期主要リリースで“既定無効”へ

最終的に、次の主要なWindows Serverリリースおよび関連するWindowsクライアントで、ネットワークNTLM認証が既定で無効になります。ただし、必要に応じてポリシーで明示的に再有効化できる余地は残す想定です。BleepingComputer+2SecurityWeek+2

企業がハマりやすい「NTLM依存」パターン

移行が難航しやすいのは、だいたい次のタイプです。

• ドメインコントローラーに到達できない状況（一時的な回線断、境界ネットワーク、特殊な拠点構成など）でNTLMへ逃げる

• ローカルアカウント認証が絡む運用（端末単体の管理、工場・店舗端末、検証用端末など）

• アプリやOSコンポーネント側で**認証方式が固定（ハードコード）**されていてKerberosを選べない

• 古いNAS、複合機、レガシーアプリがKerberos非対応または設定不備のまま運用されているTECHCOMMUNITY.MICROSOFT.COM+1

ここを「気合」ではなく、監査→対処の順番で淡々と潰すのが最短です。

今すぐやるべき実務チェックリスト（手戻り防止）

“既定無効化”は未来の話に見えますが、準備は早いほどラクになります。以下は優先度順です。

1）NTLM監査を有効化し、依存元を棚卸し

まずログで「誰が」「どこへ」「何のために」NTLMを使っているかを可視化します。端末だけでなく、サーバー側（ファイルサーバー、Web、RDS、業務アプリ）も対象に含め、依存関係マップを作るのがコツです。TECHCOMMUNITY.MICROSOFT.COM+1

2）Kerberosが成立する前提条件を点検

• SPNやDNS、時刻同期、ドメイン参加の整合性

• サービスアカウント運用（変更手順・管理粒度）

• 端末/サーバーの認証ポリシー（不要なフォールバックを許していないか）

Kerberosは強力ですが、前提条件が崩れると認証トラブルとして顕在化します。「Kerberosを使う」ではなく「Kerberosが安定して使える状態」を作るのが本質です。

3）段階的に“NTLMなし”テストを回す

本番一発勝負は危険です。検証環境や限定OUで、NTLMを無効化したときに壊れる業務を早期に炙り出します。Microsoft側も、非本番環境でNTLM無効を試しながら移行する姿勢を推奨しています。Windows Central+1

4）どうしても残るレガシーは「例外」を設計する

現実には、Kerberosへ移せない機器・アプリが一定期間残ります。その場合は「野放し」ではなく、

• 対象範囲を最小化（サブネット、サーバー、アカウントを限定）

• 期限付き（更新計画・入替計画とセット）

• 監視強化（継続利用が増えていないか）
  という統制された例外として扱うのが安全です。

まとめ：NTLM“既定無効”は、攻撃面を減らすための必然

NTLMは歴史が長いぶん、企業の運用に深く根を張っています。一方で、攻撃者にとっても“狙いやすい入口”になりやすいのが現実です。だからこそ、既定無効化は「突然の仕様変更」ではなく、Windows全体を安全な標準へ寄せるための必然だと捉えるべきです。TECHCOMMUNITY.MICROSOFT.COM+2SecurityWeek+2

重要なのは、フェーズ3が来てから慌てるのではなく、フェーズ1の監査で依存を洗い出し、2026年後半のフェーズ2で移行の詰まりを解消し、段階的に“NTLMなし”へ慣らしていくこと。これが、停止事故とセキュリティリスクの両方を最小化する最短ルートです。