Microsoft Entra IDでフィッシング耐性のあるパスワードレス認証を始めるなら、最初にやるべきことは「パスキーを全ユーザーに一斉有効化すること」ではありません。対象ユーザー、端末、利用アプリ、認証方式、移行順序を整理し、Authentication methods policyとConditional Accessの認証強度を使って段階的に展開することが重要です。
Microsoftの公式ガイダンスでは、パスワードを現代の攻撃者にとって主要な攻撃ベクトルと位置づけ、Microsoft Entra IDで利用できるフィッシング耐性のあるパスワードレス認証として、Passkeys（FIDO2）、Windows Hello for Business、Microsoft Authenticatorのパスキー、FIDO2セキュリティキー、同期パスキー、証明書ベース認証などを示しています。(Microsoft Learn)
この記事では、Microsoft Entra IDでパスワードレス認証を展開する管理者・開発者向けに、公式情報の要点、影響範囲、確認すべき設定、移行時の注意点を実務目線で整理します。
Microsoft Entra IDのパスワードレス認証でまず理解すべきこと
Microsoft Entra IDにおけるフィッシング耐性のあるパスワードレス認証は、単なるMFA強化ではありません。ユーザーがパスワードを入力しない、またはパスワードに依存しない形で、フィッシングに強い認証方式へ移行する取り組みです。
従来のMFAは、SMS、音声通話、プッシュ通知などを組み合わせることでパスワード単体より安全になります。しかし、攻撃者が偽サイトや中間者攻撃で認証情報やセッションを狙うケースでは、MFAだけでは十分でない場面があります。
フィッシング耐性のある認証方式では、認証情報が登録先のサイトやアプリと暗号学的に結びつきます。Passkeys（FIDO2）は、秘密鍵を端末側に保持し、公開鍵をサービス側に保存する仕組みで、登録先と異なる偽サイトでは認証が成立しにくい設計です。Microsoftの説明では、Passkeys（FIDO2）はWebAuthnとCTAPに基づき、本人確認には生体認証やPINを使えます。(Microsoft Learn)
管理者が押さえるべき結論は、次の3点です。
| 観点 | 実務上の判断 |
|---|---|
| 認証方式 | 全員に同じ方式を配るのではなく、管理者、一般社員、共有端末利用者、BYOD利用者などで分ける |
| 展開方法 | 全社一括ではなく、グループ単位・部門単位・端末種別単位で段階展開する |
| 強制方法 | 認証方式を有効化するだけでなく、Conditional Accessの認証強度で重要リソースへのアクセス条件を制御する |
公式情報で整理された主な変更点と確認ポイント
今回の公式情報で重要なのは、Microsoft Entra IDのパスワードレス認証が「有効化手順」だけでなく、前提条件の確認、関係者の整理、端末準備、アプリ対応、段階展開、監視まで含む導入プロジェクトとして整理されている点です。
特に注目すべき変更・整理ポイントは次のとおりです。
| 確認ポイント | 内容 | 管理者への影響 |
|---|---|---|
| 利用できる認証方式の整理 | Passkeys（FIDO2）、Windows Hello for Business、Microsoft Entra passkey on Windows、Authenticatorアプリのパスキー、FIDO2セキュリティキー、同期パスキー、証明書ベース認証などが選択肢として示されている | ユーザー属性ごとに方式を選ぶ設計が必要 |
| ライセンス要件 | Microsoft Entraでの登録やパスワードレスサインイン自体にはライセンス不要だが、Conditional Accessでの強制や認証方法アクティビティレポートの活用にはMicrosoft Entra ID P1以上が推奨されている | 無償機能だけで完結させず、強制・監査まで含めたライセンス確認が必要 |
| 権限の整理 | Authentication Administrator、Authentication Policy Administrator、User Administratorなど、作業ごとに必要なロールが異なる | グローバル管理者で作業し続けるのではなく、最小権限で運用設計する必要がある |
| 関係者の明確化 | IAM、情報セキュリティ、監査、ヘルプデスク、利用者向けコミュニケーション担当などが関係する | 技術部門だけで進めると、問い合わせ対応や利用者周知で失敗しやすい |
| Microsoft Entra passkey on Windows | 2026年6月4日更新の公式情報では、Windows HelloのローカルコンテナにFIDO2パスキーを登録し、Microsoft Entra IDへのサインインに使えることが明確化されている | Windows Hello for Businessとの違いを理解して、端末管理方針に合わせた使い分けが必要 |
Microsoft Entra passkey on Windowsは、Windows HelloのPIN、指紋、顔認証で保護されたローカルコンテナにFIDO2パスキーを保存し、Microsoft Entra IDへのサインインに利用する機能です。Microsoft Entra参加済みまたは登録済みの端末でなくても利用でき、1台のWindows PCに複数のMicrosoft Entraアカウント用パスキーを保存できます。(Microsoft Learn)
ただし、これはWindows Hello for Businessの置き換えではありません。Windows Hello for Businessは企業管理端末へのサインインやSSOと結びついた仕組みである一方、Microsoft Entra passkey on WindowsはMicrosoft Entra IDへのFIDO2認証に使うローカルパスキーです。デバイスサインインには使えず、登録や認証はMicrosoft Entra IDのPasskey（FIDO2）ポリシーとパスキープロファイルで管理されます。(Microsoft Learn)
影響範囲は「認証設定」だけではない
Microsoft Entra IDのパスワードレス認証は、管理センターで設定を切り替えるだけでは完了しません。影響は、ユーザー体験、端末管理、アプリ認証、サポート、監査まで広がります。
| 対象 | 影響する内容 | 事前に確認すべきこと |
|---|---|---|
| 一般ユーザー | サインイン方法、登録手順、紛失時の復旧方法が変わる | 利用端末、モバイル利用可否、本人確認手段、バックアップ認証方法 |
| 管理者・特権ユーザー | より強い認証方式を優先すべき対象になる | FIDO2セキュリティキー、証明書ベース認証、専用端末、緊急アクセスアカウント |
| ヘルプデスク | 初期登録、端末紛失、機種変更、パスキー再登録の問い合わせが増える | 手順書、本人確認フロー、TAP発行ルール、復旧時の権限 |
| アプリ開発者 | アプリ側の認証方式や埋め込みブラウザーがFIDO2対応を妨げる場合がある | MSAL利用、システムブラウザー利用、SAML設定、ドメインヒント、プロキシ設定 |
| セキュリティ担当 | 認証強度、サインインログ、リスク検出、トークン保護などの監視が必要 | Conditional Access、ID Protection、サインインログ、SIEM連携 |
| 監査・コンプライアンス担当 | 誰がどの認証方式を使えるか、強制できているかの証跡が必要 | Authentication Methods Activity、ポリシー変更履歴、例外ユーザー一覧 |
特に注意したいのは、「登録できる」ことと「強制できる」ことは別という点です。Authentication methods policyでPasskeys（FIDO2）を有効化しても、重要アプリへのアクセス時に必ずフィッシング耐性MFAを要求するには、Conditional Accessの認証強度を設計する必要があります。
Microsoft Entra IDには、組み込みの認証強度として「Multifactor authentication strength」「Passwordless MFA strength」「Phishing-resistant MFA strength」が用意されており、Phishing-resistant MFA strengthは最も制限の強い選択肢として位置づけられています。(Microsoft Learn)
認証方式の選び方：全員に同じ方式を配らない
パスワードレス認証の展開で失敗しやすいのは、「安全そうだから全員にFIDO2セキュリティキーを配る」「便利そうだから同期パスキーだけを許可する」といった単純化です。
実務では、ユーザーのリスク、端末の管理状態、業務形態、復旧のしやすさを見て方式を分けるべきです。
| 認証方式 | 向いているユーザー・場面 | 注意点 |
|---|---|---|
| FIDO2セキュリティキー | 管理者、経営層、金融・医療・公共など高い保証が必要な利用者 | 配布コスト、紛失時対応、予備キー、在庫管理が必要 |
| 同期パスキー | 一般社員、スマートフォン中心の利用者、BYOD利用者 | 利便性は高いが、同期プロバイダー依存になる。Attestationが必要な環境では合わない場合がある |
| Microsoft Authenticatorのパスキー | モバイル端末を業務で利用するユーザー | アプリバージョン、端末紛失時対応、端末登録ルールを確認する |
| Microsoft Entra passkey on Windows | 非参加・未登録のWindows端末、複数の職場・学校アカウントを使うWindows端末 | デバイスサインインには使えない。Attestationはサポートされない |
| Windows Hello for Business | 企業管理のWindows端末、Microsoft Entra参加またはハイブリッド参加端末 | 端末サインインやSSOと結びつく。Passkey（FIDO2）ポリシーでは管理しない |
| 証明書ベース認証・スマートカード | 厳格なPKI運用がある組織、規制業種、既存スマートカード環境 | 構成が複雑。OID、証明書バインド、PKI運用、失効管理が必要 |
Microsoftの展開ガイダンスでは、ほとんどのユーザーが少なくとも1つのポータブル資格情報を持ち、利用する各コンピューティング端末にローカル資格情報を持つ状態を目標としています。また、端末紛失や盗難に備え、少なくとも2つの認証方法を登録することが推奨されています。(Microsoft Learn)
管理者が最初に確認すべき設定
Authentication methods policyを中心に管理する
Microsoft Entra IDの認証方法管理では、Authentication methods policyが推奨される管理方法です。このポリシーでは、パスワードレス認証を含む認証方法を、すべてのユーザーまたは特定グループに対して有効化できます。(Microsoft Learn)
確認場所は次のとおりです。
| 作業 | 確認場所 |
|---|---|
| 認証方法の有効化 | Microsoft Entra admin center → Entra ID → Authentication methods → Policies |
| Passkeys（FIDO2）の有効化 | Authentication methods → Policies → Passkey（FIDO2） |
| Microsoft Authenticatorの設定 | Authentication methods → Policies → Microsoft Authenticator |
| 認証方法の移行状況 | Authentication methods policy内の移行ガイド |
| ユーザーの登録状況 | Authentication Methods Activity |
すでに古いMFAポリシーやSSPRポリシーで認証方法を管理している環境では、設定が分散している可能性があります。Microsoftは、従来のMFAおよびSSPRポリシーでの認証方法管理について非推奨化を案内しており、2025年9月30日以降はこれらのレガシーポリシーで認証方法を管理できなくなると説明しています。未移行のテナントでは、Authentication methods policyへの統合状況を優先的に確認してください。(Microsoft Learn)
Passkeyプロファイルをユーザー属性ごとに分ける
Passkeyプロファイルは、Passkeys（FIDO2）の利用条件をグループ単位で細かく制御する機能です。たとえば、管理者にはデバイスバウンドパスキーのみを許可し、一般ユーザーには同期パスキーも許可するといった設計ができます。
Passkeyプロファイルでは、主に次の項目を制御できます。
| 設定 | 役割 |
|---|---|
| Enforce attestation | 認証器のベンダーやモデルを信頼できるメタデータで検証する |
| Passkey types | Device-bound、Syncedなど、許可するパスキー種別を選ぶ |
| AAGUID制限 | 特定の認証器モデルやプロバイダーを許可またはブロックする |
| 対象グループ | 管理者、一般社員、パイロットユーザーなどに分けて適用する |
注意点として、Passkeyプロファイルを有効化すると、既存のグローバルなPasskey（FIDO2）ポリシー設定はDefault passkey profileに移行されます。また、公式情報ではDefaultを含めて最大3つのPasskeyプロファイルがサポートされ、プロファイル有効化後はオプトアウトできないと説明されています。(Microsoft Learn)
Attestationの扱いを慎重に決める
Attestationは、登録された認証器が正規のベンダー・モデルであることを確認するための仕組みです。高い保証が必要な管理者や規制業務では有効な選択肢ですが、すべての方式と相性がよいわけではありません。
たとえば、同期パスキーはAttestationをサポートしません。また、Microsoft Entra passkey on WindowsもAttestationをサポートしていないため、PasskeyプロファイルでEnforce attestationを選択すると、Windows Helloへのパスキー登録が失敗します。(Microsoft Learn) (Microsoft Learn)
実務では、次のように分けると判断しやすくなります。
| 方針 | 向いているケース |
|---|---|
| Attestationを必須にする | 管理者、特権ID、高リスク業務、認証器モデルを厳格に統制したい環境 |
| Attestationを必須にしない | 一般社員への広範な展開、同期パスキーを許可したい環境、Windowsローカルパスキーを使いたい環境 |
| AAGUID制限を使う | 配布済みのFIDO2キーだけを許可したい場合、特定ベンダーに統一したい場合 |
ただし、AAGUID制限を変更すると、過去に登録済みの認証器がサインインに使えなくなる場合があります。特に本番適用後のAAGUID削除は、サインイン障害につながりやすいため、パイロットグループで検証してから展開してください。(Microsoft Learn)
Conditional Accessの認証強度で強制する
認証方式を有効化しただけでは、ユーザーが常にその方式を使うとは限りません。重要アプリや管理者操作でフィッシング耐性MFAを必須にするには、Conditional Accessの認証強度を使います。
認証強度はAuthentication methods policyを前提に、特定のシナリオで使える認証方法をさらに制限する仕組みです。たとえば、社内ポータルでは通常のMFAを許可し、管理ポータルや機密データへのアクセスではPhishing-resistant MFA strengthを要求する、といった設計ができます。(Microsoft Learn)
実務では、最初から全リソースに強制するのではなく、次の順で進めると安全です。
| フェーズ | 対象 | 推奨アクション |
|---|---|---|
| 検証 | IT部門、ヘルプデスク、セキュリティ担当 | Passkeys（FIDO2）登録、サインイン、復旧手順を確認 |
| 初期適用 | 管理者、特権ロール保有者 | 管理ポータルや重要アプリにPhishing-resistant MFA strengthを要求 |
| 拡大 | 部門単位、端末種別単位 | Windows、macOS、iOS、Androidなどプラットフォーム別に段階適用 |
| 全社展開 | 一般ユーザー | 登録率、失敗率、問い合わせ件数を見ながら対象を広げる |
端末準備で確認すべきこと
パスワードレス認証は、端末のOS、ブラウザー、認証器、端末参加状態に依存します。Microsoftの展開ガイダンスでは、フィッシング耐性のあるパスワードレス認証を利用する端末について、Windows 10 22H2、Windows 11 22H2、macOS 13 Ventura、iOS 17、Android 14などを最低目安として挙げています。古いOSでは、FIDO2セキュリティキーのような外部認証器が必要になる場合があります。(Microsoft Learn)
ただし、実際の展開では「公式の最低要件を満たしているか」だけでなく、社内のサポート対象OS、MDM管理状態、ブラウザー標準、プロキシ設定も確認してください。
| 確認項目 | 具体的なチェック |
|---|---|
| Windows端末 | Windows Hello対応、Microsoft Entra参加・登録状態、Windows Hello for Businessの既存構成 |
| macOS端末 | Platform SSOやSecure Enclave利用可否、Intune管理状態 |
| iOS / Android | Authenticatorアプリ利用可否、OSバージョン、端末紛失時の復旧手順 |
| ブラウザー | FIDO2対応、WebAuthn対応、業務アプリでの埋め込みブラウザー利用有無 |
| 共有端末 | ユーザーごとの認証情報分離、端末上限、サインアウト運用 |
| ネットワーク | Apple関連ドメイン、Microsoftサインイン関連通信、プロキシやSSLインスペクションの影響 |
Microsoft Entra passkey on Windowsを利用する場合は、Windows 10またはWindows 11で、端末がWindows Helloをサポートしている必要があります。構成面では、Enforce attestationを選択せず、Passkey typesにDevice-boundを含める必要があります。(Microsoft Learn)
移行・展開の進め方
パスワードレス認証の展開は、次の順序で進めると失敗しにくくなります。
| 手順 | 内容 | 成功条件 |
|---|---|---|
| 現状棚卸し | ユーザー、端末、アプリ、既存MFA、SSPR、管理者ロールを確認 | どのユーザーにどの認証方式を適用するか説明できる |
| ペルソナ分類 | 管理者、一般社員、現場端末、BYOD、外部ユーザーなどに分類 | グループベースでポリシー適用できる |
| パイロット設計 | IT部門と代表ユーザーで検証 | 登録、サインイン、復旧、問い合わせ対応が確認済み |
| ポータブル資格情報の登録 | FIDO2キー、Authenticatorパスキー、同期パスキーなどを登録 | 端末が変わっても初回認証・復旧ができる |
| ローカル資格情報の登録 | Windows Hello for Business、Microsoft Entra passkey on Windows、Platform SSOなどを展開 | 日常利用端末でスムーズにサインインできる |
| Conditional Accessで強制 | 重要アプリからPhishing-resistant MFA strengthを要求 | 例外ユーザーを最小化し、ログで確認できる |
| 監視と改善 | Authentication Methods Activity、サインインログ、問い合わせ件数を確認 | 登録率と成功率が上がり、サインイン障害が管理可能 |
新規ユーザーやリモートユーザーの初回登録では、本人確認と初回資格情報の発行が重要です。Microsoftの展開ガイダンスでは、Temporary Access Pass（TAP）を使って最初のポータブル資格情報をブートストラップする流れが示されています。既存ユーザーの場合は、従来のMFAを使って最初のフィッシング耐性資格情報を登録し、その後ローカル資格情報へ広げる進め方が説明されています。(Microsoft Learn)
開発者が確認すべきアプリ側の注意点
パスワードレス認証が利用できない原因は、Microsoft Entra ID側の設定だけとは限りません。アプリ側の認証実装が、FIDO2やPasskeysの利用を妨げることがあります。
開発者は、次の点を確認してください。
| 項目 | 確認内容 |
|---|---|
| SAMLアプリ | RequestedAuthnContextでパスワード必須を指定していないか |
| ドメインヒント | home-realm discoveryを不自然に回避して、フェデレーション先でパスワードレスが使えなくなっていないか |
| Windowsアプリ | .NETデスクトップアプリではMSALとWindows Authentication Manager（WAM）の利用を検討する |
| 埋め込みブラウザー | FIDO2対応が必要な場合はWebView2やシステムブラウザーを使う |
| Androidアプリ | MSALでBROWSERを使う、またはブローカー連携を検討する |
| iOS / macOSアプリ | ASWebAuthenticationSessionまたはブローカー連携を確認する |
| Webアプリ / SPA | 利用者のブラウザーとプラットフォームのFIDO2対応を確認する |
| プロキシ | Appleの関連ドメイン検証など、Passkeysに必要な通信をブロックしていないか |
Microsoftの開発者向けガイダンスでは、SAMLでパスワードを要求するRequestedAuthnContextを指定しないこと、WindowsではWAM、WebView2、システムブラウザーの利用を検討すること、iOSやmacOSではAppleの関連ドメイン検証がプロキシで阻害されないよう確認することなどが示されています。(Microsoft Learn)
業務アプリで独自ログイン画面や古い埋め込みブラウザーを使っている場合、ユーザーにPasskeysを展開しても、そのアプリだけパスワード入力が残ることがあります。パスワードレス移行を進める際は、ID基盤チームだけでなく、アプリオーナーと開発チームも早い段階で巻き込むべきです。
監視・レポートで見るべき指標
展開後は、「何人に有効化したか」ではなく、「実際に登録できているか」「サインインに使われているか」「失敗や問い合わせが増えていないか」を確認します。
Microsoft EntraのAuthentication Methods Activityでは、MFA、パスワードレス認証、SSPRに対応できるユーザー数を確認できます。パスワードレス認証については、FIDO2、Windows Hello for Business、Microsoft Authenticatorのパスワードレス電話サインインなどを使ってパスワードなしでサインインできるユーザーの内訳を確認できます。(Microsoft Learn)
確認すべき指標は次のとおりです。
| 指標 | 見る理由 |
|---|---|
| Passkeys（FIDO2）登録者数 | 対象ユーザーが実際に登録できているか確認する |
| 登録成功・失敗件数 | 端末要件、プロファイル設定、AAGUID制限の問題を検出する |
| 認証方法別サインイン数 | パスワードレスが実際に使われているか確認する |
| Conditional Accessの失敗ログ | 認証強度の強制でブロックされているユーザーを把握する |
| ヘルプデスク問い合わせ件数 | 展開波を進める速度を調整する |
| 例外ユーザー一覧 | 一時例外が恒久化していないか確認する |
登録率だけを見て展開完了と判断するのは危険です。登録していても、実際のサインインではパスワード＋MFAを使い続けているユーザーがいるためです。重要アプリへのアクセスで認証強度が満たされているか、サインインログと合わせて確認しましょう。
展開時に失敗しやすいポイント
全社一括で有効化してヘルプデスクが詰まる
パスキー登録はユーザー体験が大きく変わります。初回登録、端末紛失、スマートフォン機種変更、セキュリティキー紛失など、問い合わせが集中しやすいポイントがあります。
公式展開ガイダンスでも、ヘルプデスクのチケット量に応じて展開速度を落とし、落ち着いたら再開する考え方が示されています。グループ単位のウェーブ展開で、サポート体制に合わせて進めるのが安全です。(Microsoft Learn)
Windows Hello for BusinessとMicrosoft Entra passkey on Windowsを混同する
どちらもWindows HelloのPIN、顔認証、指紋認証を使うため混同しやすいですが、用途が異なります。
Windows Hello for Businessは、企業管理端末へのサインインやSSOに関係する仕組みです。一方、Microsoft Entra passkey on Windowsは、Windows HelloのローカルコンテナにFIDO2パスキーを保存し、Microsoft Entra IDへのサインインに使います。デバイスサインインには使えません。(Microsoft Learn)
また、Microsoft Entra参加済みまたは登録済みの端末でWindows Hello for Business資格情報がすでに存在する場合、同じアカウント・同じコンテナにWindowsパスキーを登録しようとすると失敗する可能性があります。(Microsoft Learn)
Attestation必須にして同期パスキーやWindowsパスキーをブロックする
高セキュリティを狙ってEnforce attestationを有効にすると、認証器の正当性を確認できます。しかし、同期パスキーやMicrosoft Entra passkey on Windowsとは相性が悪い場合があります。
一般ユーザーには同期パスキーを許可し、管理者にはAttestation必須のFIDO2セキュリティキーを要求するなど、対象ユーザーごとに分けるのが現実的です。
レガシーポリシーにSMSや音声通話が残る
Authentication methods policyで強い認証方式を設計しても、古いMFAポリシーやSSPRポリシー側にSMS・音声通話が残っていると、想定外の認証経路が使える場合があります。
特に、SSPRのMobile phone設定では音声通話やSMSが関係するため、組織として廃止したい認証方式が残っていないか確認してください。(Microsoft Learn)
アプリ側がパスワードレスを妨げる
SAMLアプリがパスワード認証を要求していたり、古い埋め込みブラウザーを使っていたりすると、Microsoft Entra ID側でPasskeysを有効化してもユーザーが利用できない場合があります。
管理者は「Entraの設定は正しいのに一部アプリだけ使えない」という事象に備え、アプリオーナーに認証方式の棚卸しを依頼しておくべきです。
復旧手順を決めずに本番適用する
パスワードレス認証では、紛失・故障・機種変更時の復旧が非常に重要です。
最低限、次のルールを事前に決めておきましょう。
| 復旧シナリオ | 決めるべきこと |
|---|---|
| スマートフォン紛失 | 本人確認方法、TAP発行権限、代替認証方法 |
| FIDO2キー紛失 | 予備キーの有無、紛失報告、該当認証方法の削除手順 |
| PC交換 | ローカル資格情報の再登録手順、ポータブル資格情報の利用可否 |
| 管理者ロックアウト | 緊急アクセスアカウント、保管方法、監査方法 |
| 退職・異動 | 登録済み認証方法の削除、デバイス回収、証明書失効 |
まず実行すべきチェックリスト
Microsoft Entra IDでフィッシング耐性のあるパスワードレス認証を始めるなら、次の順に確認してください。
| 優先度 | チェック項目 |
|---|---|
| 高 | Authentication methods policyに移行済みか確認する |
| 高 | 管理者・特権ユーザーを洗い出す |
| 高 | Passkeys（FIDO2）、Windows Hello for Business、証明書ベース認証のどれを誰に使わせるか決める |
| 高 | Conditional AccessでPhishing-resistant MFA strengthを使う対象アプリを決める |
| 高 | TAPや代替認証方法を含む復旧手順を整備する |
| 中 | Windows、macOS、iOS、Androidの対応状況を確認する |
| 中 | PasskeyプロファイルのAttestation、同期パスキー、AAGUID制限を設計する |
| 中 | アプリ開発チームにFIDO2対応を確認する |
| 中 | Authentication Methods Activityで登録率と利用状況を追跡する |
| 低 | 全社展開後、SMS・音声通話など弱い方式の例外削減を進める |
最初の一歩としては、全ユーザーを対象にするのではなく、管理者とIT部門のパイロットグループを作成し、Passkeys（FIDO2）の登録、サインイン、復旧、ログ確認までを一通り検証するのが現実的です。
そのうえで、一般ユーザー向けには同期パスキーやAuthenticatorのパスキー、企業管理Windows端末にはWindows Hello for Business、非参加端末や複数アカウント利用にはMicrosoft Entra passkey on Windowsなど、利用シーンに合わせて方式を広げていきましょう。
Microsoft Entra IDのパスワードレス認証は、設定をオンにするだけの作業ではなく、認証基盤全体の移行計画です。認証方式、端末、アプリ、サポート、監査を同時に見直すことで、フィッシングに強く、ユーザーにも使いやすいサインイン環境を作れます。
コメント