Windows Update 後に Windows Hello や 保存された資格情報が利用できなくなる事象

Last Update: feedback 共有

本記事はマイクロソフト社員によって公開されております。

こんにちは。Windows Commercial Support Directory Services チームです。

今回は、Windows Update をインストールした後の OS 再起動後に Windows Hello によるサインインができなくなるという事象について紹介します。

発生する事象について

Windows Update をインストール後、OS を再起動した後から、「問題が発生したため、PIN を使用できません。クリックして暗証番号 (PIN) をもう一度設定してください。」と表示され、Microsoft アカウントが Windows Hello (PIN や 生体認証) によるサインインができなくなる事象が報告されています。本事象が発生すると、最悪の場合は Microsoft アカウントによるサインインができなくなり、OS の再インストールが必要となる場合がございます。

OS の再インストールが必要となる条件については、OS の再インストールが必要となるケース にてご説明いたします。

発生原因

今回の問題は、Windows Update 時に、Secure Boot DBX のアップデートと BIOS/UEFI Firmware のアップデートが同時に行われた場合に発生する可能性があります。Secure Boot DBX とは、Secure Boot の信頼を取り消された署名や証明書のリスト (Disallowed Signature Database) です。

一方で、Windows 11 の Copilot+ PC などでは、ESS (Enhanced Sign-in Security) と呼ばれる機能が有効化されていますが、この ESS が有効となっている環境では、Windows Hello に関する情報は、VSM (Virtual Secure Mode) で保護されています。この VSM で保護されている情報を取得する際、TPM 内に存在する特別なレジスター情報 (PCR) を用いて、整合性のチェックを行います。

Secure Boot DBX のアップデートと BIOS/UEFI Firmware のアップデートが同時に行われた場合、複数の PCR 値が同時に更新されてしまうことがあります。その結果、VSM で保護された情報の取り出し時の整合性チェックに失敗し、それに伴い情報の取り出しもできなくなり、本事象が発生します。

なお、Windows Update は既定で自動更新が有効となっているため Secure Boot DBX と BIOS/UEFI Firmware のアップデートが自動的に更新される場合がございますのでご留意ください。

OS の再インストールが必要となるケース

以下の条件を満たす場合、Microsoft アカウントでデバイスにサインインができなくなり、OS の再インストールが必要となる場合がございます。

条件 1) [セキュリティ向上のため、このデバイスでは Microsoft アカウント用に Windows Hello サインインのみを許可する (推奨)] が有効になっている ( 既定で有効 )
本設定が有効になっていることで Windows Hello 以外のサインイン手段 ( パスワード ) が無効になります。これにより、Windows Hello が利用できなくなった場合サインインする手段が失われます。

条件 2) システム ドライブが BitLocker で暗号化 / 保護されており、かつ、BitLocker の回復パスワードを保管していない
サインインできない状況から回復するためには、Windows RE (Windows 回復環境) や OS インストール メディアを用いて起動を行い、条件1) [セキュリティ向上のため、このデバイスでは Microsoft アカウント用に Windows Hello サインインのみを許可する (推奨)] を無効化する必要がありますが、BitLocker の保護が有効な環境の場合、BitLocker の回復パスワードが必要になります。BitLocker の回復パスワードが分からない場合、復旧が困難となり、OS の再インストールが必要となります。

なお、Bitlocker は特定の環境下で自動で有効化される場合がございます。対象端末が自動有効化の条件に合致しているかを確認する方法、および具体的な条件については、Bitlocker が自動で有効化されるケース にてご説明いたします。

OS 再インストールの予防策

Windows 11 Home, Pro Edition では、Microsoft アカウントを用いて初期セットアップを行うと、初期セットアップ中に Windows Hello の登録を求められます。また、Windows Hello を登録した場合、既定で [設定] アプリ - [アカウント] - [サインイン オプション] 内にある [セキュリティ向上のため、このデバイスでは Microsoft アカウント用に Windows Hello サインインのみを許可する (推奨)] が有効化されます。この設定が有効化されている場合、Windows Hello を用いてのみ対象端末にサインイン可能となり、パスワードでのサインインは使用できなくなります。

[セキュリティ向上のため、このデバイスでは Microsoft アカウント用に Windows Hello サインインのみを許可する (推奨)] を無効にしていただくことでパスワードでサインインが可能となり、一切サインインが出来なくなるというシナリオを予防することができます。また、本事象が発生してしまった後に、引き続き Windows Hello を利用する場合は、Windows Hello の再設定をお願いいたします。 [設定] アプリ - [アカウント] - [サインイン オプション] 内から PIN や生体情報の登録が可能となります。

残念ながら、現状 Windows OS として Secure Boot DBX と BIOS/UEFI Firmware の更新が確実に同時に行われないようにする実装はありません。マイクロソフトではこのようなシナリオにも対応できるよう、サポート チームから開発部門へのフィードバックは実施しているため、今後改善される可能性はあります。

しかしながら、現時点では Windows Update による自動更新が有効になっている (既定で有効) 場合、Secure Boot DBX と BIOS/UEFI Firmware のアップデートが自動的に更新される可能性があるため、前述の予防策は必須となります。

サインインできなくなった場合の対処策

Microsoft アカウントでのサインインができなくなった場合、この状況から回復するためには、Windows RE (Windows 回復環境) や OS インストール メディアを用いて起動を行い、**[セキュリティ向上のため、このデバイスでは Microsoft アカウント用に Windows Hello サインインのみを許可する (推奨)]** を以下のレジストリから無効化する必要があります。
(対象 Microsoft アカウント以外にサインインできる管理者ユーザーがいる場合は、管理者ユーザーでサインインして [レジストリ エディター] より以下のレジストリを書き換えてください。)

キー: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device
値の名前: DevicepasswordLessBuildVersion
値の種類: REG_DWORD
値のデータ: 0 ([セキュリティ向上のため、このデバイスでは Microsoft アカウント用に Windows Hello サインインのみを許可する (推奨)] を無効化します)
※ 有効時は 2 になります。

なお、BitLocker が有効化されている場合、先述の Windows RE や OS インストール メディアなどを用いてのレジストリ編集時に、BitLocker 回復パスワードの入力が求められます。この時に BitLocker 回復パスワードが確認できない場合、復旧が困難となることが想定されるため、万が一に備えて通常時から BitLocker 回復パスワードが参照できる状況を確保しておいてください。( 回復パスワードが不明な場合、OS の再インストールが必要となります )

BitLocker 回復パスワードは、Microsoft account | BitLocker 回復キー に対象の Microsoft アカウントを用いてサインインすることで確認できます。また、OS が起動している状態であれば、以下のコマンドを用いて、新たに BitLocker 回復パスワードを追加することもできます。(追加した/表示された回復パスワード (数字パスワード) 情報は、安全な場所に保管してください。)

1
2
3
4
5
6
7
8
// BitLocker が有効化どうかを確認するコマンド ("保護の状態" が "保護はオンです" となっているか確認します。)
manage-bde -status C:

// 追加コマンド
manage-bde -protectors -add C: -RecoveryPassword

// 確認コマンド
manage-bde -protectors -get C:

※ 管理者権限が必要です

参考情報
OEM 向け Windows 11 での BitLocker ドライブ暗号化
BitLocker 回復の概要
BitLocker 回復プロセス

Bitlocker が自動で有効化されるケース

Bitlocker は特定の環境下で自動で有効化される場合がございます。具体的な条件 および お使いのデバイスが自動有効化の条件に合致しているかを確認する方法は以下の通りとなります。

Bitlocker が自動で有効化される条件

  1. Windows 10 以降、エディションは Home 以上。 (※1)
  2. 新規インストール時 ( なお、既存の OS に対し、 [リセット] 機能 (選択肢: “すべて削除する”) を使用し初期化した場合を含みます。)
  3. Bitlocker の自動暗号化要件
    ・ デバイスに TPM 1.2 もしくは TPM 2.0 が搭載されていること
    ・ UEFI Secure Boot が有効であること
    ・ Platform Secure Boot が有効であること
    ・ モダンスタンバイ もしくは HSTI に準拠していること ( ただし、Windows 11 24H2 以降では IoT Enterprise Edition を除いて要件より削除 )
    ・ 許可されていないダイレクト メモリ アクセス (DMA) インターフェイス が存在しないこと ( ただし、Windows 11 24H2 以降では IoT Enterprise Edition を除いて要件より削除 )

かつ、以下の条件を満たし BitLocker による保護が開始されている状態。 (※2)
4. Microsoft アカウントによる OS ログオン もしくは Entra ID 参加

※1 [BitLocker] は Pro エディション以上で利用可能な機能ですが、 Home エディションにおいても [デバイスの暗号化] 機能として OS ドライブの自動暗号化が行われます。 そのため、 Microsoft アカウントによるログオンに切り替えられ、保護が開始されると WinRE や OS インストール メディアから OS ディスクにアクセスする際には回復キーによるロック解除が必要となります。
※2 [BitLocker] には暗号化と保護の 2 フェーズがございます。暗号化の段階では回復キーは作成されておらず、 OS ドライブは保護されていないため、 WinRE や OS のインストール メディアから回復キー不要でアクセスすることが可能です。

条件に合致したデバイスであるかを確認する方法

1
2
3
4
5
6
1. コマンド プロンプトまたは Powershell を [管理者として実行] で起動します。
2. 以下のコマンドを実行します。
msinfo32

3. [システムの要約] - [自動デバイスの暗号化サポート] が "前提条件を満たしています" になっている場合、
そのデバイスは自動暗号化の条件を満たしていると判断できます。

その他の関連事例

Windows Hello 以外の関連事例についてご紹介いたします。

資格情報マネージャーに保存した資格情報が削除され、タスクスケジューラーが実行されなくなった

Credential Guard が有効な環境において、タスク スケジューラ タスクにて、[ユーザーがログオンしているかどうかにかかわらず実行する] にチェックを入れているタスクが実行できなくなる事象が報告されております。この時、Microsoft-Windows-TaskScheduler/Operatinoal イベント ログを確認すると、以下のログオン失敗のイベント ログが記録されていることが確認できます。

ログの名前: Microsoft-Windows-TaskScheduler/Operational
ソース: Microsoft-Windows-TaskScheduler
日付: yyyy/MM/dd HH:mm:ss
イベント ID: 104
タスクのカテゴリ: ログオン失敗
レベル: エラー
説明:
タスク スケジューラは、”<YOUR_TASK_NAME>” にログオンできませんでした。”LogonUserExEx” でエラーが発生しました。
ユーザー操作: タスクの資格情報が正確に指定されていることを確認します。
追加データ: エラー値: 2147943726。

タスク スケジューラ タスクの実行アカウントの資格情報については、SYSTEM アカウントの資格情報マネージャー内に保存されます。Credential Guard が有効な環境では、資格情報マネージャーに保存された資格情報が VSM (Virtual Secure Mode) で保護されています。そのため、発生原因 に記載の問題が発生すると VSM で保護された情報が取り出せなくなり、実行アカウントの資格情報を利用することができなくなります。これに伴ってタスク実行のためのユーザー ログオンに失敗し、その結果タスクの実行に失敗します。

この事象が発生した場合は、改めて対象タスクを保存し直し、実行アカウントの資格情報を再入力する必要があります。

更新履歴

2025/10/07 : 本ブログの公開
2025/10/10 : 一部文言の修正およびシナリオを追加
2025/11/13 : 章立て および 内容を全体的に修正