企業向けパスキー展開の課題と解決策

1. はじめに：企業における従業員向けパスキーの運用上の現実#

パスキーは職場に導入されつつあります。問題はもはや「この技術は機能するか？」ではありません。現在の問題は「これをどうやって大規模に運用するか？」です。摩擦のポイントは運用レイヤーに移っています。初期登録の「鶏と卵」の問題（ブートストラップ）、デバイスバウンド型と同期型パスキーの違い、クロスプラットフォームの相互運用性、そしてパスワードの持つ脆弱性に逆戻りしないリカバリーメカニズムなどです。

本ガイドでは、Microsoft Entra ID環境におけるパスキー展開の現実的な課題を取り上げ、構成の落とし穴、運用ワークフロー、リカバリー戦略について解説します。具体的には、以下の疑問にお答えします。

1. Entra IDにおけるデバイスバウンド型と同期型パスキーの違いは何ですか？
2. 新しい従業員に対してパスワードなしでパスキーをブートストラップするにはどうすればよいですか？
3. ユーザーが新しいスマートフォンに変更して認証器へのアクセスを失った場合、どうやってリカバリーしますか？
4. どのような構成ミスがパスキーの登録失敗を引き起こしますか？
5. フィッシング耐性のあるMFAを要求する場合、B2Bゲストにはどう対応すればよいですか？
6. ハードウェアセキュリティキー (YubiKey) とモバイルパスキーのどちらを使用すべきですか？
7. パスキー展開において、Windowsと一緒にmacOSデバイスをどう扱えばよいですか？
8. スマートフォン交換によるヘルプデスクの過負荷を防ぐための事前の対策は何ですか？

2. Microsoft Entraにおけるパスキーの理解#

Entraにおいて、「パスキー」= FIDO2/WebAuthn認証情報を意味します。パスワードの代わりに、ユーザーは認証器に保存された秘密鍵を所有していることを証明します。WebAuthnは認証情報を実際のサインインオリジンにバインドするため（類似のフィッシングサイトではリプレイできないため）、フィッシング耐性があります。Microsoftによる概要は、パスキー (FIDO2) の概念に関するドキュメントを参照してください。

Entraは実質的に、異なる動作をする2つの「モード」のパスキーをサポートしています。

2.1 Entraにおけるデバイスバウンド型パスキー#

これらのパスキーは1つの物理デバイスに紐付いており（同期不可）、秘密鍵は特定のハードウェア要素（ノートPCのTPMや、YubiKeyのセキュアエレメントなど）に存在します。エクスポートはできません。

Entraにおいて、デバイスバウンド型のシナリオは一般的に以下のように解釈されます。

• Microsoft Authenticator パスキー
• Windows Hello または Windows Hello for Business (WHfB) パスキー（2026年1月時点では非同期）
• FIDO2セキュリティキー (YubiKeyなどのハードウェアキー)
• スマートカード

デバイスバウンド型パスキーに関するMicrosoftのベースライン設定ガイダンスは、以下で確認できます。 https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

ユースケース: 高特権アクセス、「ブレークグラス」アカウント、共有ワークステーション環境。欠点: 摩擦が大きい。デバイスの紛失は認証情報の紛失を意味する。高い運用コスト（例：YubiKeyの発送など）。

2.2 Entraにおける同期型パスキー#

これらはプロバイダーのエコシステム内に保存され、ユーザーのデバイス間で同期されるパスキーです（例：iCloudキーチェーン、Googleパスワードマネージャー、またはサードパーティのプロバイダー）。秘密鍵は暗号化され、クラウドプロバイダーの同期ファブリックに保存されます。

2026年1月現在、Entraにおいて、同期型パスキーはプレビュー機能を通じて処理されます： 同期型パスキー (プレビュー)。 同期型パスキーを有効にして制御するために、Entraはパスキープロファイル (プレビュー)を使用します。

規制への適合: 最近、NIST SP 800-63B Supplement 1により、AAL2要件を満たすことが検証されました。これは、同期型パスキーが一般的な従業員が使用するのに十分な「フィッシング耐性」を持つことを検証する、規制面での大きな勝利です。

ユースケース: ナレッジワーカー、BYODユーザー、役員の利便性。欠点: ハードウェアより「低い」保証レベル。クラウドプロバイダーのアカウントリカバリーフローのセキュリティに依存。

以下は、Entraがサポートする同期型パスキープロバイダーの概要です。

ユーザーのセキュリティ情報ページでは、同期型パスキーとデバイスバウンド型パスキーが明確に区別されます。以下は、同期型パスキー（1Passwordから）とデバイスバウンド型パスキー（YubiKey 5C NFC）がどのように表示されるかの例です。

2.3 規制への適合：NISTのAALレベル#

• AAL3は歴史的に、エクスポート不可能な秘密鍵を利用するハードウェアベースのデバイスバウンド認証器（YubiKeyやスマートカードなど）を要求していました。
• AAL2は現在、NISTのガイダンスに従い、同期型パスキーで達成可能になりました。
• ニュアンス: 同期型パスキー（iCloudなどのもの）は標準的なユーザーには優れていますが、最高権限レベルのAAL3における「エクスポート不可」要件を厳密には満たさない場合があります。したがって、セグメント化された戦略が必要です：管理者向けにはハードウェアキー (AAL3)、従業員向けには同期型パスキー (AAL2) です。

2.4 デバイスの準備要件#

デバイスがフィッシング耐性のあるパスワードレス認証の準備ができていることを確実にするには、以下の最小バージョンを実行している必要があります。

古いオペレーティングシステムでは、フィッシング耐性のあるパスワードレス認証をサポートするために外部認証器（FIDO2セキュリティキー）が必要になる場合があります。

最小バージョンの要件に加えて、ブラウザ側の機能サポートもプラットフォームによって異なります。Corbado パスキーベンチマーク 2026 WebAuthn クライアント機能分析によれば、2026年第1四半期の一般的なコンシューマーブラウザ構成では、Conditional GetとHybrid Transportのブラウザサポートは97〜100%ですが、Conditional Createはわずか83〜92%にとどまります。Windows HelloはConditional Createのパスではなく、特にEdgeは同じデータセットにおいてConditional Createのサポートが非常に低いと報告されているため、この制約はWindowsに最も重くのしかかります。このベンチマークは従業員環境ではなく、コンシューマー向けのB2C展開を対象としていますが、基礎となるブラウザやOSの機能的な上限はEntra IDの展開にも同様に適用されます。エンタープライズでEdgeを多用する環境では、Conditional Createの混合レンジである83〜92%を大幅に下回る可能性があります。

2.5 ユーザーペルソナ別の認証情報の推奨事項#

Microsoftは、認証情報の展開においてユーザーペルソナに基づくアプローチを推奨しています。役割によって、セキュリティ要件や許容される摩擦レベルが異なります。

ポータブル認証情報 (デバイス間で利用可能):

ローカル認証情報 (デバイス固有):

最終的な目標: ほとんどのユーザーは、各コンピューティングデバイスにポータブルな認証情報を少なくとも1つと、ローカルな認証情報を持つべきです。

3. 実際のパスキー展開からの経験#

パスキーを展開した組織と話すと、現実世界でのいくつかの摩擦のポイントやパターンが認識されています。

3.1 運用上のシフト#

「課題は技術スタックではなく、運用レイヤーにある。」 これにより、「パスキーが登録されていません」というエラーや、個人のデバイスでWindows Helloのオプションが表示されないといった技術的なハードルは、特有の異常ではなく、エコシステムの現在の成熟度に内在するシステム的な摩擦ポイントであることが確認されます。企業の運用において重要なのは、監視において予期される失敗と予期されない失敗を切り離すことです。WebAuthnエラーを明示的にバケツに分類し、NotAllowedError、AbortError、Credential Managerのパスキーエラーを個別のシグナルとして追跡します。当社の認証分析プレイブックはこれらのシグナルを分類するためのフレームワークを提供しており、パスキー分析はアクティベーション率やログイン率などのパスキー固有のKPIをカバーしています。

3.2 登録：「成否を分ける」瞬間#

登録は展開において最も困難なフェーズであり、大幅な変更管理が求められます。

• 事前登録の複雑さ: 以前の認証情報を持たない新しい従業員のオンボーディングが主要なボトルネックとなります。管理者が仲介する登録への依存は、一貫性のないユーザーエクスペリエンスを生み出します。
• プラットフォームの断片化: ブラウザ、オペレーティングシステム、パスワードマネージャーの独立した反復に伴う「ステップによるユーザーのフラストレーション」。これにより、Chrome/Windowsでは機能するフローがSafari/macOSでは失敗したり、個人の管理外デバイスでは失敗する一方で会社のデバイスでは成功したりする、一時的な不整合が発生します。

3.3 メンタルモデルのギャップ#

「ユーザーに必要なのは暗号技術ではなく、メンタルモデルである」。用語の混乱により認知負荷が生じます：

• パスキー (Passkey)
• セキュリティキー (Security Key)
• ハードウェアキー (Hardware Key)
• YubiKey
• パスワードレス (passwordless)
• Windows セキュリティ (Windows Security)
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• 電話でのサインイン (Phone Sign-in)

テクノロジーに詳しくないユーザーだけでなく、詳しいユーザーにとっても、これらの用語の違いは直感的にわかりません。

エンドユーザー向けのコミュニケーションにおいて、「フィッシング耐性」や「キーペア」といった専門用語は避けることをお勧めします。代わりに、「顔を使って企業のシステムをロック解除する」など、スマートフォンのロック解除に例えた「ロック解除」の概念に焦点を当ててください。

3.4 コミュニケーションの限界#

初期段階での強力な導入が成功には不可欠ですが、コミュニケーションの力には限界があります。ユーザーに認証方法を確認するよう定期的にメールを送ることはできません。一般的に、ユーザーの行動をうまく計画することはできません。 この現実があるため、ユーザー教育のみに頼るのではなく、事前の技術的対策が必要となります。

4. Microsoft Entra IDの構成の深掘り#

企業環境でパスキーを展開するには、相互に依存するポリシーを理解し設定する必要があります。パスキーは単にオンにできる機能ではなく、すべての従業員の日々の業務に大きな影響を与えます。

4.1 認証方法ポリシー#

従来のMFAやSSPRポータルは非推奨となっています。すべてのFIDO2の構成は、統合された認証方法ポリシーブレードで行う必要があります。

• FIDO2セキュリティキーの方法: これは有効にして対象を指定する必要があります。有効化の対象は「すべてのユーザー」とすることを推奨しますが、条件付きアクセスを介して強制を制御します。
• キーの制限 (AAGUID): すべてのFIDO2デバイス (例: YubiKey 5 NFC、iOS上のMicrosoft Authenticator、Googleパスワードマネージャー) には、一意のAuthenticator Attestation GUID (AAGUID)があります。ベストプラクティスとして、セキュリティの高い環境では、「キーの制限を実施」設定を利用して、承認された特定のAAGUIDのみを許可します。これにより、ユーザーが安価で未検証の「グレーマーケット」のセキュリティキーを登録するのを防ぎます。

4.2 構成証明 (Attestation): 重要な決定ポイント#

最も重要な構成の決定の1つは**「構成証明の実施 (Enforce Attestation)」**です。

• 役割: 登録時に、認証器がそのメーカーとモデルを暗号化によってEntra IDに証明することを強制します。
• 競合: 同期型パスキー (iCloudキーチェーン、Bitwarden、Googleパスワードマネージャーなどのソフトウェアプロバイダーに保存されるもの) は、ソフトウェアベースでプラットフォームに依存しないため、通常は構成証明をサポートしていません。これらはハードウェアバッチ証明書でチャレンジに署名することができません。
• トレードオフ:
  • 「はい」に設定: 高い保証 (AAL3) に必要。キーがハードウェアバウンドであることを保証します。ソフトウェアベースのパスキープロバイダーをブロックします。
  • 「いいえ」に設定: 同期型パスキーを許可します。保証レベルはわずかに低下します (AAL2)。ソフトウェアベースのパスキープロバイダーを有効にします。

ハードウェアキーを必要とする高特権の管理者がいる場合、全体的な「構成証明なし」のポリシーを適用することはできません。パスキープロファイル (プレビュー)を使用する必要があります：

• プロファイル A (管理者): 構成証明の実施 = はい
• プロファイル B (一般スタッフ): 構成証明の実施 = いいえ

4.3 パスキープロファイルの解説#

パスキープロファイルは、以下を定義するためのメカニズムと考えてください：

• 「これらのユーザーは同期型パスキーを使用できる」
• 「これらのユーザーはデバイスバウンド型のみを使用しなければならない」
• 「構成証明が必須か、不要か」（それに伴う、同期型パスキーの許可か除外か）
• 「特定の認証器の種類に制限する (AAGUID制限)」

以下は、Microsoft Entra管理センターのパスキー (FIDO2) 設定ページで、パスキープロファイルを構成する画面です：

パスキープロファイルを編集する際、構成証明の実施、ターゲットタイプ (デバイスバウンド型、同期型、またはその両方)、および特定のAAGUIDの制限を構成できます。

4.4 条件付きアクセスと認証強度#

強制は、認証強度 (Authentication Strengths)を利用した条件付きアクセス (CA) ポリシーを通じて処理できます。

• フィッシング耐性のあるMFA強度: この組み込みの強度は、FIDO2、Windows Hello for Business (WHfB)、または証明書ベースの認証 (CBA) を要求します。
• ロックアウトの罠: 「すべてのクラウドアプリ」に対して「フィッシング耐性のあるMFA」を要求するCAポリシーを作成し、「すべてのユーザー」に適用すると、まだパスキーを登録していないすべてのユーザーが直ちにロックアウトされます。ユーザーはログインして登録することさえできなくなります。
• 「セキュリティ情報の登録」のパラドックス: これはCAにおける特定のユーザーアクションです。アクションセキュリティ情報の登録を実行するためにフィッシング耐性のあるMFAを要求すると、循環的な依存関係 (鶏と卵) が生じます。ユーザーは登録ページにアクセスするためにパスキーが必要となるため、最初のパスキーを登録できなくなります。

以下は、どの認証方法がどの強度要件を満たすかの概要です：

4.5 システム優先の認証#

Entra IDの「システム優先の多要素認証」機能は、サインインエンジンに最も安全な登録済み方法をユーザーに促すように強制します。

ユーザーがSMSとパスキーの両方を登録している場合、システムはデフォルトでパスキーを使用します。これにより、厳格な強制なしに、パスキーの導入が有機的に推進されます。ユーザーが認証情報を登録すると、自動的にセキュリティ態勢を「アップグレード」するようなものです。

以下は、パスキーのサインインエクスペリエンスの例です。ユーザーは「顔、指紋、PIN、またはセキュリティキー」の使用を促され、ブラウザ拡張機能やシステムのクレデンシャルマネージャーからパスキーを選択できます。

4.6 macOSに関する考慮事項：プラットフォームSSO#

WindowsとmacOSが混在する環境を持つ組織向けに、macOS プラットフォームSSOはWindows Hello for BusinessのApple相当の機能を提供します。MDMソリューションと組み合わせることで、以下を実現できます。

• MacのSecure Enclaveに紐付いたデバイスバウンド認証情報
• ネイティブアプリとWebアプリ間でのSSOエクスペリエンス
• AAL2/AAL3要件を満たすフィッシング耐性のある認証

注意: macOS プラットフォームSSOには、macOS 13以上と適切なMDM構成が必要です。設定はWindows WHfBとは大きく異なるため、個別の展開計画を立ててください。

5. よくある構成ミス：なぜ「Microsoft Authenticatorでしか機能しない」のか#

目標が管理外のデバイスでの同期型パスキーである場合、最も一般的な障害となるのは以下の点です。

5.1 同期型パスキーが有効化/ターゲットにされていない#

Entraで単に全体的に「FIDO2」を有効にするだけでは十分ではありません。同期型パスキーを使用するには通常、以下の設定が必要です。

• 同期型パスキー (プレビュー)で説明されているプレビュー機能のパス。
• パスキープロファイルを使用したプロファイル構成。

同期型パスキーを許可するプロファイルによってグループがターゲットにされていない場合、「デバイスバウンド型のみ」の世界に引き戻されてしまいます。

5.2 構成証明の強制 (同期型パスキーをブロック)#

これが、セキュリティ意識の高い組織で最も多くの疑問を引き起こします。

• Entraは、一部のパスキーシナリオに対して構成証明を要求できます (認証器のタイプ/出所の検証に役立ちます)。
• Entraでは同期型パスキーは構成証明をサポートしていないため、構成証明が強制されると、同期型パスキーの登録は失敗し、結果的にデバイスバウンドのオプションのみが残ります。

5.3 AAGUIDの許可リストがプロバイダーをブロックしている#

Entraでは、許可される認証器を制限できます (多くの場合、AAGUIDの許可/ブロックリストを介して)。Microsoft Authenticator (または狭い範囲の認証器) のみを許可リストに入れると、サードパーティの同期型プロバイダーは暗黙的にブロックされる可能性があります。混乱を招くのは、ローカルの認証 (Touch ID、Face ID、Windowsの生体認証スキャンなど) は機能するのに、Entraのログインページでエラーが表示されることです。

5.4 条件付きアクセスが特定のパスキーの種類を強制している#

パスキーが有効になっていても、条件付きアクセスが実質的にユーザーを認証方法のサブセットに強制する可能性があります (例：「Authenticatorのみ」、または意図したパスキープロファイルを許可しない強度構成など)。実際には、これが同期型パスキーを計画しているにもかかわらず、「Authenticatorへの依存」を生み出します。

5.5 B2Bゲストとメンバーアカウント#

外部パートナーがリソーステナントのB2Bゲストユーザーである場合、どこでどのように認証方法を登録できるかについて既知の制限があります。これは、「パートナーにテナントでパスキーを使わせたい」という意図があるのに「なぜ機能しないのか」という、隠れた原因になることがよくあります。

6. 運用上の課題と解決策#

6.1 ブートストラップのパラドックス#

最も広範な問題 (「登録が最も難しい部分」) はブートストラップ問題です。現在認証情報を持っていない (または低保証の認証情報しか持っていない) ユーザーに対して、高保証の認証情報を安全に発行するにはどうすればよいか？

6.1.1 一時アクセスパス (Temporary Access Pass: TAP)#

一時アクセスパス (TAP)は、パスワードレスのオンボーディングのためのアーキテクチャアプローチです。

• 役割: Entra IDが「強力な認証」方法として扱う、時間制限のある (例: 1時間) 高エントロピーのパスコード。パスワードや既存のMFAをバイパスします。
• ワークフロー:
  1. 身元確認: 新しい従業員の身元が確認されます (人事プロセスやマネージャーによる確認など)。
  2. 発行: 管理者 (または自動化されたLogic App) がユーザー用のTAPを生成します。
  3. 「マジック」ログイン: ユーザーは aka.ms/mysecurityinfo に移動します。ユーザー名とTAPを入力します。
  4. 登録: TAPは「強力な認証」の要件を満たすため、ユーザーはセキュリティ情報ブレードへのアクセスが許可されます。「方法の追加」をクリックし、パスキーを登録します。
  5. 定常状態: TAPの有効期限が切れます。ユーザーはフィッシング耐性のある認証情報を手に入れました。パスワードを入力したことは一度もありません。

6.1.2 Graph APIを介した自動化#

大規模な組織では、TAPの手動発行は拡張性がありません。ベストプラクティスは、Microsoft Graph APIを介した自動化です。

• シナリオ: 新入社員が人事システム (Workday/SuccessFactors) で処理されます。
• トリガー: プロビジョニングイベントがAzure Logic Appをトリガーします。
• アクション: Logic AppがGraph API POST /users/{id}/authentication/temporaryAccessPassMethods を呼び出します。
• 配信: 初日からのアクセスのために、TAPがユーザーの採用マネージャーや個人のメールアドレス (暗号化済み) に安全に配信されます。

6.1.3 高保証のオンボーディングのためのMicrosoft Entra 検証済みID (Verified ID)#

リモートでのオンボーディングや、高い身元保証が求められるシナリオでは、MicrosoftのFace Checkを伴うEntra 検証済みIDがパスワードレスファーストの登録パスを提供します。

1. 身元確認 (Identity proofing): 新規ユーザーはIDVパートナーを介して身元を証明します (政府発行のIDスキャンなど)。
2. 生体認証の照合: Face Checkは、Azure AI Visionを使用して、リアルタイムの自撮り写真とIDドキュメントの写真を比較します。一致の信頼度スコアのみが共有されます (生の生体データは共有されません)。
3. 検証済み認証情報の発行: ユーザーは検証済みID認証情報を受け取ります。
4. TAPの発行: 検証が成功すると、システムは一時アクセスパスを発行します。
5. パスキーのブートストラップ: ユーザーはTAPを使用して最初のパスキーを登録します。

Face Checkのフローは、ユーザーに「確認 (認証情報を共有)」、「確認 (顔スキャンを実行)」、「レビュー (一致結果を確認)」の3つのステップを案内します：

このフローにより、初日から真のパスワードレスアカウントが可能になります。パスワードは一切作成されません。

6.2 スマートフォン交換の問題 (隠れたスケーラビリティの課題)#

これは多くの場合、パスキー展開におけるヘルプデスクへの問い合わせの最大の原因となります。多数のBYODデバイスを抱える組織 (例: 10,000台以上のデバイス) では、ユーザーが新しいスマートフォンに変更し、認証方法の再登録手順がわからないという理由だけで、膨大な数のサポートコールが発生する可能性があります。

パスキーを導入すると、この問題はさらに深刻になります。理由は以下の通りです。

• ユーザーが新しいスマートフォンにアプリ (Outlookなど) をインストールする
• これらのアプリが認証を求める
• MFAのプロンプトが古いスマートフォン (すでに下取りに出したか初期化済みの可能性がある) に表示される
• ユーザーはロックアウトされ、ヘルプデスクに電話する

6.2.1 スマートフォン交換のシナリオマトリックス#

目標は、可能な限り多くのケースを最初の2つの行に移行させ、ヘルプデスクの介入を最小限に抑えることです。

6.2.2 Intuneの登録トリック#

巧妙な洞察: Intuneの登録にパスキーを必須にすると、ユーザーは企業アプリにアクセスする前に、新しいスマートフォンですぐにMicrosoft Authenticatorのセットアップを完了せざるを得なくなります。

• 現状: Intuneの登録にはMFAステップアップが必要です。つまり、新しいスマートフォンでログインしたい場合、そこにOutlookをインストールします。しかし、MFAのプロンプトは古いスマートフォンに送信されます。
• パスキー要件あり: ユーザーは登録を完了するために、まず新しいスマートフォンでMicrosoft Authenticatorのパスキーを設定しなければなりません。これは、数ヶ月後に古いスマートフォンが手元になくなってからではなく、迅速に (機種変更した当日に) 行われます。

これはリカバリーを解決するものではありませんが、タイムラインをシフトさせます。ユーザーは古いデバイスにアクセスできる間に新しいデバイスを登録します。

6.3 ハードウェアセキュリティキーに伴うロジスティクスの問題#

ハードウェアキー (YubiKeyなど) は普遍的なソリューションとして位置付けられることがありますが、現実世界ではより多くの課題が明らかになります。

• ロジスティクスの悪夢: 以前に物理トークン (RSA SecurIDなど) を展開した組織は、多くの場合、それらを排除するために何年も費やしました。ある物理トークンプログラムを別の物理トークンプログラムに置き換えることは魅力的ではありません。
• ドロップシッピング (直送): Yubicoはキーをユーザーに直接発送でき、(SecurIDとは異なり) 数年ごとの電池交換は必要ありません。しかし、ユーザーがキーを忘れると、(共有デスクトップには) サインインできません。
• ローカルITの負担: 現場のスーパーバイザーが、忘れられたキーの事実上のITサポートになるべきではありません。
• コスト: ハードウェアキーは、従業員数に比例してユーザーあたりのコストを増加させます。

ハードウェアキーが理にかなう場合:

• Tier 0 管理者: ドメイン管理者、「ブレークグラス」アカウント
• 共有ワークステーション: キオスク環境、工場のフロア、現場のタブレット
• BYODを利用しない契約社員: 個人のデバイスを使用しない外部ユーザー

6.4 管理外デバイスの課題#

多くのユーザーから、個人のデバイスでパスキーの使用オプションが表示されないという苦情が寄せられます。これは「管理外デバイス」に関する典型的な摩擦のポイントです。

6.4.1 「パスキーが登録されていません」エラーの分析#

ユーザーは個人のデバイスでパスキーを追加できない一方で、会社のデバイスでは追加できる場合があります。これはおそらく、Intuneのコンプライアンスポリシーが登録フローと相互作用しているためです。

• メカニズム: Windows Hello for Business (WHfB) はプラットフォーム認証情報です。これは特定のデバイスのTPMにバインドされます (デバイスバウンド型パスキー)。
• 制約: WHfBを登録するには、デバイスが通常テナントに参加 (Entra参加またはハイブリッド参加) している必要があります。単に「登録済み (Registered)」(ワークプレイス参加) である個人のデバイスは、デバイスが完全に管理されているかコンプライアンスを満たしていない場合、WHfBコンテナのプロビジョニングをブロックするポリシー制限がIntuneを介して適用されている可能性があります。FIDO2セキュリティキーのサインイン要件を参照してください。
• 「パスキー」オプション: 個人のデバイスでは、ユーザーはWindows Hello for Businessではなく (BYODの登録が完全にサポートされていない限り)、FIDO2セキュリティキー (ローミング) またはクロスデバイスパスキー (スマートフォン上) を登録しようとするべきです。
• Entra IDの表示の問題: 「Windows Hello」がオプションとして表示されない場合、デバイスは前提条件となるMDM登録を完了していません。

6.4.2 クロスデバイス認証 (CDA) の失敗#

管理外のデバイスでは、ユーザーは頻繁にクロスデバイス認証 (CDA) フロー (スマートフォンでPC上のQRコードをスキャンする) を試みます。

• Bluetoothへの依存: CDAには、PCとスマートフォンの両方でBluetoothが有効になっている必要があります。ペアリングする必要はありませんが、近接性を証明するためにBluetooth Low Energy (BLE) ハンドシェイクを実行する必要があります。詳細はMicrosoft Authenticatorのデバイスバウンド型パスキーを確認してください。
• 企業ポリシーによるブロック: 企業のノートPCで、「セキュリティ」を理由にBIOSやGPOを介してBluetoothが無効にされている場合、ローミングパスキーの主要なメカニズムがすでに壊れていることになります。
• Websocketのブロック: CDAフローは cable.ua5v.com または cable.auth.com へのWebSocket接続を使用します。攻撃的な企業のファイアウォールやZscalerの構成では、これらのドメインがブロックされることが多く、QRコードのスキャンがハングアップしたり、警告なしに失敗したりする原因となります。Microsoft Authenticatorのパスキーに関するドキュメントを参照してください。

6.5 B2Bと外部ID#

企業にとってのもう一つの悩みの種は、外部コンサルタント (B2Bゲスト) への対応です。

• 問題: コンサルタントがSharePointサイトにアクセスしようとします。テナントは「フィッシング耐性のあるMFA」を要求する条件付きアクセスポリシーを実施しています。
• 失敗: コンサルタントはリソーステナントにFIDO2キーを登録しようとします。これは失敗します。 Entra IDは、ゲストユーザーがリソーステナントにFIDO2キーを登録することをサポートしていません。
• 修正策: クロステナントアクセス設定
  • ロジック: ゲストにテナントで認証情報を登録させるのではなく、_ゲストの_テナントで使用している認証情報を信頼するべきです。
  • 構成: [外部ID] > [クロステナントアクセス設定] に移動します。パートナー組織を選択します。受信の信頼で、**「Microsoft Entraテナントからの多要素認証を信頼する」**にチェックを入れます。
  • 結果: コンサルタントがホームテナントのYubiKeyを使用してログインすると、テナントは「MFA完了 ＋ フィッシング耐性あり」というクレームを受け取ります。ユーザーが何も登録することなくアクセスが許可されます。これにより、認証情報のライフサイクル管理をパートナーに外部委託し、自社の責任とヘルプデスクの負担を軽減できます。

7. リカバリー戦略#

多くの場合、リカバリーの決定は実際の展開に遅れをとっています。組織のニーズに応じて、複数のリカバリーオプションが存在します。

7.1 検証済みIDを使用したセルフサービスアカウントリカバリー (SSAR)#

Microsoft Entra IDの新しいセルフサービスアカウントリカバリー (SSAR)フロー (プレビュー) は、ヘルプデスクの介入なしに高保証のリカバリーを可能にします。

1. トリガー: ユーザーがサインインできない。「アカウントを復元する」を選択します。
2. 身元確認: ユーザーはサードパーティの身元確認 (IDV) プロバイダー (OnfidoやIDemiaなど) にリダイレクトされます。
3. ドキュメントのチェック: ユーザーはモバイルカメラを使用して、物理的な運転免許証、国民ID、またはパスポートをスキャンします。
4. 生存確認 (Liveness Check): ユーザーは自撮りのFace Checkを実行します。これはIDドキュメント (および場合によってはEntra IDに保存されている写真) と照合されます。照合にはAzure AI Vision Face APIが使用され、信頼度スコアのみが共有されます。生の生体データがアプリケーションに渡ることはありません。
5. 復元: 成功すると、システムは自動的に**一時アクセスパス (TAP)**をユーザーに発行します。
6. 再登録: ユーザーはTAPを使用して、すぐに新しいパスキーを登録します。

推奨事項: この自動化された生体認証を利用したリカバリーパスは、ソーシャルエンジニアリング (ディープフェイク音声攻撃) に対して脆弱な「ヘルプデスクに電話する」よりも優れています。

7.2 マイスタッフを使用したマネージャー支援のリカバリー#

サービスデスクの負荷を軽減したいが、完全なセルフサービスを有効にできない場合、Microsoft Entraには**マイスタッフ (My Staff)**と呼ばれるネイティブの委任管理機能が含まれています。

• 仕組み: 「チームマネージャー」 (Entraの管理単位を使用) に限定的な権限を委任します。
• フロー: ユーザーがアクセスを失った場合、委任されたローカル管理者に連絡し、その管理者はマイスタッフポータルを使用して、パスワードのリセットや電話番号の更新など、サポートされているリカバリータスクを実行できます。
• 役立つ理由: 一般的なアカウントリカバリーの作業を中央のヘルプデスクから移行させ、サポートを迅速化します。

7.3 セルフサービスリカバリーキオスク (イントラネット)#

多くの場合、ユーザーはまだ信頼できるWHfBで保護されたノートPCを持っているため、シンプルな「ブレークグラス (緊急時用)」イントラネットページを構築できます。

• 構築: WHfBのサインイン (強力な認証) を必要とするシンプルな社内Webアプリ。
• アクション: 認証後、ユーザーは「新しいスマートフォンがある」をクリックします。アプリはMicrosoft Graph API (バックグラウンドサービス) を使用して、有効期間の短い一時アクセスパス (TAP) を生成し、画面に表示します。
• 結果: ユーザーはそのTAPを新しいスマートフォンに入力して、Microsoft Authenticatorアプリをブートストラップします。ヘルプデスクの介入はゼロです。

これは、ポリシーを弱めることなく、「認証方法のクリア」のリセットを減らすための重要なレバーとなります。強力な「ノートPCによるブートストラップ」メカニズムがあれば、ユーザーは完璧な手順を知らなくてもリカバリーできるため、コミュニケーションの負担は大幅に軽減されます。

8. パスキー企業導入のための推奨事項#

成熟度ステージを中心とした展開計画を策定します。摩擦 (「技術の準備はできているが、運用が難しい」) を認識し、以下の緩和策を適用してください。

8.1 差し迫ったアクション (「修正」フェーズ)#

1. Bluetoothとファイアウォールの監査: 企業のノートPCでBluetooth (近接性チェック用) が許可されていることを確認し、FIDO/WebAuthnのリレードメイン (\*.cable.auth.com) をホワイトリストに登録してクロスデバイスの失敗を修正します。
2. クロステナントの信頼の有効化: ゲストのパスキーを登録しようとするのをやめます。主要なパートナー向けにMFAの受信の信頼を構成し、B2Bアクセスの問題をすぐに解決します。
3. オンボーディングでのTAPの実装: 「鶏と卵」の登録ブロッカーを解決するため、すべての新規ユーザーのオンボーディングにおいて一時アクセスパスの使用を義務付けます。

8.2 戦略的な決定 (「アーキテクチャ」フェーズ)#

1. 「ハイブリッドアシュアランス」モデルの採用:
   • Tier 0 (管理者): 構成証明とキーの制限を実施します。YubiKey/ハードウェアのみを許可します (AAL3)。
   • Tier 1 (従業員): パスキープロファイルを通じて構成証明の実施を無効にします。摩擦とコストを削減するために同期型パスキーを許可します (AAL2)。
2. macOSの計画: Windows WHfBと並行するトラックとして、MDMと一緒にプラットフォームSSOを展開します。

8.3 将来への備え (「最適化」フェーズ)#

1. SSARの計画: ヘルプデスクをソーシャルエンジニアリングのベクターから排除するため、検証済みIDを使用したセルフサービスアカウントリカバリーのパイロット版を開始します。
2. システム優先の認証: このポリシーを有効にして、ユーザーがパスキーを登録するとすぐに自動的にパスキーに「アップグレード」させ、厳格な義務付けなしに導入を促進します。
3. リカバリーオプションの展開: マイスタッフによるマネージャー支援のTAP、またはセルフサービスリカバリーキオスクを実装します。
4. Intuneパスキー要件: 新しいデバイスでの早期登録を強制するために、Intuneの登録にパスキーを必須にすることを検討します。

8.4 トラブルシューティングマトリックス#

9. 「フィッシング耐性のあるパスワードレス」ブックによる展開の監視#

Microsoftは、Azure Monitorにログを持つ組織が展開の進捗を追跡するために使用できるフィッシング耐性のあるパスワードレスブックをリリースしました。Entra管理センターの [監視] > [ブック] からアクセスできます：

このブックには主に2つのセクションがあります：

9.1 登録準備フェーズ#

このタブを使用してサインインログを分析し、どのユーザーが登録可能か、どのユーザーがブロックされる可能性があるかを判断します。OSプラットフォーム (Windows、macOS、iOS、Android) と認証情報の種類 (Authenticatorアプリのパスキー、FIDO2セキュリティキー、証明書ベースの認証) でフィルタリングできます：

ブックには以下が表示されます：

• 登録準備が完了しているユーザー/デバイスのペア: 選択した認証情報の種類を登録できるユーザー
• 準備が未完了のユーザー/デバイスのペア: 登録に問題がある可能性のあるユーザー (例: 古いOSバージョン)

修復アクション (OSのアップグレード、デバイスの交換、または代替の認証情報オプションなど) が必要なユーザーのリストをエクスポートできます。

9.2 強制準備フェーズ#

ユーザーがフィッシング耐性のある認証のみを利用する準備ができたら、「強制準備フェーズ (Enforcement Readiness)」タブを使用します。まず、フィッシング耐性のあるMFAを要求するレポート専用の条件付きアクセスポリシーを作成します。これにより、強制が有効だった場合にアクセスが_ブロックされたかどうか_に関するデータがサインインログに取り込まれます。

ダッシュボードには以下が表示されます：

• スコープ内の総ユーザー数
• レポートのみの成功 (Report Only Success) - 強制を通過するユーザー
• ポリシーが満たされない (Policy Not Satisfied) - ブロックされるユーザー (これらを調査してください！)
• デバイスの状態、デバイスプラットフォーム、クライアントアプリの内訳

さらなるデータ分析 (Further Data Analysis) タブを使用して、特定のユーザーがブロックされる理由を調査します。このデータは、強制を有効にする前に、修復対象のユーザーを絞り込むのに役立ちます。

9.3 ヘルプデスクの監視を伴うウェーブベースの展開#

Microsoftは、柔軟な日付範囲を持つ複数のウェーブで展開を実行することを推奨しています。シグナルとして、ヘルプデスクのチケット件数を監視してください。

• チケットの件数が増加している: 展開、コミュニケーション、強制アクションのペースを落とします
• チケットの件数が減少している: 活動のペースを再び上げます

各ウェーブ用のMicrosoft Entra IDセキュリティグループを作成し、グループをポリシーに段階的に追加します。これにより、サポートチームへの過負荷を防ぎます。

10. 同期型パスキーのパイロットチェックリスト#

目標がMicrosoft Authenticatorに依存しない同期型パスキーである場合、以下のパイロット姿勢に従ってください：

1. 同期型パスキーの有効化 (プレビュー) 同期型パスキー (プレビュー)に従ってください。

2. パスキープロファイル (プレビュー) を使用し、パイロットグループをターゲットにする パスキープロファイルで説明されているように、同期型パスキーを許可するプロファイルを作成/割り当てます。

3. 構成証明を強制しない (少なくともパイロットグループでは) パスキー (FIDO2) の概念に関するドキュメントにある通り、構成証明を強制すると同期型パスキーが除外されます。

4. 最初は厳密なAAGUIDの許可リストを避ける 最初はフローを確認するために寛容な設定から始め、どのプロバイダーを許可したいかが分かってから制限を強めます。パスキー (FIDO2) の有効化を参照してください。

5. 条件付きアクセスがMicrosoft Authenticatorを強制していないことを確認する CA/認証強度が依然として意図したパスキープロファイルを許可していることを確認します (そうしないと、Microsoft Authenticatorに依存しているように見えます)。

6. IDモデルを確認する (メンバー vs ゲスト) ユーザーがゲストである場合、プロファイルの調整に時間を費やす前に、テナントモデルで期待されるサポートが可能かを確認します。

11. 結論#

企業におけるパスキーの展開は運用上複雑ですが、進むべき道は明確に定義されています。上記で提起された主要な運用上の疑問に対応する重要な答えをまとめます。

1. デバイスバウンド型 vs 同期型パスキー: デバイスバウンドの認証情報 (例: Microsoft Authenticator、Windows Hello、YubiKey、スマートカード) は単一のデバイスに厳密に紐付けられ、AAL3を満たします。同期型パスキー (例: iCloudキーチェーン、Googleパスワードマネージャー) はデバイス間で機能し、AAL2を満たします。ほとんどの組織では両方が必要です。管理者向けにはハードウェア認証器 (AAL3)、より広範な従業員向けには同期型パスキー (AAL2) です。

2. 新しい従業員のブートストラップ: 一時アクセスパス (TAP) を使用して、オンボーディング時の「鶏と卵」の問題を解決します。大規模な展開の場合は、これをGraph APIを介して自動化します。高保証のユースケースでは、Entra検証済みIDとFace Checkを使用してオンボーディングを補完します。

3. スマートフォン交換時のリカバリー: 複数のリカバリー方法を提供します。セルフサービスリカバリーキオスク (ノートPCをブートストラップデバイスとして使用)、マイスタッフを介したマネージャー支援のTAP、およびエッジケース向けの検証済みIDによるSSAR (セルフサービスアカウントリカバリー) です。

4. 構成のミス: 最も頻繁なミスには、構成証明をグローバルに強制すること、同期型パスキーのプレビュー機能を有効にしていないこと、過度に厳密なAAGUID許可リスト、そして循環的な依存関係を生み出す条件付きアクセス (CA) ポリシーが含まれます。

5. B2Bゲスト: ゲストのためにテナントで直接パスキーを登録することは避けてください。代わりに、クロステナントアクセス信頼を有効にして、ゲストのホームテナントからの認証情報を検証します。

6. ハードウェアキー vs モバイルパスキー: ハードウェアセキュリティキーは、特定の高セキュリティの役割 (管理者、共有ワークステーション) には必要ですが、大規模になるとロジスティクスのハードルが生じます。モバイルパスキーは一般に、従業員にとってより実用的です。

7. Windowsと並行するmacOS: JAMF/MDMを用いたプラットフォームSSOを使用して、Windowsの展開と並行してmacOS上のパスキーサポートを有効にします。プラットフォーム固有のワークフローを計画してください。

8. 事前の対策: Intuneを使用して非アクティブなデバイスを特定し、ロックアウトが発生する前にユーザーに修復を促します。早期の導入を促進するために、パスキーの登録をIntuneの登録の前提条件とすることを検討してください。ノートPCをブートストラップデバイスとして使用するセルフサービスのリカバリーワークフローを構築します。

技術の準備は整っています。主な課題は運用上の実行です。リカバリー計画は後回しにするのではなく、初日から不可欠なものとしなければなりません。インフラストラクチャが強固になれば、パスキーが従業員全体の主要な認証方法となるよう、パスキーログインの採用の最適化に注力してください。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

よくある質問 (FAQ)#

条件付きアクセスでフィッシング耐性のあるMFAを有効すると、すべてのユーザーがロックアウトされるのはなぜですか？#

すべてのクラウドアプリに対してフィッシング耐性のあるMFAを要求する条件付きアクセスポリシーを作成すると、パスキーをまだ登録していないユーザーは直ちにブロックされ、セキュリティ情報の登録ページへのアクセス自体もブロックされます。この「セキュリティ情報の登録」のパラドックスと呼ばれる循環的な依存関係のため、強制を有効にする前に、影響を受けるユーザーに一時アクセスパス (Temporary Access Pass) を発行し、初回登録を完了できるようにする必要があります。

テナントでフィッシング耐性のあるMFAが必須な場合、B2Bゲストユーザーにはどのように対応すればよいですか？#

Entra IDでは、ゲストユーザーがリソーステナントにFIDO2キーを登録することはサポートされていないため、ゲストに対してパスキー登録を強制しようとすると失敗します。正しい解決策は、外部IDのクロステナントアクセス設定を構成して、ゲストのホームテナントからのMFAクレームを信頼するようにすることです。つまり、ゲスト自身の組織で使用されているYubiKeyが、テナントへの登録なしにフィッシング耐性のあるMFA要件を満たします。

パスキーでサインインする際、クロスデバイスでのQRコード認証が警告なしに失敗するのはなぜですか？#

クロスデバイス認証では、BLE近接ハンドシェイクを完了するために、PCとスマートフォンの両方でBluetoothが有効になっている必要があります。そのため、Bluetoothを無効にする企業ポリシーがあると、フロー全体が機能しなくなります。また、このフローではcable.auth.comへのWebSocket接続が使用されるため、ファイアウォールやZscalerの構成でこれがブロックされることが多く、明確なエラーメッセージなしにQRコードのスキャンがハングアップしたり失敗したりする原因となります。

フィッシング耐性のあるMFAの強制をオンにする前に、どの従業員が準備できているかをどのように監視できますか？#

Entra管理センターの[監視] > [ブック]からアクセスできるMicrosoftの「フィッシング耐性のあるパスワードレス」ブックには、プラットフォームと認証情報の種類別に、どのユーザー/デバイスのペアが登録可能かを示す「登録の準備状況」ビューが用意されています。強制適用の準備状況を確認するには、フィッシング耐性のあるMFAを要求するレポート専用の条件付きアクセスポリシーを作成します。これにより、実際の強制を有効にする前に、サインインログからどのユーザーがブロックされるかを把握できます。

従業員が新しいスマートフォンに機種変更し、パスキーへのアクセスを失った場合、最善のリカバリー戦略は何ですか？#

推奨されるアプローチは階層型です。WHfBで保護されたノートPCを使用するセルフサービスリカバリーキオスクでは、Graph APIを介して一時アクセスパス (TAP) を生成し、ヘルプデスクを介さずにほとんどのケースをカバーします。ノートPCを持たないユーザーの場合は、マイスタッフポータルを通じたマネージャー支援によるTAPによってリカバリーを直属のマネージャーに委任します。そして、完全な身元再確認が必要なエッジケースには、Entra検証済みID (Verified ID) の生体認証Face Checkを用いたセルフサービスアカウントリカバリーで対応します。

参考文献#

エンタープライズ向けのFIDO2/パスキー展開の深掘りについては、Merill Fernando や Jan Bakker などの専門家をフォローしてください。彼らはMicrosoft Entraの認証に関する実践的なガイダンスを定期的に公開しています。