Microsoftの「World Passkey Day: Advancing passwordless authentication」で押さえるべき結論は、パスキーを“便利な追加機能”ではなく、パスワードやSMS、セキュリティ質問などのフィッシングされやすい認証手段を置き換える標準認証として広げていく方針が明確になったことです。管理者はMicrosoft Entra IDのパスキープロファイル、条件付きアクセス、アカウント回復、SSPRの代替手段を確認する必要があります。開発者は、Microsoft Entra IDやMicrosoft Entra External IDを使うアプリで、FIDO2パスキーが正しく使えるサインイン導線になっているかを早めに検証すべきです。(Microsoft)
MicrosoftのWorld Passkey Day発表は「パスキー推進」だけではない
今回のMicrosoft Security Blogの発表は、World Passkey Dayに合わせた啓発記事であると同時に、Microsoftの認証基盤全体がどこへ向かうのかを示す実務上重要なアップデートです。ポイントは、パスキー対応を増やすだけでなく、パスワードリセットやアカウント回復のような“抜け道”まで含めて、フィッシングされやすい認証経路を減らすことにあります。(Microsoft)
Microsoftは、AIを使った攻撃が自動化・高度化するなかで、アカウントの安全性は最も弱い認証情報に左右されると説明しています。つまり、パスキーを導入しても、回復フローにセキュリティ質問や弱い本人確認が残っていれば、攻撃者はそこを狙えます。(Microsoft)
今回の変更は、Microsoft 365やAzureを使う企業だけでなく、Microsoft Entra IDで社内アプリを保護している組織、Microsoft Entra External IDで顧客向けアプリを構築している開発チーム、Windows HelloやMicrosoft Authenticatorを運用している情シス部門にも関係します。
主な変更点を一覧で整理
| 項目 | 変更・発表内容 | 実務上の確認ポイント |
|---|---|---|
| Microsoft Entra IDのパスキー | 同期パスキー、デバイスバウンドパスキー、パスキープロファイルの活用を拡大 | 対象グループ、許可するパスキー種別、認証器制限、証明構成を確認 |
| Microsoft Entra passkey on Windows | 個人用・未管理のWindows端末でもWindows HelloコンテナーにFIDO2パスキーを登録してEntra IDにサインインできる方向へ拡大 | Windows Hello for Businessとの違い、デバイスサインインには使えない点を説明 |
| Microsoft Entra External ID | 顧客向けアプリでパスキー利用を広げる方針。公式ブログでは2026年5月下旬の一般提供予定とされている | CIAMアプリのサインアップ・サインイン導線、ネイティブアプリの認証方式を検証 |
| Passkey-preferred authentication | 登録済みの認証方法から、より強い方法を優先表示するプレビュー機能 | ユーザー体験の変化、ヘルプデスク問い合わせ、例外グループを確認 |
| Microsoft Password Manager | Microsoftアカウントでサインインしたデバイス間のパスキー保存・同期を拡大 | 主に個人向け領域。企業管理下ではEntra ID側のポリシーを優先 |
| Microsoft Entra ID account recovery | すべての認証方法を失った場合の高保証アカウント回復が一般提供 | 評価モードで検証し、ID確認プロバイダー、本人確認属性、プライバシー要件を確認 |
| セキュリティ質問 | SSPRでの利用廃止に向けた移行が必要 | セキュリティ質問依存のユーザーを洗い出し、別の認証方法へ移行 |
パスキーが重視される理由
パスキーは、パスワードのようにユーザーが覚えたり入力したりする秘密情報ではありません。秘密鍵はユーザーの端末や認証器に保存され、サービス側には公開鍵が登録されます。サインイン時は、端末のPIN、顔認証、指紋認証などで秘密鍵の利用を許可し、Microsoft Entra IDなどのサービスが署名を検証します。(Microsoft Learn)
重要なのは、パスキーが登録先のWebサイトやアプリに結び付く点です。攻撃者が見た目だけ似せた偽サイトを用意しても、パスキーはその偽サイトに対して有効な認証情報を渡しません。そのため、パスワード、SMSコード、メールのワンタイムコードよりもフィッシングに強い認証方法として扱われます。(Microsoft Learn)
ただし、「パスキーを有効にしたから安全」と考えるのは早計です。SSPR、ヘルプデスクによる本人確認、古いMFA、例外アカウント、管理者アカウントの回復手順まで含めて見直さなければ、攻撃者は弱い経路を探します。
Microsoft Entra ID管理者が最初に確認すべき設定
Microsoft Entra IDでパスキーを展開する場合、まず確認すべきは「誰に、どの種類のパスキーを、どの条件で許可するか」です。Microsoft Learnでは、パスキーを有効にする流れとして、パスキープロファイルの有効化、プロファイル作成、対象グループへの適用、必要に応じた同期パスキーの有効化、条件付きアクセスによる強制を挙げています。(Microsoft Learn)
パスキープロファイルで決めること
パスキープロファイルでは、テナント全体に一律で設定するのではなく、グループ単位でパスキーの要件を分けられます。たとえば、管理者や役員にはデバイスバウンドパスキーを必須にし、一般社員には同期パスキーも許可する、といった設計が可能です。(Microsoft Learn)
| 利用者 | 推奨される考え方 | 理由 |
|---|---|---|
| グローバル管理者、特権ロール保持者 | デバイスバウンドパスキー、FIDO2セキュリティキー、Microsoft Authenticatorのパスキーを優先 | 端末や認証器を明確に管理しやすい |
| 一般社員 | 同期パスキーも候補に入れる | 利用開始しやすく、紛失時の再発行負荷を抑えやすい |
| 高規制業界、機密システム利用者 | 証明、AAGUID制限、条件付きアクセスを厳格化 | 認証器の種類や信頼性を管理する必要がある |
| 契約社員・外部協力者 | 対象範囲と回復手順を明確に分ける | ライフサイクル管理とアカウント回復で混乱しやすい |
同期パスキーは、Apple iCloud KeychainやGoogle Password Managerなどのクラウド型パスキープロバイダーを通じて複数デバイスで利用できます。一方、同期パスキーでは証明がサポートされないため、端末境界を厳密に管理したい利用者には、デバイスバウンドパスキーを選ぶ判断が必要です。(Microsoft Learn)
条件付きアクセスで「使える」から「使わせる」へ移行する
パスキーを登録できるだけでは、ユーザーがいつまでもパスワードやSMSを使い続ける可能性があります。機密性の高いアプリや管理者操作では、条件付きアクセスの認証強度を使い、フィッシング耐性のある認証を要求する設計が現実的です。(Microsoft Learn)
ただし、いきなり全社へ強制すると、未登録ユーザーや端末条件を満たさないユーザーがロックアウトされます。最初はパイロットグループで登録率、失敗率、問い合わせ内容を確認し、その後に部門単位で広げるのが安全です。
Windows Hello for Businessとの違いに注意
Microsoft Entra passkey on Windowsは、Windows HelloのPIN、顔認証、指紋認証を使って、ローカルのWindows HelloコンテナーにFIDO2パスキーを保存し、Microsoft Entra IDへサインインできる仕組みです。個人所有端末や未登録端末でも利用できる点が特徴です。(Microsoft Learn)
ここで混同しやすいのがWindows Hello for Businessです。Windows Hello for Businessは、企業管理下のMicrosoft Entra参加済みまたは登録済みデバイスで、デバイスサインインやSSOに使われる認証基盤です。一方、Microsoft Entra passkey on WindowsはFIDO2パスキーであり、デバイスサインインには使えません。Microsoftの説明でも、Windows Hello for Businessを置き換えるものではなく、未登録端末などのシナリオを補完する位置付けです。(Microsoft Learn)
管理者は、次のように説明を分けるとユーザー混乱を防げます。
| 項目 | Microsoft Entra passkey on Windows | Windows Hello for Business |
|---|---|---|
| 主な用途 | Entra IDへのFIDO2パスキーサインイン | 企業管理デバイスへのサインインとSSO |
| デバイス参加 | 不要でも利用可能 | Microsoft Entra参加・登録デバイスが中心 |
| デバイスサインイン | 対応しない | 対応する |
| 管理 | Entra IDのAuthentication methods policy | Intune、グループポリシーなど |
| 向いている場面 | BYOD、共有PC、複数Entraアカウント利用 | 企業支給PC、標準管理端末 |
プレビュー段階では、Windows HelloのAAGUIDをパスキープロファイルで明示的に許可し、証明を強制しないなどの要件がありました。公式ブログでは2026年5月下旬の一般提供予定とされていますが、展開時点の最新ドキュメントでGA後の要件を確認する必要があります。(Microsoft)
アカウント回復を見直さないとパスキー導入は中途半端になる
今回の発表で見落としやすいのが、Microsoft Entra ID account recoveryです。これは、ユーザーがすべての認証方法を失った場合に、政府発行IDや生体情報の確認を使って本人性を再確認し、新しい認証方法を登録できるようにする機能です。(Microsoft Learn)
従来のヘルプデスク主導の回復は、攻撃者がユーザーになりすましてサポート担当者をだますリスクがあります。アカウント回復機能は、このようなソーシャルエンジニアリングの経路を減らす狙いがあります。(Microsoft Learn)
管理者が確認すべき項目は次のとおりです。
| 確認項目 | 実務で見るべきポイント |
|---|---|
| 対象ユーザー | 全社員にするか、まずはパイロットや高リスク部門から始めるか |
| 回復モード | Evaluationで検証してからProductionへ切り替える |
| ID確認プロバイダー | 対応地域、本人確認書類、費用、データ保持を確認 |
| 照合属性 | 氏名だけで足りるか、社員番号やHRシステムとの照合が必要か |
| Temporary Access Pass | 有効期間、再登録させる認証方法、ヘルプデスク手順を定義 |
| プライバシー | 政府発行IDや生体情報を扱うため、社内規程と地域要件を確認 |
Microsoft Learnでは、新しいプロファイルはEvaluationモードで開始し、ユーザーとポリシーに合うか確認してからProductionへ移行することが推奨されています。また、政府発行IDや生体情報を第三者プロバイダーで処理するため、プライバシー、データ保持、地域コンプライアンスを事前に確認する必要があります。(Microsoft Learn)
セキュリティ質問依存のSSPRは早めに移行する
セキュリティ質問は、ユーザー本人しか知らない情報に見えても、SNS、過去の漏えい情報、推測、ソーシャルエンジニアリングで破られやすい方法です。Microsoftの公式ブログでは、Microsoft Entra IDでパスワードリセット手段としてのセキュリティ質問を廃止していく方針が示されています。(Microsoft)
なお、公式ブログでは2027年1月からの削除に触れていますが、Microsoft Learnのセキュリティ質問ページではSSPRでの廃止時期を2027年3月と説明しています。実際の適用時期はテナント通知や最新ドキュメントで確認しつつ、2026年中に移行計画を終えておくのが安全です。(Microsoft)
移行では、次の順番で進めると失敗しにくくなります。
| 手順 | 作業内容 |
|---|---|
| 現状把握 | SSPRでセキュリティ質問を登録・利用しているユーザーを確認 |
| 代替手段の決定 | Microsoft Authenticator、パスキー、Temporary Access Pass、電話以外の方法を検討 |
| ユーザー通知 | 「質問が使えなくなる」だけでなく「何を登録すべきか」を具体的に案内 |
| パイロット | 部門単位で登録率と問い合わせ内容を確認 |
| 強制移行 | 期限を決めてセキュリティ質問への依存を減らす |
| 廃止後の監視 | ロックアウト、SSPR失敗、ヘルプデスク増加を確認 |
開発者が確認すべきアプリ側の落とし穴
パスキー対応は、管理者がEntra IDで有効化すれば終わりではありません。開発中のアプリや既存アプリの認証実装によっては、FIDO2パスキーが表示されなかったり、ユーザーがパスワード認証へ誘導されたりします。
Microsoftの開発者向けガイダンスでは、FIDO2パスワードレス認証を阻害しやすい設定として、ドメインヒントでHome Realm Discoveryを迂回すること、SAMLのRequestedAuthnContextでパスワード必須を指定すること、互換性の低い埋め込みブラウザーを使うことなどが挙げられています。(Microsoft Learn)
アプリ種別ごとの確認ポイント
| アプリ種別 | 確認ポイント |
|---|---|
| Webアプリ | ブラウザーとOSの組み合わせでFIDO2が使えるか確認 |
| SPA | MSAL構成、リダイレクトURI、ブラウザー互換性を確認 |
| Windowsデスクトップアプリ | .NETアプリではWAM利用を優先。埋め込みが必要ならWebView2を検討 |
| Androidアプリ | MSALでBROWSERを使うか、ブローカー統合を検討 |
| iOS・macOSアプリ | ASWebAuthenticationSessionまたはブローカー統合を利用 |
| SAMLアプリ | RequestedAuthnContextでパスワードを要求していないか確認 |
| 顧客向けアプリ | Entra External IDのパスキー対応状況とサインアップ導線を検証 |
特にモバイルアプリでは、独自の埋め込みWebViewでサインイン画面を表示していると、パスキーや条件付きアクセス、SSOの動作に影響することがあります。MSALやシステムブラウザー相当の認証面を使う設計に寄せることが重要です。(Microsoft Learn)
展開時に失敗しやすいポイント
パスキー展開で多い失敗は、技術設定そのものよりも、対象者、例外、回復手順、ユーザー説明の設計不足です。
いきなり全社強制する
全社一括でパスキー必須にすると、端末条件を満たさないユーザー、外出中のユーザー、共有端末利用者、レガシーアプリ利用者がサインインできなくなる可能性があります。まずは管理者、IT部門、セキュリティ意識の高い部門でパイロットを行い、登録手順と回復手順を検証しましょう。
同期パスキーとデバイスバウンドパスキーを混同する
同期パスキーは展開しやすく、紛失時の負担も軽くなります。一方で、どの端末に同期されたかを管理者が完全に把握・制御することは現時点では難しいとMicrosoftは説明しています。厳密な端末境界が必要な管理者や高リスクユーザーには、デバイスバウンドパスキーを優先する判断が必要です。(Microsoft Learn)
弱いフォールバックを残す
パスキーを登録しても、SMS、音声通話、セキュリティ質問、ヘルプデスク手動リセットが残っていれば、攻撃者はより弱い方法を狙います。Microsoftが強調しているのは、強い認証方法を追加するだけでなく、フィッシングされやすい資格情報を減らすことです。(Microsoft)
ヘルプデスクを巻き込まない
パスキー導入直後は、「どの端末に登録すればよいか」「スマートフォンを紛失した」「Windows Hello for Businessと何が違うのか」といった問い合わせが増えます。ヘルプデスクには、登録手順、削除手順、Temporary Access Pass発行基準、本人確認手順を事前に共有しておきましょう。
管理者向けチェックリスト
展開前に、少なくとも次の項目を確認してください。
| 分類 | チェック内容 |
|---|---|
| 認証方法 | パスワード、SMS、音声通話、TOTP、Authenticator、FIDO2、セキュリティ質問の利用状況を確認 |
| 対象グループ | 管理者、一般社員、外部協力者、共有端末利用者を分ける |
| パスキープロファイル | デバイスバウンド、同期パスキー、証明、AAGUID制限を定義 |
| 条件付きアクセス | 重要アプリや管理者操作でフィッシング耐性のある認証を要求 |
| アカウント回復 | Evaluationモードで検証し、Production移行条件を決める |
| SSPR | セキュリティ質問依存を洗い出し、代替手段へ移行 |
| 端末要件 | Windows、macOS、iOS、Android、ブラウザーの互換性を確認 |
| 開発アプリ | MSAL、システムブラウザー、SAML設定、WebView利用状況を確認 |
| 監視 | サインインログ、監査ログ、認証方法レポート、ヘルプデスク件数を確認 |
| ユーザー案内 | 登録手順、紛失時の対応、使ってよい端末、問い合わせ先を明記 |
パスキー利用状況は、監査ログ、サインインログ、ユーザー通知などで追跡できます。Microsoftは、パスキーに自動有効期限はないため、登録・利用状況の監視とライフサイクル管理が重要だと説明しています。(Microsoft Learn)
開発者向けチェックリスト
開発チームは、アプリ単位で次の確認を進めると実装上の問題を早く見つけられます。
| 分類 | チェック内容 |
|---|---|
| 認証ライブラリ | MSALを利用し、プラットフォーム推奨の認証面を使っているか |
| ブラウザー | FIDO2対応ブラウザーとOSの組み合わせを確認したか |
| 埋め込み認証 | 独自WebViewでパスキーを阻害していないか |
| SAML | RequestedAuthnContextでパスワード必須にしていないか |
| ドメインヒント | フェデレーション先でパスキーが使えない導線になっていないか |
| モバイル | iOSはASWebAuthenticationSession、Androidはシステムブラウザーまたはブローカー統合を確認 |
| 顧客向け認証 | Entra External IDのパスキー対応を前提にサインアップ、回復、再認証をテスト |
| 障害時対応 | パスキー未登録、端末紛失、ブラウザー非対応時の代替導線を設計 |
開発者にとって重要なのは、「ログイン画面が出るか」ではなく、「最も安全な認証方法が自然に提示されるか」です。ユーザーが毎回パスワード入力へ戻ってしまう導線では、パスキー導入の効果が下がります。
次に取るべき行動
MicrosoftのWorld Passkey Day発表は、パスキーを一部の先進ユーザー向け機能から、企業と顧客向けアプリの標準的な認証体験へ広げる節目と捉えるべきです。
まず管理者は、Microsoft Entra IDのAuthentication methods policyで現在の認証方法を棚卸しし、パスキープロファイル、条件付きアクセス、アカウント回復、SSPRのセキュリティ質問移行を同じ計画にまとめてください。開発者は、MSAL、システムブラウザー、SAML設定、Entra External IDのサインインフローを点検し、パスキーが阻害されない実装へ修正しましょう。
最初の目標は「全員を即パスワードレスにすること」ではありません。管理者や高リスクユーザーから確実にパスキーを登録し、弱い回復手段を減らし、サインインログと問い合わせ状況を見ながら段階的に展開することです。それが、パスワードレス認証を現場で失敗させない最短ルートです。
コメント