Windows 10からWindows 11へ大量移行でCredential Guardを無効化すべきか？影響と500台向け手順

Windows 10 22H2（19045）からWindows 11（23H2/24H2）へ500台規模でインプレースアップグレードする際、「Windows Credential Guard（資格情報ガード）を無効化した方が移行が安定するのでは？」と悩むことがあります。結論から言うと、原則は有効のまま移行し、問題が出る端末だけを例外的に扱う方が、長期的に安全で運用もラクになります。

結論：全台でのCredential Guard無効化はおすすめしない

大量移行の現場で一番怖いのは「将来、気づかないうちに侵害が広がる」ことです。Credential Guardは、端末が侵害された場合の“横展開”を難しくするための重要な防波堤であり、安易な全台無効化はリスクが大きすぎます。

移行の安定性は、パイロット検証と例外運用で担保できる
無効化によるセキュリティ低下は、端末台数が多いほど被害が指数的に増えやすい
Windows 11では、条件を満たす端末でCredential Guardが既定で有効化されるケースがあるため、無効化前提の設計は将来コストになりやすい

特にWindows 11 22H2以降は、要件（ライセンスやハードウェア要件など）を満たす端末でVBSとCredential Guardが既定で有効化されます。つまり「移行したらいつの間にか有効になっていた」「特定の端末だけ挙動が変わった」という事象を前提に計画しておくと、500台展開でも事故が減ります。

最初に確認：Windowsエディションとライセンス要件

意外と見落とされがちなのが、Credential GuardはWindows Proでは正式サポート対象外という点です。端末がWindows 11 Enterprise/Educationなのか、Windows 11 Proなのかで、設計・説明の仕方が変わります。

Windowsエディション	Credential Guardのサポート	注意点
Windows Enterprise	対応	既定有効化の対象になりやすい（要件を満たす場合）
Windows Education	対応	同上
Windows Pro	非対応（原則）	過去にEnterprise等で有効化していた端末がProへダウングレードした場合、条件次第でVBS/Credential Guardが自動的に有効化されるケースがある

上記の可否・注意点は、Microsoftが公開しているエディション/ライセンス要件に基づいて整理しています。

そもそもCredential Guardとは何を守る仕組みか

Credential Guardは、NTLMのパスワードハッシュやKerberosのTGT（チケット）など、Windowsが認証に使う“価値の高い資格情報”をOS本体（ユーザーや管理者権限で動くプロセス）から分離して守る仕組みです。具体的には、VBS（Virtualization-based security）で隔離領域（Virtual Secure Mode）を作り、その中に秘密情報を閉じ込めます。

観点	Credential Guard 無効	Credential Guard 有効
資格情報（NTLM/Kerberos）の所在	LSASS等のOS側メモリに残りやすい	VBSの隔離領域に分離され、OS側から取り出しにくい
侵害後の横展開	Pass-the-Hash / Pass-the-Ticket系が通りやすい	同系統の手口が成立しにくくなる
“侵害前提”の防御	侵害されたら詰みやすい	侵害されても被害を広げにくくする

ポイントは、Credential Guardは“万能”ではないものの、攻撃者が最も狙う領域（資格情報の抽出）に対して効く対策だということです。だからこそ、安定化目的で雑に無効化すると、被害の大きさが跳ね上がります。

よく混同するポイント：Credential GuardとMemory integrity（HVCI）は別物

「Credential Guardを切ったら速くなるのでは？」という相談は多いのですが、体感性能に影響しやすいのはCredential Guardそのものより、同じVBSファミリーのMemory integrity（HVCI / Hypervisor-enforced Code Integrity）の方です。Win32_DeviceGuardの出力でSecurityServicesRunningに2が含まれている場合、HVCIが稼働しています。

機能	主な目的	現場で目立つ影響	確認の目安
Credential Guard	資格情報（NTLM/Kerberos等）の保護	MSCHAPv2/NTLMv1/一部SSOの挙動変化が出やすい	SecurityServicesRunning に 1
Memory integrity（HVCI）	カーネルのコード整合性強化	古いCPU/ドライバで性能影響・互換問題が出やすい	SecurityServicesRunning に 2

Microsoftの説明でも、古いCPUではHVCIがエミュレーション（Restricted User Mode）になり、性能影響が大きくなる可能性があります。また、HVCIは“対応していないドライバがあると不安定になる/起動に失敗する”リスクがあるため、全台一斉に有効化するのではなく、テストグループで段階的に検証してから広げるのが安全です。

無効化すると起きやすいこと：デメリットを具体化

「無効化＝トラブル回避」のイメージが先行しがちですが、500台規模では“無効化による負債”が目立ちます。代表的なデメリットを、現場で起きる形に落とすと以下です。

起きやすい問題	なぜ困るか	500台規模での現実的な影響
資格情報の盗難リスクが上がる	端末内で奪われた資格情報が、別サーバーへの認証に転用されやすくなる	1台の侵害が、ファイルサーバー／業務アプリ／管理系へ連鎖しやすい
侵害時の被害が拡大しやすい	横展開の難易度が下がるため、攻撃者の“滞在時間”が伸びる	検知・封じ込めに時間がかかり、復旧の人件費が膨らむ
監査・説明コストが増える	「なぜ守れる機能を切ったのか」を説明し続ける必要が出る	ゼロトラストやセキュリティベースライン適用の足かせになる

逆に言うと、“無効化しないと困る理由”がある場合は、機能を切るのではなく依存している古い仕組みを直す方が根本解決になります。

「有効だと困る」代表例と、無効化しない回避策

Wi-Fi／VPNのSSOが失敗する（PEAP-MSCHAPv2等）

Credential Guardが有効だと、MS-CHAPv2（例：PEAP-MSCHAPv2、EAP-MSCHAPv2）やNTLMv1など、パスワードベースで“クライアント側に秘密を置く前提”のSSOが成り立ちにくくなります。その結果、毎回資格情報入力を求められたり、保存しても次回使えなかったりします。

ここでやりがちな誤りが「SSOを維持したいからCredential Guardを切る」です。Microsoft自身が、MSCHAPv2ベースのWi-Fi/VPNから証明書ベース（EAP-TLS/PEAP-TLS）へ移行することを推奨しています。

項目	PEAP-MSCHAPv2	EAP-TLS（証明書）
セキュリティ強度	パスワード依存。攻撃の研究も多く、設計が古い	証明書で端末/ユーザーを識別。パスワード露出の面が小さい
Credential Guardとの相性	SSOが壊れやすい（毎回入力になりがち）	基本的に阻害されにくい
運用負荷	導入は簡単だが、長期的に例外が増えやすい	PKI/証明書配布が必要。ただし一度整えると安定

現実的な移行手順（最短ルート）は次の流れです。

現状棚卸し：Wi-Fi/有線802.1X/VPNで「MSCHAPv2依存」が残っていないか確認
RADIUS（NPS等）側でEAP-TLSを受けられる設計に変更（サーバー証明書、クライアント証明書の要件整理）
証明書配布：IntuneならSCEP/PKCSプロファイルで端末証明書を自動配布（社内CA or クラウドCA）
Wi-Fi/VPNプロファイル配布：まずパイロット端末に限定して配布し、切替ウィンドウを作る
リング展開：部署・拠点・端末機種ごとに順次切替し、最後にMSCHAPv2を撤去

また、切り分けの際はイベントログが役に立ちます。例えばApplication and Services Logs > Microsoft > Windows > NTLM > Operationalで、Credential Guardによりブロックされた挙動（NTLMv1など）を拾えるケースがあります。

RDPや一部の資格情報保存が使いづらい

Credential Guardが有効な端末では、Credential Managerに保存した“Windows資格情報”がRDPクライアント経由で送れないなど、資格情報の扱いが制限されることがあります（結果として「保存したはずなのにログオン失敗」になりやすい）。

運用回避：RDPは“保存に頼らない”設計（踏み台・管理端末の整理、特権アクセスの分離）へ寄せる
ユーザー体験：どうしても必要なら、初回だけ入力させる/SSO前提を捨てる範囲を明確化する
代替案：Windows Hello for BusinessやFIDO2等、パスワード以外の認証へ寄せていく

古いKerberos/NTLM設計・古いアプリが引っかかる

Credential Guardは、環境を安全側に倒すために「危険度の高い認証要素」をブロックします。たとえばNTLMv1、MS-CHAPv2、Kerberosの非推奨構成（無制約委任、古い暗号など）に依存していると、運用上の“今まで通っていた動き”が通らなくなります。

特にKerberosの無制約委任は推奨されない運用であり、Credential Guard有効時は使えません。委任が必要な領域は、制約付き委任（KCD）やリソースベース制約付き委任（RBCD）など、互換性と安全性を両立する方式へ寄せるのが定石です。

VBSが絡む周辺影響（仮想化ソフト、ドライバ、セキュリティ製品）

Credential GuardはVBSを使うため、同じくハイパーバイザーを使う製品（例：一部のデスクトップ仮想化ソフト）や、カーネルに深くフックする製品・ドライバが影響を受けることがあります。特に“端末標準イメージに入っている常駐ソフト”ほど、全台展開前の検証が重要です。

500台規模インプレースアップグレードの現実的な進め方

「Credential Guardを切る/切らない」だけを議論しても、移行は安定しません。500台クラスでは、前提を揃え、影響の出る端末を早期に炙り出し、例外の出口を用意するのが勝ちパターンです。

事前チェックリスト（やらないと後で詰みやすい）

チェック項目	確認方法（例）	OKの目安	NG時の打ち手
Windowsエディション/ライセンス	デバイス情報、契約/割当確認	Enterprise/Education（または方針に合う状態）	Pro混在なら、既定有効化の挙動を含めて運用設計を分ける
UEFI/Secure Boot	msinfo32、BIOS設定	UEFI + Secure Boot有効	BIOS更新後に設定が戻ることがあるため、標準手順に“再確認”を入れる
仮想化支援（VT-x/AMD-V等）	BIOS設定、Win32_DeviceGuard	VBSがRunningになれる状態	古い機種は対象外リングに回す/更新計画へ
TPMの状態	tpm.msc、運用手順	TPMが有効で、安易にクリアしない運用	ヘルプデスク手順に“TPMクリアの影響”を明記
Wi-Fi/VPNの認証方式	構成プロファイル、RADIUS設定	MSCHAPv2依存が把握できている	EAP-TLS/PEAP-TLS移行をパイロットで先に進める
古い認証/委任の残骸	AD設定、アプリ要件、ログ監視	NTLMv1/無制約委任などの依存が棚卸し済み	置換/KCD/RBCDなどへ移行し、例外を減らす
UEFIロック運用	Intune/GPO設計	当面は“ロックなし”で戻せる設計	ロックは互換性が読めてから段階的に検討

Secure Bootは要件の一つで、TPMは必須ではありませんが推奨です。対応しているほどCredential Guardの防御が厚くなり、組織の説明もしやすくなります。

フェーズ	やること	成果物（例）	失敗しやすい点
事前準備	端末機種・BIOS・ドライバの標準化（可能なら機種を絞る） Wi-Fi/VPN認証方式の棚卸し（MSCHAPv2依存の有無）業務アプリの認証方式棚卸し（NTLMv1/委任/旧暗号など） Credential Guardの方針決定（基本は有効、例外は限定）	移行チェックシート、例外運用ルール、パイロット対象リスト	「後で直す」が積み上がり、本番で爆発する
パイロット	“特殊端末”を混ぜる（古い業務アプリ、特殊VPN、特殊NICなど）アップグレード後の業務シナリオを通しで確認 Credential Guard有効状態でのWi-Fi/VPN接続検証	既知のNGパターン一覧、回避策（設定/置換）	良い端末だけで試して「成功」と誤認する
段階展開（リング）	部署/拠点/機種でリング分割不具合が出たらリングを止め、例外端末だけ別ルートへサポート窓口の一次切り分けテンプレを用意	リング進捗、障害対応ナレッジ、除外端末台帳	“全台一斉”で炎上し、原因追跡ができなくなる
事後運用	Credential Guard稼働状況の継続監視イベントログ/監視で認証系エラーを拾う例外端末の再評価（恒久無効化を増やさない）	監視項目、月次レビュー、例外の縮小計画	例外が固定化して“穴”として残る

移行後に必ずやる：Credential Guard稼働確認（3つの方法）

System Information（msinfo32）で確認

手早く確認したい場合は、msinfo32（システム情報）で「Virtualization-based Security Services Running」等の項目にCredential Guardが出ているかを確認します。

PowerShell（Win32_DeviceGuard）で機械的に判定

大量端末では、GUI確認よりもPowerShellで揃える方が確実です。代表的には次のように取得できます。

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object -First 1 -Property SecurityServicesConfigured,SecurityServicesRunning,VirtualizationBasedSecurityStatus

SecurityServicesRunningは配列（例：{1,2}）で返ることがあり、値の意味は概ね以下です（1がCredential Guard）。

値	意味（SecurityServicesRunning）	現場での見方
0	サービスが動いていない	VBS自体が無効/非稼働の可能性
1	Credential Guardが稼働	「有効」の判定キー
2	Memory integrity（HVCI）が稼働	ドライバ互換や性能影響の議論が必要になることがある

補助的に、VirtualizationBasedSecurityStatusも見ると切り分けが早くなります。値が2ならVBSが有効かつ稼働中、1なら有効だが稼働していない、0ならVBS自体が無効です。Credential Guardが動かない端末では、まずここを見て「VBSがそもそも起動できていない」ケースを先に潰すのが近道です。

イベントログで「いつ・なぜ動かなかったか」を追う

「有効にしたはずなのに動いていない」「一部端末だけ動かない」などの切り分けには、イベントログが効きます。WinInitソースのイベントで、Credential Guard起動/設定状況や失敗理由を追えます。

どうしても無効化が必要な場合：全台ではなく“例外運用”に落とす

現実には、特殊なVPNクライアントや古い業務アプリが残っていて、どうしても問題が解消できない端末が出ます。そこで重要なのは「全台無効化」ではなく、例外端末だけ、限定された期間・限定された条件で無効化し、移行後は戻すことです。

なお、Credential GuardをIntune/GPO/レジストリで明示的に無効化すると、Windows 11へアップグレードしても既定有効化で勝手に戻ることはありません。つまり「一時的に切ったつもりが、そのまま放置される」事故が起きやすいので、例外端末は台帳化して“戻す”までを作業範囲に含めてください。

状況	推奨アクション	補足
MSCHAPv2系のWi-Fi/VPNでSSOが壊れた	EAP-TLS/PEAP-TLSへ移行を本線にする	緊急回避として一時無効化はあり得るが恒久化しない
アップグレード工程で特定端末だけ失敗する	アップグレード中のみ一時無効→完了後に再有効	例外端末を台帳化し、再有効化までを“作業完了条件”に含める
恒久的に無効化せざるを得ない	リスク受容（承認）＋代替統制（最小権限、端末隔離、追加監視）	「いつまでに置換するか」を期限付きで決める

無効化の手段：Intune／GPO／レジストリ（UEFIロックに注意）

Credential Guardは、Intune（設定カタログやCSP）、グループポリシー、レジストリで制御できます。運用上の最重要ポイントは、リモートで戻せるように「UEFIロックなし」を基本にすることです。

Intune（設定カタログ）での基本

Device Guard → Credential Guard：Enabled without lock（基本）／Disabled（例外）

「将来オフにできる余地」を残したいなら、Enabled with UEFI lockではなくEnabled without lockを選びます。

Credential Guardは、理想は端末がドメイン参加する前、またはドメインユーザーが初回サインインする前に有効化しておくと、資格情報が既に露出した状態になるリスクを減らせます。リプレースやAutopilotで新規配備する端末が混ざる場合は、ここも合わせて設計しておくと安心です。

MDMカスタム（CSP）で明示する場合

設定カタログを使わず、CSPで制御したい場合は次の値を使います（環境によりポリシー競合が起きやすいので、運用ルールを決めてからにすると安全です）。

./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity：1
./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags：0（無効）/ 1（UEFIロック有効）/ 2（ロックなし有効）

GPOでの基本

Active Directory管理下なら、Computer Configuration > Administrative Templates > System > Device Guard の「Turn On Virtualization Based Security」で制御します。

レジストリでの基本（例外端末の緊急回避に使うことが多い）

ロックなしで有効化されている場合は、レジストリのLsaCfgFlagsを0にすることで無効化できます（削除ではなく0）。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa]
"LsaCfgFlags"=dword:00000000

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\DeviceGuard]
"LsaCfgFlags"=dword:00000000

UEFIロックを有効にした場合の注意

Enabled with UEFI lockで運用すると、無効化には原則として物理端末での操作（起動時の確認）が必要になります。500台規模でこれをやると、現場が詰みやすいので、互換性が十分に読めるまでは“ロックなし”で運用するのが安全です。

参考までに、UEFIロックを解除する手順では、EFI領域にSecConfig.efiを配置し、bcdeditでDISABLE-LSA-ISOを指定して再起動し、起動前の確認プロンプトを物理操作で承認する必要があります。手順を間違えると復旧が大変になりやすいため、全社展開前に必ずテスト機で試してください。

実務で効く小ワザ：例外を増やさないための管理方法

「例外端末＝期限付き」にする（例：90日以内に根本対策を決める）
例外はグループで束ねる（Intune/ADで例外用グループを用意し、台帳と一致させる）
例外の再有効化を自動化（アップグレード完了後に“再有効化ポリシー”へ自動で戻す）
MSCHAPv2撤去を移行完了条件に入れる（残ると次回アップデートで再燃しやすい）
TPMクリアは最終手段（VBS機能が使う保護データが失われる可能性があるため、サポート手順に注意書きを入れる）

まとめ：Credential Guardは切るより、依存関係を直す方が結局ラク

Windows 10→11の大量移行では、Credential Guardは原則有効のまま進めるのが安全
困る原因の多くは、MSCHAPv2や古い委任など古い認証設計にある
500台規模では「全台無効化」より、パイロット＋リング展開＋例外運用が現実解
UEFIロックは“戻せなくなる”コストが大きいので、互換性が読めるまでは避ける

移行の目的が「最新OSに上げること」で終わると、次のアップデートで同じ悩みが再発します。Credential Guardを前提に、Wi-Fi/VPN/アプリ認証を現代化しておくと、Windows 11 23H2/24H2以降も運用が安定し、セキュリティ面でも説明が一気にラクになります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。