Microsoft Entra IDでパスワードレス認証を展開したい管理者にとって、2026年4月16日時点で押さえるべき更新は Passkey profiles（パスキー プロファイル） です。結論から言えば、Passkey profilesを使うと「全社一律でパスキーを許可する」のではなく、管理者・一般社員・高規制部門・パイロットユーザーごとに、許可するパスキー種別やアテステーション要件を分けて展開できます。Microsoftの2026年3月のEntra更新では、Synced passkeysとPasskey profilesがMicrosoft Entra IDの新リリースとして示され、Passkey profilesは一般提供として案内されています。(TECHCOMMUNITY.MICROSOFT.COM)
パスワードレス展開で失敗しやすいのは、技術そのものよりも「誰に、どの認証方式を、どの順番で許可するか」を決めきれないことです。Passkey profilesは、Identity adminが認証ポリシーを標準化し、endpoint adminが端末準備やサポート計画を合わせやすくするための実務的な制御単位になります。
Microsoft Entra IDのPasskey profilesとは
Passkey profilesは、Microsoft Entra IDのパスキー（FIDO2）認証を、ユーザーグループごとに細かく構成するためのポリシー機能です。従来のようにテナント全体へ同じFIDO2設定を当てるのではなく、プロファイルごとに次のような条件を定義できます。(Microsoft Learn)
| 制御項目 | 何を決めるか | 実務での使いどころ |
|---|---|---|
| 対象グループ | どのユーザーにプロファイルを適用するか | 管理者、標準ユーザー、地域別パイロット、部門別展開 |
| パスキー種別 | Device-bound、Synced、または両方を許可するか | 管理者はデバイスバウンド、一般社員は同期パスキーも許可 |
| アテステーション | 登録時に認証器の真正性確認を求めるか | 高権限アカウントや規制要件のある部門 |
| AAGUID制限 | 特定の認証器・セキュリティキーを許可またはブロックするか | 調達済みのFIDO2キーやMicrosoft Authenticatorの利用制御 |
| Default profile | 既存のグローバル設定を引き継ぐか | 既存FIDO2設定を壊さず新方式へ移行 |
特に重要なのは、Passkey profilesが「パスワードレスを広げるための機能」であると同時に、「広げすぎを防ぐための機能」でもある点です。標準ユーザーには利便性の高い同期パスキーを許可しつつ、管理者にはより厳格なデバイスバウンドパスキーを求める、といった切り分けができます。
Passkey profilesで標準化できる理由
パスワードレス展開の標準化とは、全員に同じ認証方法を強制することではありません。実務では、ユーザーのリスク、端末環境、サポート体制に応じて「違うポリシーを、同じ設計思想で運用する」ことが重要です。
Microsoft Entra IDのPasskey profilesは、この考え方に合っています。たとえば、管理者向けには「デバイスバウンドのみ、アテステーションあり」、一般社員向けには「同期パスキーとデバイスバウンドの両方を許可」、パイロット展開では「同じ一般社員向けプロファイルを小さなグループへ先に割り当てる」といった設計ができます。
| 展開対象 | 推奨しやすいポリシー例 | 目的 |
|---|---|---|
| Global Administrator、Privileged Role Administrator、Security Administratorなど | Device-boundのみ、アテステーション有効、必要に応じてAAGUID制限 | 高権限アカウントの認証器を厳格に管理する |
| 一般社員 | SyncedとDevice-boundを許可、アテステーションは要件に応じて判断 | 登録率と利用率を高め、ヘルプデスク負荷を抑える |
| 現場・共有端末利用者 | ポータブルなFIDO2キーやAuthenticatorなどを中心に検討 | 端末に依存しすぎない認証導線を確保する |
| パイロットユーザー | 本番用プロファイルを小さなセキュリティグループに割り当てる | プロファイルを増やさず段階展開する |
ここで注意したいのは、プロファイルを「地域×部門×役職」の組み合わせで増やしすぎないことです。Microsoftのドキュメントでは、Default passkey profileを含めて最大3つのPasskey profilesがサポートされ、より多くのプロファイル対応は開発中とされています。つまり、プロファイルは地域別ではなく、リスクや職務ごとの大きなポリシー単位として設計するのが現実的です。(Microsoft Learn)
Device-bound passkeyとSynced passkeyの使い分け
Passkey profilesを設計する前に、Device-bound passkeyとSynced passkeyの違いを整理しておく必要があります。
Device-bound passkeyは、秘密鍵が単一の物理デバイスに作成・保存され、そのデバイスから出ないタイプです。Microsoft AuthenticatorやFIDO2セキュリティキーが例として挙げられます。一方、Synced passkeyは暗号化された秘密鍵がクラウドのパスキープロバイダーに同期され、同じプロバイダーで認証された別デバイスからも利用できるタイプです。(Microsoft Learn)
| 種別 | 向いている用途 | 注意点 |
|---|---|---|
| Device-bound passkey | 管理者、高規制ユーザー、特定デバイスに紐づけたい業務 | 紛失時の復旧、予備キー、ヘルプデスク手順が重要 |
| Synced passkey | 一般社員、BYODに近い利用、複数デバイスを使うユーザー | アテステーションを前提にしたデバイス真正性確認には向かない |
| FIDO2 security key | 管理者、緊急アクセス、共有端末利用者 | 物理キーの配布、在庫管理、紛失対応が必要 |
| Microsoft Authenticatorのpasskey | モバイルを利用する社員、既存Authenticator運用がある組織 | 対象OS、アプリバージョン、登録導線の確認が必要 |
Microsoftの説明では、アテステーションを有効にするとデバイスやプロバイダーの真正性を確認できますが、同期パスキーはアテステーションをサポートしません。また、Microsoft Entra IDではアテステーションを有効にした場合、同期パスキーは除外され、デバイスバウンドパスキーのみが許可されます。(Microsoft Learn)
実務上の判断基準はシンプルです。管理者や機密システム利用者にはDevice-boundを優先し、一般社員の広範な展開ではSynced passkeyを含めて登録しやすさを重視します。セキュリティ要件が高いユーザーに利便性だけで同期パスキーを許可すると、後からポリシーを締める際に利用者影響が大きくなります。
Passkey profilesと条件付きアクセスの役割は分けて考える
Passkey profilesだけでパスワードレス展開が完成するわけではありません。Microsoft Entra IDでは、Passkey profilesと条件付きアクセスの認証強度を分けて設計する必要があります。
Passkey profilesは「そのユーザーがどのパスキーを登録・利用できるか」を制御します。一方、条件付きアクセスのAuthentication strengthsは「特定のアプリやリスク条件で、どの認証方式を要求するか」を制御します。Microsoftのドキュメントでも、認証強度はリソースアクセス時に利用できる認証方法の組み合わせを指定する条件付きアクセス制御として説明されています。(Microsoft Learn)
| 機能 | 主な役割 | 設計例 |
|---|---|---|
| Passkey profiles | ユーザー・グループごとに許可するパスキーを定義 | 管理者はDevice-boundのみ、一般社員はSyncedも許可 |
| Authentication methods policy | Microsoft Entra ID全体で使える認証方法を管理 | Passkey（FIDO2）を対象グループへ有効化 |
| Conditional Access Authentication strengths | アプリや条件ごとに要求する認証強度を指定 | 管理ポータルにはフィッシング耐性MFAを要求 |
| Microsoft Intune | 端末構成、コンプライアンス、アプリ配布を支援 | OS更新、Authenticator配布、デバイス準備 |
| Temporary Access Pass | 初回登録や復旧の一時的な導線 | 新入社員やMFA未登録ユーザーの初期登録 |
よくある失敗は、Passkey profilesでユーザーの準備が終わる前に、条件付きアクセスでフィッシング耐性MFAを強制してしまうことです。Microsoftは、管理者ロールにフィッシング耐性MFAを要求するポリシーを作成する前に、対象管理者が適切な方法を登録済みであることを確認するよう警告しています。準備前に有効化すると、テナントからロックアウトされるリスクがあります。(Microsoft Learn)
推奨するPasskey profilesのポリシーモデル
Passkey profilesは増やしすぎると管理が難しくなります。まずは次の3分類で考えると、グローバル組織でも運用しやすくなります。
| プロファイル設計 | 対象 | パスキー種別 | アテステーション | 運用ポイント |
|---|---|---|---|---|
| Default profile | 既存FIDO2設定を持つユーザー、移行直後の全体 | 既存設定を確認して維持 | 既存設定に準拠 | Opt-in後に既存グローバル設定が移行されるため、最初に差分確認する |
| Privileged profile | 管理者、高権限ロール、セキュリティ運用担当 | Device-bound中心 | 有効を検討 | 同期パスキーを安易に含めない。予備キーと復旧手順を用意する |
| Workforce profile | 一般社員、営業、バックオフィス、通常業務ユーザー | SyncedとDevice-boundを検討 | 要件に応じて無効 | 登録率とサポート負荷を見ながら、Waveグループで段階展開する |
Default profileは軽視しないでください。Passkey profilesを有効化すると、既存のグローバルなPasskey（FIDO2）ポリシー設定はDefault passkey profileへ自動的に移行されます。また、Passkey profilesを有効化した後はオプトアウトできないとされています。(Microsoft Learn)
もう一つの落とし穴は、グループの重複です。ユーザーが複数のPasskey profilesの対象になる場合、少なくとも1つのプロファイル要件を満たせばパスキーの登録・認証が許可され、評価順序はありません。つまり、管理者が「厳格な管理者用プロファイル」と「同期パスキーを許可する全社員用プロファイル」の両方に入っていると、意図せず緩い条件が有効になる可能性があります。(Microsoft Learn)
実務では、地域別・部門別の展開Waveはセキュリティグループで管理し、プロファイル自体は「特権」「一般」「既存移行」のような少数のリスク分類に寄せるのが安全です。
Identity admin向けの導入手順
Passkey profilesの展開は、いきなり全社有効化するよりも、現在のFIDO2設定と認証強度ポリシーを棚卸ししてから進めるべきです。
| フェーズ | 作業 | 完了条件 |
|---|---|---|
| 現状確認 | 既存のFIDO2設定、MFA登録状況、管理者ロール、条件付きアクセスを確認 | 既存ユーザーに影響する設定が把握できている |
| グループ設計 | Privileged、Workforce、Pilot、Break-glassを分ける | 管理者が一般社員用プロファイルに重複しない |
| Default確認 | Passkey profiles有効化後、Default profileの設定を確認 | 既存FIDO2設定が意図通り移行されている |
| プロファイル作成 | パスキー種別、アテステーション、AAGUID制限を定義 | 対象ユーザーごとの許可方法が明文化されている |
| パイロット | 小規模グループへ割り当て、登録率と失敗理由を確認 | ヘルプデスクで解決できる手順が整っている |
| 条件付きアクセス適用 | 認証強度をReport-onlyなどで検証してから段階的に有効化 | 対象者が必要なパスキーを登録済み |
| 本番展開 | Waveごとに対象グループを拡大 | 登録率、サインイン失敗、問い合わせ件数を継続確認 |
Microsoftは、フィッシング耐性パスワードレス展開ではユーザーをペルソナごとに分類し、それぞれにMicrosoft Entra IDグループを作る考え方を示しています。また、展開時はテストユーザーや早期導入者を用意し、Authentication Methods Activityレポートなどで登録状況を測定することが推奨されています。(Microsoft Learn)
Endpoint adminが事前に確認すべきこと
Passkey profilesはIdentity adminの設定に見えますが、実際の成功率は端末側の準備に大きく左右されます。特にグローバル展開では、OS、ブラウザ、Authenticator、MDM、Bluetooth制御、ネットワーク制限が地域ごとに異なることがあります。
Microsoftの展開ガイドでは、フィッシング耐性パスワードレスの端末準備として、サポート対象OSへの更新が重要とされています。例として、Windows Hello for BusinessではWindows 10 22H2、パスキーのより良い体験ではWindows 11 22H2、macOS 13、iOS 17、Android 14が挙げられています。(Microsoft Learn)
endpoint adminは、少なくとも次の項目を確認してからパイロットを始めるべきです。
| 確認項目 | 見るべきポイント |
|---|---|
| OSバージョン | 対象プラットフォームがパスキーやWindows Hello for Businessの要件を満たすか |
| Microsoft Authenticator | パスキー登録に必要なアプリバージョン、配布状況、更新制御 |
| ブラウザ | WebAuthn/FIDO2のサポート、拡張機能、企業管理ポリシー |
| Bluetooth制御 | クロスデバイス登録・認証が必要な場合、Bluetooth制限が妨げにならないか |
| Intune構成 | コンプライアンスポリシー、構成プロファイル、アプリ配布が整っているか |
| 共有端末 | 個人のローカル資格情報を前提にしてよい端末か |
| 復旧導線 | 端末紛失、機種変更、Authenticator再セットアップ時の手順 |
Microsoft Authenticatorのパスキーでは、クロスデバイス登録や認証にBluetoothとインターネット接続が関係します。組織でBluetoothを制限している場合、パスキー対応FIDO2認証器向けのBluetoothペアリングだけを許可する設計も検討対象になります。(Microsoft Learn)
AAGUID制限は便利だが、運用変更の影響が大きい
AAGUIDは、FIDO2認証器やパスキープロバイダーの種類を識別するためのIDです。Passkey profilesでは、AAGUIDを使って特定の認証器を許可またはブロックできます。たとえば、会社が標準採用したFIDO2セキュリティキーだけを許可する、といった制御が可能です。(Microsoft Learn)
ただし、AAGUID制限は「細かく制御できるから常に使うべき」というものではありません。Microsoftのドキュメントでは、以前許可していたAAGUIDを削除すると、その方法を登録済みのユーザーがサインインに使えなくなると説明されています。また、アテステーションを強制しない場合、AAGUIDリストは厳格なセキュリティ制御というよりポリシーガイドとして扱うべきとされています。(Microsoft Learn)
AAGUID制限を使うなら、次の3点を必ず運用ルールに入れてください。
| ルール | 理由 |
|---|---|
| 変更前に登録済みユーザー数を確認する | 削除したAAGUIDの利用者がサインイン不能になる可能性がある |
| セキュリティキーの調達モデルを固定する | 同じメーカーでもモデル変更でAAGUIDが変わる場合がある |
| パイロットで登録・サインイン・復旧まで試す | 登録できても、実運用のサインインや復旧で詰まることがある |
条件付きアクセスを有効化する前のロックアウト対策
パスワードレス展開で最も避けるべき事故は、管理者がサインインできなくなることです。Passkey profilesを整えても、条件付きアクセスの認証強度を強くしすぎると、準備不足の管理者や復旧アカウントが締め出される可能性があります。
Microsoftは、Microsoft Entra IDで誤ってロックアウトされる影響を抑えるため、2つ以上の緊急アクセスアカウントを作成することを推奨しています。緊急アクセスアカウントにはPasskey（FIDO2）が推奨される認証方法の一つとして挙げられ、通常の管理者アカウントと同じ認証依存関係を持たせないことも重要です。(Microsoft Learn)
また、条件付きアクセスポリシーは強力な制御であり、Microsoftは緊急アクセスまたはbreak-glassアカウントをポリシーから除外してロックアウトを防ぐこと、Report-only modeやWhat Ifツールで検証することを推奨しています。(Microsoft Learn)
実務では、次の状態になるまで本番強制は避けるべきです。
| チェック | OKの基準 |
|---|---|
| 管理者の登録 | 対象管理者が必要なパスキーを登録済み |
| 予備認証 | 管理者に代替のフィッシング耐性手段がある |
| 緊急アクセス | 2つ以上の緊急アクセスアカウントを定期検証している |
| 条件付きアクセス | Report-onlyまたは限定グループで影響確認済み |
| ヘルプデスク | 紛失、機種変更、登録失敗、退職時の手順がある |
登録と復旧の導線を先に決める
パスワードレス展開は「登録できるか」で成功率が決まります。特に新入社員、MFA未登録ユーザー、リモートユーザーは、最初のフィッシング耐性資格情報をどう取得するかが課題になります。
Microsoftのガイドでは、ユーザーには少なくとも2つの認証方法を登録することが推奨されています。また、新規ユーザーやMFA未登録ユーザーにはTemporary Access Pass（TAP）を発行し、最初のフィッシング耐性資格情報を登録する流れが説明されています。(Microsoft Learn)
TAPは恒久的なパスワードレス方式ではありませんが、長期的なパスワードレス設定を完了する前のオンボーディングや復旧に使える一時的な資格情報です。Microsoft Intuneのパスワードレス解説でも、TAPは初回サインイン問題を解決する重要な要素として説明されています。(Microsoft Learn)
登録導線は、次のようにユーザー区分ごとに分けると運用しやすくなります。
| ユーザー区分 | 初回登録の考え方 |
|---|---|
| 新入社員 | 本人確認後にTAPを発行し、最初のポータブル資格情報を登録 |
| 既存社員 | 既存MFAで本人確認し、パスキー登録へ誘導 |
| 管理者 | 事前にFIDO2キーやDevice-bound passkeyを登録し、予備手段も用意 |
| リモートユーザー | 本人確認、TAP、端末要件、サポート窓口を事前に明記 |
| 共有端末利用者 | 個人端末前提のWindows Helloだけに依存しない |
よくある失敗と回避策
Passkey profilesは強力ですが、設計を誤ると「広げたいのに登録できない」「厳しくしたいのに緩いプロファイルが効く」「変更したら既存ユーザーがサインインできない」といった問題が起きます。
| 失敗パターン | 原因 | 回避策 |
|---|---|---|
| 管理者にも同期パスキーが許可される | 管理者が一般社員用グループにも入っている | 特権ユーザーを一般展開グループから分離する |
| プロファイルが増えすぎる | 地域や部門ごとにプロファイルを作る | プロファイルはリスク分類、展開Waveはグループで管理する |
| アテステーションを後から有効化すれば既存登録も厳格化されると思い込む | アテステーションは登録時の許可制御 | 既存登録の扱いを別途棚卸しし、必要なら再登録計画を作る |
| AAGUIDを削除して既存ユーザーが使えなくなる | 登録済み認証器のサインイン可否に影響する | 削除前に利用者を特定し、代替手段を登録させる |
| 条件付きアクセスを先に強制する | 対象者がパスキー未登録 | パイロット、Report-only、登録率確認の順に進める |
| Helpdeskが復旧できない | 紛失・機種変更・TAP発行手順が未整備 | 復旧Runbookを作り、権限と本人確認手順を明確にする |
特に、アテステーションを有効化した後の挙動には注意が必要です。Microsoftのドキュメントでは、アテステーション強制は登録時にパスキーを許可するかどうかを制御するもので、アテステーションなしで登録済みのパスキーが、後からEnforce attestationをYesにしただけでサインイン時にブロックされるわけではないと説明されています。(Microsoft Learn)
グローバル展開では「地域」より「リスク分類」を先に決める
日本、北米、欧州、アジア太平洋など複数地域で展開する場合、地域ごとにPasskey profilesを作りたくなります。しかし、これは管理が複雑になりがちです。Passkey profilesは、地域ではなく次のようなリスク分類で設計する方が長期運用に向いています。
| 分類軸 | 例 |
|---|---|
| 権限 | 特権管理者、一般ユーザー、外部委託管理者 |
| データ感度 | 財務、人事、研究開発、一般業務 |
| 端末形態 | 管理端末、会社貸与端末、モバイル中心、共有端末 |
| 復旧難易度 | リモート中心、現地ITあり、24時間運用 |
| 規制要件 | 高規制部門、通常部門 |
地域差は、プロファイルではなく展開Wave、サポート時間帯、ユーザーコミュニケーション、Intuneポリシー、ヘルプデスク体制で吸収します。たとえば「Workforce profile」は全世界共通にしつつ、割り当てるグループを「Wave-01-Japan」「Wave-02-EMEA」「Wave-03-Americas」のように分ければ、ポリシーの一貫性と展開速度の調整を両立できます。
まず管理者が取るべき次のアクション
Microsoft Entra IDのPasskey profilesは、パスワードレス認証を単に有効化するためのボタンではありません。管理者が「どのユーザーに、どのパスキーを、どの条件で許可するか」を標準化するためのポリシーモデルです。
最初に行うべきことは、Passkey profilesを増やすことではなく、ユーザー分類を決めることです。管理者、高規制ユーザー、一般社員、パイロットユーザーを分け、既存FIDO2設定がDefault profileにどう移行されるかを確認します。そのうえで、一般社員向けには登録しやすいプロファイル、管理者向けには厳格なプロファイルを設計し、条件付きアクセスの認証強度は登録完了後に段階適用します。
Identity adminはポリシーとグループ設計を、endpoint adminは端末・アプリ・復旧導線を、それぞれ同じ展開計画に載せることが重要です。Passkey profilesを少数の明確なルールに整理できれば、パスワードレス展開は「例外だらけの個別対応」ではなく、制御された標準ロールアウトとして進められます。
コメント