Microsoft Entra ID で FIDO2 パスキーサインインを展開したところ、「セキュリティキーだけで運用したいのに、なぜかサインイン画面に“電話（iPhone / Android）”“リンク済みデバイス”が出てしまう……」という声はとても多く聞かれます。本記事では、その正体と制御方法、現実的な運用設計までを管理者目線で詳しく解説します。
「パスキーでサインイン」に電話が出てしまう問題とは
Microsoft Entra ID（旧 Azure AD）で FIDO2 を有効化し、条件付きアクセスでパイロットグループに対して「パスキーでサインイン」を強制すると、Windows 10/11 や Edge / Chrome のサインイン UI に、次のような候補が出てくることがあります。
- 電話（iPhone / iPad / Android）
- リンク済みデバイス
- セキュリティキー
しかし、多くの企業がやりたいことはシンプルです。
- YubiKey などの FIDO2 ハードウェアキー（セキュリティキー）だけを使わせたい
- 誤って「電話」や「リンク済みデバイス」を選ばせたくない
つまり、ゴールは次の状態です。
- UI 上に「電話」がある程度残ってしまうのは許容するとしても、実際に認証として通るのはセキュリティキーだけにしたい
まずは、この「電話」や「リンク済みデバイス」が何者なのかを整理しておきましょう。
パスキー / FIDO2 / WebAuthn の関係をざっくり整理
サインイン画面に出てくる候補を理解するには、FIDO2 / WebAuthn 周りの用語を軽く押さえておくとイメージしやすくなります。
| 用語 | 意味 | どこに保存されるか | 典型例 |
|---|---|---|---|
| FIDO2 | パスワードレス認証の標準仕様。CTAP と WebAuthn の総称。 | ハードウェアキー / 端末 / クラウド同期など実装に依存 | FIDO2 セキュリティキー、Windows Hello、パスキー |
| WebAuthn | ブラウザーと認証器をつなぐ Web 標準 API。サイトが「パスキーを使って」と指示するしくみ。 | ブラウザー UI が呼び出す | Edge / Chrome / Safari が利用 |
| パスキー | FIDO2 ベースの「ユーザー名 + サイトごとに固有の鍵」のペア。 | OS / ブラウザー / クラウド同期（iCloud / Google / Microsoft） | iPhone のパスキー、Android のパスキー、Entra ID の FIDO2 資格情報 |
| セキュリティキー | FIDO2 対応ハードウェアトークン。 | 物理デバイスに保存 | YubiKey、Feitian、SoloKey など |
WebAuthn の仕様では、ブラウザーは「このサイトで使えそうな認証器の候補」を一覧表示することになっています。これが Windows の「パスキーでサインイン」ダイアログで出てくる「電話」「リンク済みデバイス」「セキュリティキー」などの正体です。
「電話（iPhone/Android）」の正体は何か
管理者から見ると一番わかりにくいのが「電話（iPhone / iPad / Android）」という表示です。これは大きく分けて次の 2 パターンが絡み合っています。
Microsoft Authenticator のパスキー（プレビュー）
Microsoft Authenticator アプリを使うと、アカウントに対して「パスキー」を登録できるプレビュー機能があります。これを有効化しているテナントで、ユーザーが Authenticator にパスキーを追加すると、サインイン時の候補として「電話」が表示されるようになります。
- Entra ID 上で「Microsoft Authenticator のパスキー」が有効
- ユーザーが Authenticator にパスキーを登録済み
このとき、ユーザーのスマホは「FIDO2 認証器」として振る舞い、ブラウザーから見ると「このアカウントのパスキーを持っている電話」として候補に出てくるわけです。
WebAuthn のハイブリッド認証（近接デバイス）
もう 1 つのパターンが、いわゆる「ハイブリッド認証」や「近接デバイス」です。PC とスマホを BLE / QR コードなどで連携し、スマホに保存されているパスキーを PC のサインインでも使えるようにするしくみです。
- スマホの iCloud / Google / Microsoft アカウントにパスキーが存在
- ブラウザーが「近くのデバイスを探す」機能を有効にしている
この場合も、Windows の UI は「電話」「リンク済みデバイス」として候補を表示します。テナント側から見ると「どの電話なのか」「どのアカウントのパスキーなのか」が見えづらく、「よくわからないけど電話が出ている」という混乱につながります。
テナント側でできること / できないこと
ここが本題です。管理者が一番知りたいのは、次の 2 点でしょう。
- Q1: サインイン UI から「電話」の項目そのものを消せるのか？
- Q2: 実際に使える認証手段を「セキュリティキーだけ」にできるのか？
答えを先にまとめると、次のようになります。
| 項目 | 可否 | 概要 |
|---|---|---|
| サインイン UI から「電話」の表示を完全に消す | できない | WebAuthn の仕様に基づき、ブラウザーが候補を描画するため、テナント設定だけでは非表示にできない。 |
| 「電話」のパスキーを実際には使えないようにする | できる | 登録済みパスキーを削除し、認証方法ポリシーと条件付きアクセスで制御することで、セキュリティキー以外では要件を満たせないようにできる。 |
つまり、「電話」という見た目の候補自体は残り得るが、実際に認証として通るかどうかはこちらでコントロールできるというスタンスになります。
最優先でやるべきこと：ユーザーの登録済みパスキーを整理
まず着手すべきは、ユーザーごとに登録されているパスキーの棚卸し・整理です。特にパイロット段階では、ここをきちんとやるだけで混乱がかなり減ります。
Entra 管理センターでの確認手順
- Microsoft Entra 管理センターに管理者としてサインイン。
- 「ID」 > 「ユーザー」 を開く。
- 対象ユーザーを選択し、「認証方法（セキュリティ情報）」 を開く。
- 登録済みの認証方法一覧の中から、次を確認する。
- FIDO2 セキュリティキー / パスキー
- 「Microsoft Authenticator のパスキー」（プレビュー）
- テスト方針に基づき、不要なものは削除する。
ここで Authenticator のパスキーが残っていると、スマホが FIDO2 認証器として振る舞い続けます。電話の候補そのものは UI から消せないとしても、その電話に紐づいたパスキーを消すことで実質的に使えなくすることができます。
注意点として、Office / Teams / Outlook など複数のサービスでパスキーを試しているユーザーの場合、どの登録がどの端末に対応しているかがわかりづらいことがあります。パイロットの最初は、対象ユーザーの登録を一旦すべて削除してから、改めてセキュリティキーだけ登録し直す運用にしてしまう方がトラブルが少ないケースも多いです。
認証方法ポリシーで「セキュリティキーのみ」運用に寄せる
次に行うのが、テナント全体（またはパイロットグループ）に対する認証方法ポリシーのチューニングです。目的はシンプルで、次の 2 点です。
- FIDO2 セキュリティキーだけを有効にする
- Microsoft Authenticator のパスキー（プレビュー）を無効にする
設定パスの例
- Entra 管理センターで 「保護」 > 「認証方法」 を開く。
- 左メニューから 「ポリシー」 を選択。
- 「FIDO2 セキュリティキー」 を開き、対象ユーザー / グループ（パイロットグループ）に対して 有効にする。
- 同様に、「Microsoft Authenticator のパスキー（プレビュー）」 を探し、無効にする。
これにより、少なくともテナントポリシー上は「Authenticator のパスキーを新規で使う」という選択肢を封じることができます。
Key restriction policy（AAGUID の許可リスト）
さらに一歩踏み込んで、使用を許可するセキュリティキーの種類（メーカー / 型番）を制限したい場合は、Key restriction policy を設定します。
| 項目 | 役割 | ポイント |
|---|---|---|
| AAGUID 許可リスト | 利用を許可するハードウェアキーの一意な ID を指定。 | 特定メーカーの特定モデルだけを使わせたい場合に有効。 |
| AAGUID 拒否リスト | 利用を禁止するキーの ID を指定。 | 既に配布済みの一部モデルだけを締め出す用途など。 |
ただし、ここで重要なのは次の点です。
- Key restriction policy は「使えるキーの種類を制限する機能」であって、「電話」という候補表示を消す機能ではない
あくまで「セキュリティキーの中でも、どのデバイスを許可するか」の制御に使うものだと理解しておきましょう。
条件付きアクセスで FIDO2 セキュリティキーを必須にする
パスキーの候補表示は UI レベルの振る舞いですが、実際のサインインでどの認証手段を認めるかは、条件付きアクセス（CA）と認証強度で制御できます。
認証強度で「FIDO2 セキュリティキー」を要求する
Entra ID の条件付きアクセスでは、「認証強度」という考え方が導入されています。これは、「どの認証方法ならこのリソースにアクセスさせてよいか」を抽象化したものです。
例えば、次のようなポリシーを作成します。
- Entra 管理センターの 「保護」 > 「条件付きアクセス」 を開く。
- 新しいポリシーを作成し、対象ユーザー / アプリ / クラウドアプリを指定。
- 「アクセス制御」 > 「付与」 の設定で、「認証強度」 を選択。
- 認証強度として 「FIDO2 セキュリティキー」（または同等の構成）を要求。
こうしておくと、ユーザーがサインイン画面でどの候補を選択しようと、ポリシー側で「FIDO2 セキュリティキーの認証を通さない限り、アプリへのアクセスを許可しない」というふるまいになります。
つまり、ユーザーが誤って「電話」や「リンク済みデバイス」を選んでも、CA の要件を満たせないため、結果としてセキュリティキー以外では業務アプリに入れない状態を作り出せます。
注意点として、認証強度の評価は「テナントで有効にしている認証方法」に依存します。例えば「Authenticator のパスキー」を有効のままにしていると、構成によっては電話側のパスキーでも条件を満たせてしまう可能性があります。必ずパイロット環境でパターンテストを行い、「求める認証強度を満たすのはセキュリティキーだけ」という状態になっているかを検証しましょう。
端末ローカルの FIDO 情報を掃除する（非公式な手段）
ここまでの手順はすべて、Microsoft が正式に想定しているテナント設定の範囲です。一方で、環境によっては「なぜか以前使っていた FIDO 設定が残っているようで、挙動がおかしい」というケースもあります。
そのような場合にコミュニティベースでよく話題に上るのが、Windows 端末に残っている FIDO 関連の情報をローカルで削除するという方法です。
レジストリの FIDO キーを削除する例
一例として、次のレジストリキー配下を削除することで挙動が改善したという報告があります。
HKEY_USERS\S-1-5-20\Software\Microsoft\Cryptography\FIDO
ただし、これはあくまで「現場の知見レベル」の話であり、正式なサポート対象外の手作業になります。実施する場合は次の点を徹底してください。
- 本番端末ではなく、必ず 検証用端末で試す
- レジストリキーの バックアップを取得してから作業する
- インターネット上に転がっている PowerShell スクリプトをそのまま実行しない
ローカルの FIDO 情報を削除しても、「電話」という候補表示が完全に消えるとは限りませんが、過去の試行錯誤で残った中途半端な状態をリセットするという意味では有効な場合もあります。あくまで「最終手段」「ピンポイントのトラブルシュート」として位置付けるのがよいでしょう。
現実的な落としどころ：UI は残るが、使えるのはセキュリティキーだけ
ここまでを踏まえると、現実的なゴールは次のように整理できます。
- サインイン UI の候補（電話 / リンク済みデバイス）は 完全には消せない
- しかし、テナント設定（認証方法ポリシー + 条件付きアクセス）とユーザーの登録情報の整理によって、実際にサインインに使えるのはセキュリティキーだけにできる
その上で、エンドユーザーには次のようなガイドを周知します。
- サインイン画面では必ず「セキュリティキー」を選ぶ
- 「電話」や「リンク済みデバイス」は使用しない（試してもエラーになる可能性がある）
このように「技術的な制御」と「ユーザー教育」の両輪で運用するのが、現時点で最も現実的な落としどころです。
ユーザー向け案内の具体例
実際の運用では、IT 部門からユーザーへの告知文が重要です。ここでは、社内ポータルやメールで配信しやすいサンプル案内を紹介します。
社内向けお知らせ文のサンプル
件名： 新しいサインイン方法（セキュリティキー）について
本文の例：
セキュリティ強化のため、Microsoft アカウントへのサインイン方法として「セキュリティキー」を導入しました。今後、対象の業務システムにアクセスする際は、以下の点にご注意ください。
- サインイン画面に「パスキーでサインイン」というボタンが表示されます。
- ボタンを押すと「電話」「リンク済みデバイス」「セキュリティキー」など複数の選択肢が表示される場合があります。
- 当社では、「セキュリティキー」のみご利用いただけます。
- 「電話」や「リンク済みデバイス」を選択するとエラーになる場合がありますので、選択しないでください。
不明点がある場合は、情報システム部までお問い合わせください。
このように、「なぜ電話が出るのか」まで説明しなくても、ユーザーにとって必要十分なレベルの説明をコンパクトにまとめるのがポイントです。
よくある勘違いと整理しておきたいポイント
条件付きアクセスを厳しくすれば UI の見た目も変わる？
いいえ、変わりません。条件付きアクセスはあくまで「アクセスを許可するかどうか」を決めるものであり、サインイン画面のボタンや選択肢の見た目を変える機能ではありません。UI の描画は、ブラウザーと OS が WebAuthn の仕様に基づいて行っています。
Key restriction policy で「電話」を消せる？
これも誤解されがちなポイントです。Key restriction policy が制御できるのは、FIDO2 セキュリティキー（ハードウェアキー）の種類だけです。「電話」や「リンク済みデバイス」といった UI 上の候補を消すことはできません。
「電話のパスキー」はどこから来る？
「電話に保存されたパスキー」は、次のような組み合わせで表示されます。
- Microsoft Authenticator に登録されたパスキー（プレビュー機能）
- iCloud や Google アカウントに同期されているパスキー
- WebAuthn のハイブリッド認証機能による「近接デバイス」の候補
どれがどのように表示されるかは、OS / ブラウザー / テナント設定の組み合わせによって変化します。そのため、「このチェックをオフにすれば必ず電話が消える」といった単純なスイッチは現時点では存在しません。
管理者向けチェックリスト
最後に、本記事で解説した対策をチェックリストとしてまとめます。パイロット開始前やトラブルシュートの際に活用してください。
| 項目 | 内容 | 目的 |
|---|---|---|
| ユーザーの認証方法の整理 | ユーザー > 認証方法 から、不要な FIDO2 / パスキー / Authenticator のパスキーを削除。 | 電話側のパスキーを無効化し、誤動作の原因を減らす。 |
| 認証方法ポリシーの設定 | FIDO2 セキュリティキーのみ有効化し、Authenticator のパスキー（プレビュー）を無効化。 | テナント全体で「セキュリティキーのみ」運用に寄せる。 |
| Key restriction policy の検討 | 必要に応じて AAGUID の許可リスト / 拒否リストを設定。 | 利用可能なハードウェアキーの種類を制限する。 |
| 条件付きアクセスの認証強度 | アクセス制御で「認証強度 = FIDO2 セキュリティキー」を要求。 | セキュリティキー以外の認証では業務アプリに入れないようにする。 |
| 端末ローカル情報の整理（任意） | 検証端末で FIDO 関連のレジストリキーをバックアップのうえ整理。 | 過去の試行錯誤で残った中途半端な状態をリセットする。 |
| エンドユーザー向け周知 | サインイン時は「セキュリティキー」を選択するよう通知。FAQ やスクリーンショットで案内。 | 誤操作とヘルプデスク問い合わせを減らす。 |
まとめ：設計のポイントと今後の付き合い方
「パスキーでサインイン」に「電話」や「リンク済みデバイス」が出てしまうのは、決して構成ミスではなく、WebAuthn / パスキー時代の「標準的な挙動」と言えます。一方で、企業としては「いまはハードウェアキーだけに絞りたい」という要件も根強く、ここにはどうしてもギャップが生じます。
現状でとれるベストプラクティスは次の通りです。
- サインイン UI の候補表示は「ブラウザーの仕様」と割り切る
- セキュリティキー以外のパスキーは、テナント設定と登録情報の整理で実質的に使えないようにする
- 条件付きアクセスで FIDO2 セキュリティキーを必須にし、実運用としてはセキュリティキーだけが通る状態を作る
- ユーザーには「セキュリティキーを選んでください」と具体的な画面イメージ付きで周知する
将来的には、パスキーのエコシステムが成熟し、スマホや OS プラットフォームに保存されたパスキーも企業利用で広く受け入れられていく可能性があります。しかし、現時点で「まずは FIDO2 セキュリティキーから」というロードマップを取る企業は多く、そのためには本記事で紹介したような段階的な設計と運用ルール作りが不可欠です。
「電話が出てしまう」こと自体をゼロにしようとするのではなく、「たとえ出ていても、業務上問題は起きない」構成に落とし込むことが、パスワードレス時代の現実的なセキュリティ設計と言えるでしょう。
コメント